- systemd is the default init framework, replacing initscripts.
- The services which are started by systemd can be found in the subfolders of /etc/systemd/system/.
- Services can be enabled using the
- Units can be, for example, services (.service), mount points (.mount), devices (.device) or sockets (.socket).
- If you do not specify the suffix, systemctl will assume .service.
- Mount points will automatically be translated into the appropriate .mount unit. For example, specifying /home is equivalent to home.mount.
- Similar to mount points, devices are automatically translated into the appropriate .device unit, therefore specifying /dev/sda2 is equivalent to dev-sda2.device.
When run as a system instance, systemd interprets the configuration file /etc/systemd/system.conf and the files in /etc/systemd/system.conf.d directories; when run as a user instance, systemd interprets the configuration file user.conf and the files in user.conf.d directories. These configuration files contain a few settings controlling basic manager operations.
systemd vs SysV or Upstart
- The init scripts in /etc/rc.d/init.d/ have been replaced with service units with the .service file extension.
Comparison by commands:
# Starts a service. service name start systemctl start name.service # Stops a service. service name stop systemctl stop name.service # Restarts a service. service name restart systemctl restart name.service # Restarts a service only if it is running. service name condrestart systemctl try-restart name.service # Reloads configuration. service name reload systemctl reload name.service # Checks if a service is running. service name status systemctl status name.service systemctl is-active name.service # Displays the status of all services. service --status-all systemctl list-units --type service --all # Comparison of the chkconfig Utility with systemctl # Enables a service. chkconfig name on systemctl enable name.service systemctl reenable name.service # Disables a service. chkconfig name off systemctl disable name.service # Checks if a service is enabled. chkconfig --list name systemctl status name.service systemctl is-enabled name.service # Lists all services and checks if they are enabled. chkconfig --list systemctl list-unit-files --type service # Lists services that are ordered to start before the specified unit. chkconfig --list systemctl list-dependencies --after systemctl list-dependencies graphical.target # Lists services that are ordered to start after the specified unit. chkconfig --list systemctl list-dependencies --before
# List known units systemctl [list-units] systemctl --all # List failed units: systemctl --failed # Lists currently loaded target units: # Same as "runlevel" command in SysV systemctl list-units --type target systemctl list-units --type service # Show all installed unit files systemctl list-unit-files # Determine which target unit is used by default systemctl get-default # In arch, it's graphical.target # Replace name with the name of the target unit you want to use by default (for example, multi-user). This command replaces the /etc/systemd/system/default.target file with a symbolic link to /usr/lib/systemd/system/name.target systemctl set-default name.target # This command is similar to "systemctl isolate rescue.target", but it also sends an informative message to all users that are currently logged into the system. systemctl rescue # Change to a different target unit in the current session: # Seme as "telinit runlevel" in SysV systemctl isolate name.target systemctl start/stop/restart/reload/status systemctl is-enabled/enable/disable unit # Mask a unit to make it impossible to start it: systemctl mask unit systemctl unmask unit # Show the manual page associated with a unit (this has to be supported by the unit file): systemctl help unit systemctl daemon-reload systemctl reboot/poweroff/suspend/hibernate
Symbolic unit file is not followed by design
# Use this to debug. # wcf.serve is a symbolic pointing to /home/wcf/conf/wcf.service. cd /etc/systemd/system strace -o trace.txt systemctl enable wcf.service # The result is: # open("///etc/systemd/system/wcf.service", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links) # O_NOFOLLOW implies that it won't be followed.
The solution is to enable directly on the real file:
systemctl enable /home/wcf/conf/wcf.service. The following is the explanation:
"systemctl enable" is about enabling vendor supplied unit files. It will only create and remove symlinks in /etc/ and /run/, that's all it does. So right now it's a pretty safe tool: it will create/override/remove the modifiable configuration via symlinks and strictly leave vendor supplied static data untouched, since it is stored in real files. However, if we suddenly allow enabling of symlinks, then this clear separation goes away. This gets particularly nasty for disabling things, because that removes all symlinks to the destination file, and how should it know when to stop precisely? So, yeah, I am pretty sure we shouldn't allow "enabling of symlinks". What we should support however is enabling of unit files that are outside of the usualy search paths, via specifiying full absolute paths. i.e. "systemctl enable /var/lib/foo/bar.service" should link it to /etc/systemd/system/bar.service and do everything listed in [Install]. Now, I originally implemented things to work like that, but this might got broken one time... Andrew, so if you'd call "systemctl enable" directly on the original unit file, instead of via a symlink, then everything should be fine for you, right?
- Enabling users to start, stop, enable, and disable their own units.
- On the first login of a user, systemd automatically launches a systemd --user instance, responsible to manage user services.
- By default no user services are run.
- User units are located in the following directories just as they would with system services (ordered by ascending precedence):
- /usr/lib/systemd/user/, where services provided by installed packages go.
- /etc/systemd/user/, where system-wide user services are placed by the system administrator.
- ~/.config/systemd/user/, where the user puts its own services.
- To check that it is already running you can use
systemctl --user status serviceName.
- All the user services will be placed in ~/.config/systemd/user. If you want to run services on first login, execute
systemctl --user enable serviceNamefor any service you want to be autostarted.
Can't sudo in user services
systemctl --user start wcf # To see the log: systemctl --user status wcf # or use: journalctl --user-unit wcf
Jul 15 23:04:30 wcfThinkpad systemd: Started wcfStartUp. Jul 15 23:04:30 wcfThinkpad systemd: Starting wcfStartUp... Jul 15 23:04:30 wcfThinkpad init.sh: sudo: no tty present and no askpass program specified Jul 15 23:04:30 wcfThinkpad sudo: pam_unix(sudo:auth): auth could not identify password for [wangcf]
systemd uses targets which serve a similar purpose as runlevels but act a little different. Each target is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common SystemVinit runlevels so you can still switch targets using the familiar telinit RUNLEVEL command.