Systemd Concepts

Internal

• systemd

TODO: This article was generated during the process of parsing https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units.Currently at “System State Overview” in the document. Next time I need systemd, finish it and transfer everything in here.

!!!Purpose

The purpose of an init system is to manage (initialize, start, stop) components in the user space - programs that run after the kernel has booted. Some of those components are services and daemons for the server.

!!!systemctl

Template:Systemctl is the central management tool for systemd.

!!!Units

The resources managed by systemd are known as units.

Units represent different types of resources and are defined in files known as unit files. The type of each unit can be inferred from the suffix at the end of the file.

To list all units known to systemd, use

{{{ systemctl list-units }}}

The command will list the units and their state.

!!!Services

For service management tasks, the target unit is a service unit, and their unit file have a Template:.service suffix.

!!!Starting a Service

Starting a service means using Template:Systemctl to execute instructions in the service's unit file. It must be executed as root:

{{{ systemctl start <application>.service }}}

The short form

{{{ systemctl start <application> }}}

also works.

!!!Reload Configuration without a Restart

If the service supports reloading configuration without actually restarting the service, use:

{{{ systemctl reload <application>.service }}}

!!!Restart a Service

{{{ systemctl restart <application>.service }}}

!!!Reload or Restart a Service

If you are unsure whether the service has the configuration reload functionality, use Template:Reload-or-restart:

{{{ systemctl reload-or-restart <application>.service }}}

!!!Enabled - Start a Service Automatically at Boot

To configure a service to start automatically at boot it must be enabled:

{{{ systemctl enable <application>.service }}}

This command creates a symbolic link from the service unit file, which is usually maintained in Template:/lib/systemd/system into a location on disk where systemd looks for autostart files. This is usually a {{/etc/systemd/system/<some-target>.target.wants}} directory. See [systemd Concepts#Target].

Example:

{{{ [root@openshift-master1 system]# systemctl enable docker ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service' }}}

!!!Disabled

{{{ systemctl disable <application>.service }}}

!!!Status of a Service

!!Status Report

To check the status of a service run:

{{{ systemctl status <application>.service }}}

!!Active

A service can be active (running) or not active. To check whether a service is active (running), execute:

{{{ systemctl is-active <application>.service }}}

This will return the current unit state as a string ("active" or "inactive"). The exit code will be "0" if it is active.

!!Enabled

A service can be configured to start at boot (enabled) or not enabled. To check whether a service is enabled, execute:

{{{ systemctl is-enabled <application>.service }}}

This will return the current unit enabled state as a string ("enabled" or "disabled"). The exit code will be "0" if it is enabled.

!!Failed

systemctl can be used to check to see whether the service is in a failed state:

{{{ systemctl is-failed <application>.service }}}

This will return "active" if it is running properly or "failed" if an error occurred. If the unit was intentionally stopped, it may return "unknown" or "inactive". An exit status of "0" indicates that a failure occurred and an exit status of "1" indicates any other status.

!!!Loaded Unit

A unit is in a "loaded" state if the unit's configuration has been parsed by systemd. The configuration of loaded units is kept in memory.

!!!Target

__Referenced by:__\\ [{INSERT com.ecyrd.jspwiki.plugin.ReferringPagesPlugin WHERE max=20, maxwidth=50}]