Managing a Linux Server with Systemd

Systemd is the System Management Daemon, which provides a standard for controlling the Linux boot process. It is named per the UNIX convention of adding ‘d’ to the end of daemon’s name. Systemd is intended as a drop-in replacement for the very common init start-up scripts for the boot process (which is also referred to as System V or SysV).

Though there is some debate regarding the benefits of systemd, the advantages do include: Service Reporting (failed? suspended? error?), Process Monitoring (kills user processes at logout), and Parallel Processes (multiple services are able to start at same time, improving boot times).

OS/Distro : Integration
CentOS: Yes, by default since CentOS 7
Fedora: Yes, since the release of Fedora 15
RedHat: Yes
Debian: Yes, shipped since Debian 7 as a technology preview
Arch: Yes
Ubuntu: Available
Gentoo: Available
OpenSUSE: Available
Slack: No

With systemd it is still possible to use the chkconfig and service commands to manage services that haven’t moved their management to systemd. However, in some cases you will get warning messages from the commands.

On Fedora, RedHat, and CentOS, for example:

chkconfig

returns:

Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.

If you want to list systemd services use ‘systemctl list-unit-files’.
To see services enabled on particular target use
‘systemctl list-dependencies [target]’.

For a primer on the legacy command chkconfig, check-out our tutorial on: chkconfig Command Examples for Red Hat and CentOS

The arguments systemctl uses are very similar to the legacy arguments for chkconfig and service. For example, instead of:

service sshd start

it would be:

systemctl start sshd.service

Or instead of:

chkconfig sshd on

it would be:

systemctl enable sshd.service

View all services that can start using systemctl and their respective statuses:

systemctl list-unit-files --type=service