Systemd Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(64 intermediate revisions by the same user not shown)
Line 9: Line 9:
=Overview=
=Overview=


<code>systemd</code> is a init system, a system and user space service manager for the Linux operating system. 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.  
<code>systemd</code> is a init system, a system and user space service manager for the Linux operating system. The purpose of an init system is to manage - initialize, start, stop - components in the user space, which are the programs that run after the kernel has booted. Some of those components are services and daemons that provide services.


<code>systemd</code> is run as the first process at boot (PID 1) and acts as the init system that brings up and maintains the userspace services.
<code>systemd</code> runs as the first process at boot, with PID 1, and acts as the init system that brings up and maintains the user-space services.


Unlike [[System V#init|System V init]], which starts services one at a time, moving to the next after running dependency checks and waiting on the daemon to start, <code>systemd</code> can start services in parallel. It takes advantage of the daemon to daemon relationship in that dependent daemons do not actually need to be running, they only need the correct domain sockets to be available. <tt>systemd</tt> creates all sockets first, all the daemons second and any client requests to daemons not yet running are cached in the socket buffer and filled when the daemons come online.
Unlike [[System V#init|System V init]], which starts services one at a time, moving to the next service after running dependency checks and waiting on the daemon to start, <code>systemd</code> can start services in parallel. It takes advantage of the daemon to daemon relationship in that dependent daemons do not actually need to be running, they only need the correct domain sockets to be available. <code>systemd</code> creates all sockets first, all the daemons second and any client requests to daemons not yet running are cached in the socket buffer and filled when the daemons come online.


<tt>systemd</tt> interprets the configuration file <tt>system.conf</tt> and the files in <tt>system.conf.d</tt> directories.
<code>systemd</code> interprets its main configuration configuration file <code>/etc/systemd/system.conf</code> and the files in <code>system.conf.d</code> directories.


=Differences between System V and systemd=
=Differences between System V and systemd=
Line 22: Line 22:
=<tt>systemctl</tt>=
=<tt>systemctl</tt>=


<tt>systemctl</tt> is the central management tool for systemd. More operational details:
<code>systemctl</code> is the central management tool for systemd. More operational details:


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
{{Internal|systemctl|<tt>systemctl</tt>}}
:[[systemctl]]
</blockquote>


=<span id='Units_and_Unit_Files'></span><span id='Unit'></span>Units=
=<span id='Units_and_Unit_Files'></span><span id='Unit'></span>Units=
The resources managed by systemd are known as '''units'''. systemd provides a dependency system between units.
The resources managed by <code>systemd</code> are known as units. <code>systemd</code> provides a dependency system between units.


Units represent different types of resources. The units are defined in files known as [[#Unit_File|unit files]]. The unit type is given the suffix of the corresponding unit file. There are 12 types of resources:
Units represent different types of resources. The units are defined in configuration files known as [[#Unit_File|unit files]]. The unit type is given by the suffix of the corresponding unit file. There are 12 types of resources:
* <code>.service</code>: A service unit describes how to manage a service or an application. This including starting and stopping the service, under which circumstance it should be automatically started and its dependencies.
* <code>.service</code>: A service unit describes how to manage a service or an application. This including starting and stopping the service, under which circumstance it should be automatically started and its dependencies. For more details, see the [[#Services|Services]] section, below.
* <code>.socket</code>: A socket unit describes a network or IPC socket, or a FIFO buffer systemd uses for socket-based activation.
* <code>.socket</code>: A socket unit describes a network or IPC socket, or a FIFO buffer systemd uses for socket-based activation.
* <code>.device</code>: A device unit describes a device that needs systemd management.
* <code>.device</code>: A device unit describes a device that needs systemd management.
Line 38: Line 36:
* <code>.automount</code>: Units that configure a mountpoint to be automatically mounted.
* <code>.automount</code>: Units that configure a mountpoint to be automatically mounted.
* <code>.swap</code>: Units that describe the swap space on the system.
* <code>.swap</code>: Units that describe the swap space on the system.
* <code>.target</code>: A unit that provides a synchronization point for other units when booting up or changing state.
* <code>.target</code>: A unit that provides a synchronization point for other units when booting up or changing state. For more details, see [[#Target|Targets]] section below.
* <code>.path</code>: Units defining paths that can be used for path-based activation.
* <code>.path</code>: Units defining paths that can be used for path-based activation.
* <code>.timer</code>: A timer unit defines a timer managed by systemd, similar to a cron job for delayed or scheduled activation.
* <code>.timer</code>: A timer unit defines a timer managed by systemd, similar to a cron job for delayed or scheduled activation. For more details see [[#Timers|Timers]] section below.
* <code>.snapshot</code>
* <code>.snapshot</code>
* <code>.slice</code>
* <code>.slice</code>
* <code>.scope</code>
* <code>.scope</code>
<span id='Loaded_Unit'></span>A unit is in a "loaded" state if the unit's configuration has been parsed by <code>systemd</code>. The configuration of loaded units is kept in memory.
==Query Known Units==
To list all units known to systemd, use:
<syntaxhighlight lang='bash'>
systemctl list-units
</syntaxhighlight>
The command will list the units and their state.
To query units matching a certain pattern, use:
<syntaxhighlight lang='bash'>
systemctl list-units PATTERN
</syntaxhighlight>


=<span id='Unit_File'></span>Unit Files=
=<span id='Unit_File'></span>Unit Files=
 
Unit files are configuration files for [[#Unit|units]]. They are not executable scripts. The type of each unit can be inferred from the suffix at the end of the file, as described in the [[#Unit|Units]] section.
The type of each unit can be inferred from the suffix at the end of the file, as described in the [[#Unit|Units]] section.
==Unit File Location==
==Unit File Location==


Line 65: Line 75:
A typical unit file is similar to:
A typical unit file is similar to:


<syntaxhighlight lang='prop'>
<syntaxhighlight lang='bash'>
[Unit]
[Unit]
Description=My Service
Description=My Service
Line 81: Line 91:
===<tt>[Unit]</tt> Section===
===<tt>[Unit]</tt> Section===


The <code>[Unit]</code> section contains a description of the service and its dependency declarations. In the example above, we declare that systemd must not attempt to start the service until the network is not running on the host. For more details on dependencies, see the [[#Dependencies|Dependencies]] section, below. For more practical details on how to declare dependencies, see [[systemd Declaring a Service Dependency]].
The <code>[Unit]</code> section contains a description of the service and its dependency declarations.  
 
In the example above, we declare that systemd must not attempt to start the service until the network is not running on the host. For more details on dependencies, see the [[#Dependencies|Dependencies]] section, below. For more practical details on how to declare dependencies, see [[systemd Declaring a Service Dependency]].


===[Service] Section===
===<tt>[Service]</tt> Section===


<tt>Type=</tt> can be set to one of "simple", "forking", "oneshot", "dbus", "notify" or "idle"
<code>Type</code> can be set to one of <code>simple</code>, <code>[[#forking|forking]]</code>, <code>[[#oneshot|oneshot]]</code>, <code>dbus</code>, <code>notify</code> or <code>idle</code>.


====Type=forking====
====<span id='forking'></span><tt>Type=forking</tt>====


<tt>ExecStart=</tt> represents the path to the binary to execute when the service is started. The binary is expected to fork.
<code>ExecStart</code> represents the path to the binary to execute when the service is started. The binary is expected to fork.


If set to "forking", it is expected that the process configured with <tt>ExecStart=</tt> will call <tt>fork()</tt> as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the <tt>PIDFile=</tt> option, so that <tt>systemd</tt> can identify the main process of the daemon. <tt>systemd</tt> will proceed with starting follow-up units as soon as the parent process exits.
If set to "forking", it is expected that the process configured with <code>ExecStart</code> will call <tt>fork()</tt> as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the <code>PIDFile</code> option, so that <code>systemd</code> can identify the main process of the daemon. <code>systemd</code> will proceed with starting follow-up units as soon as the parent process exits.


<tt>PIDFile=</tt> takes an absolute file name pointing to the PID file of the service's daemon. <tt>PIDFile=</tt>is recommended for services where <tt>Type=</tt> is set to forking. <tt>systemd</tt> will read the PID of the main process of the daemon after start-up of the service. <tt>systemd</tt> ''will not write'' to the file configured here, although it will remove the file after the service has shut down if it still exists. <tt>systemd</tt> uses this file to identify the main process of the daemon, but the file will need to be written by other means.
<code>PIDFile</code> takes an absolute file name pointing to the PID file of the service's daemon. <code>PIDFile</code> is recommended for services where <code>Type</code> is set to forking. <code>systemd</code> will read the PID of the main process of the daemon after start-up of the service. <code>systemd</code> '''will not write''' to the file configured here, although it will remove the file after the service has shut down if it still exists. <code>systemd</code> uses this file to identify the main process of the daemon, but the file will need to be written by other means.


====Type=oneshot====
====<span id='oneshot'></span><tt>Type=oneshot</tt>====


If the Type is set to "oneshot", it is expected that the process configured with ExecStart= is the main process of the service and will exit before <tt>systemd</tt> starts follow-up units. However, if RemainAfterExit= is configured with "true", <tt>systemd</tt> will consider the service active even after the "ExecStart=" process had exited. You may want to specify the pair "ExecStop=" wrapper so <tt>systemd</tt> knows how to cleanly shut down the process. This is a typical pattern for a Java server started by a wrapper script.
If the <code>Type</code> is set to <code>oneshot</code>, it is expected that the process configured with <code>ExecStart</code> is the main process of the service and will exit before <tt>systemd</tt> starts follow-up units. However, if <code>RemainAfterExit</code> is configured with <code>true</code>, <code>systemd</code> will consider the service active even after the <code>ExecStart</code> process had exited. You may want to specify the pair <code>ExecStop</code> wrapper so <code>systemd</code> knows how to cleanly shut down the process. This is a typical pattern for a Java server started by a wrapper script.


Typical "oneshot" Service section:
Typical <code>oneshot</code> <code>[Service]</code> section:


<pre>
<syntaxhighlight lang='bash'>
...
...
[Service]
[Service]
Line 109: Line 121:
RemainAfterExit=true
RemainAfterExit=true
...
...
</pre>
</syntaxhighlight>


====Environment=====
====<span id='Environment.3D'></span><tt>Environment</tt>====
 
Environment variables can be declared with <code>Environment="variable_name=variable_value"</code> as follows:
Environment variables can be declared with <tt>Environment="variable_name=variable_value"</tt> as follows:
<syntaxhighlight lang='bash'>
 
<pre>
[Service]
[Service]
...
...
Environment="JAVA_HOME=/opt/java"
Environment="JAVA_HOME=/opt/java"
</pre>
</syntaxhighlight>


===[Install] Section===
Also see: {{Internal|Setting Environment Variables for a systemd Service|Setting Environment Variables for a systemd Service}}


<tt>WantedBy=multi-user.target</tt> means that the service should be started while in multi-user mode (equivalent with System V run level 3).
===<tt>[Install]</tt> Section===
<code>WantedBy=multi-user.target</code> means that the service should be started while in multi-user mode (equivalent with [[System_V#Level_3|System V runlevel 3]]).
==Create a Custom Unit File for a Service==
{{Internal|Custom_systemd_Unit_and_Unit_File#Overview|Custom systemd Unit and Unit File}}


=Environment=
=<span id='Service'></span>Services=


<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
For service management tasks. use service units. The associated files have a <code>.service</code> extension.
:[[#Environment.3D|<tt>Environment=</tt>]]
:[[Setting Environment Variable for a systemd Service]]
</blockquote>
 
=Query the Units Known to <tt>systemd</tt>=
 
To list all units known to systemd, use:
 
<pre>
systemctl list-units
</pre>
 
The command will list the units and their state.
 
To query units matching a certain pattern, use:
 
<pre>
systemctl list-units PATTERN
</pre>
 
=Services=
 
For service management tasks, the target unit is a ''service unit'', and their unit file have a <tt>.service</tt> suffix.


==Start (Enable) a Service Automatically at Boot==
==Start (Enable) a Service Automatically at Boot==
Line 156: Line 146:
To configure a service to start automatically at boot it must be enabled:
To configure a service to start automatically at boot it must be enabled:


<pre>
<syntaxhighlight lang='bash'>
systemctl enable <application>.service
systemctl enable <application>.service
</pre>
</syntaxhighlight>


This command creates a symbolic link from the service unit file, which is usually maintained in <tt>/lib/systemd/system</tt> into a location on disk where systemd looks for autostart files. This is usually a <tt>/etc/systemd/system/<some-target>.target.wants</tt> directory. See [[#Target|Target]].
This command creates a symbolic link from the service unit file, which, if it is a standard system service, it usually maintained in <code>/usr/lib/systemd/system</code>, into a location on disk where systemd looks for autostart files. This location usually is a <code>/etc/systemd/system/<some-target>.target.wants</code> directory. See [[#Target|Target]] for more details.


Example:
Example:


<pre>
<syntaxhighlight lang='bash'>
[root@openshift-master1 system]# systemctl enable docker
systemctl enable docker
ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'
# ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'
</pre>
</syntaxhighlight>


More: {{Internal|Systemctl#enable|systemctl enable}}
Also see: {{Internal|Systemctl#enable|<tt>systemctl enable</tt>}}


==Starting a Service==
==Starting a Service==


Starting a service means using <tt>systemctl</tt> to execute instructions in the service's unit file. It must be executed as root:
Starting a service means using <code>systemctl</code> to execute instructions in the service's unit file. It must be executed as root:


<pre>
<syntaxhighlight lang='bash'>
systemctl start <application>.service
systemctl start <application>.service
</pre>
</syntaxhighlight>
 
The short form


<pre>
The short form also works:
<syntaxhighlight lang='bash'>
systemctl start <application>
systemctl start <application>
</pre>
</syntaxhighlight>
 
See also: {{Internal|Systemctl#start|<tt>systemctl start</tt>}}
also works.
 
More: {{Internal|Systemctl#start|systemctl start}}


==Reload Configuration without a Restart==
==Reload Configuration without a Restart==
Line 193: Line 179:
If the service supports reloading configuration without actually restarting the service, use:
If the service supports reloading configuration without actually restarting the service, use:


<pre>
<syntaxhighlight lang='bash'>
systemctl reload <application>.service
systemctl reload <application>.service
</pre>
</syntaxhighlight>


==Restart a Service==
==Restart a Service==


<pre>
<syntaxhighlight lang='bash'>
systemctl restart <application>.service
systemctl restart <application>.service
</pre>
</syntaxhighlight>


==Reload or Restart a Service==
==Reload or Restart a Service==
 
If you are unsure whether the service has the configuration reload functionality, use the <code>reload-or-restart</code> command:
If you are unsure whether the service has the configuration reload functionality, use <tt>reload-or-restart</tt>:
<syntaxhighlight lang='bash'>
 
<pre>
systemctl reload-or-restart <application>.service
systemctl reload-or-restart <application>.service
</pre>
</syntaxhighlight>


==Stop (Disable) a Service==
==Stop (Disable) a Service==


<pre>
<syntaxhighlight lang='bash'>
systemctl disable <application>.service
systemctl disable <application>.service
</pre>
</syntaxhighlight>


==Status of a Service==
==Status of a Service==
Line 223: Line 207:
To check the status of a service run:
To check the status of a service run:


<pre>
<syntaxhighlight lang='bash'>
systemctl status <application>.service
systemctl status <application>.service
</pre>
</syntaxhighlight>


===Active===
===Active===
Line 231: Line 215:
A service can be active (running) or not active. To check whether a service is active (running), execute:
A service can be active (running) or not active. To check whether a service is active (running), execute:


<pre>
<syntaxhighlight lang='bash'>
systemctl is-active <application>.service
systemctl is-active <application>.service
</pre>
</syntaxhighlight>


This will return the current unit state as a string ("active" or "inactive"). The exit code will be "0" if it is active.
This will return the current unit state as a string ("active" or "inactive"). The exit code will be "0" if it is active.
Line 241: Line 225:
A service can be configured to start at boot (enabled) or not enabled. To check whether a service is enabled, execute:
A service can be configured to start at boot (enabled) or not enabled. To check whether a service is enabled, execute:


<pre>
<syntaxhighlight lang='bash'>
systemctl is-enabled <application>.service
systemctl is-enabled <application>.service
</pre>
</syntaxhighlight>


This will return the current unit enabled state as a string ("enabled" or "disabled"). The exit code will be "0" if it is enabled.
This will return the current unit enabled state as a string ("enabled" or "disabled"). The exit code will be "0" if it is enabled.
Line 251: Line 235:
systemctl can be used to check to see whether the service is in a failed state:
systemctl can be used to check to see whether the service is in a failed state:


<pre>
<syntaxhighlight lang='bash'>
systemctl is-failed <application>.service
systemctl is-failed <application>.service
</pre>
</syntaxhighlight>


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.
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.
==Service Unit File==
==Create a Custom Unit File for a Service==
{{External|http://jlk.fjfi.cvut.cz/arch/manpages/man/systemd.service.5}}
{{Internal|Custom_systemd_Unit_and_Unit_File#Overview|Custom systemd Unit and Unit File}}
Service unit files contain information about a process controlled and supervised by systemd. Service units installed by the system administrator are typically stored in <code>/etc/systemd/system/</code> directory, but this may vary depending on the Linux distribution.
 
=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=
 
A unit configuration file whose name ends in " .target " encodes information about a ''target unit'' of systemd, which is used for grouping units and as well-known synchronization points during start-up.


=Dependencies=
=Dependencies=
 
The dependencies are declared in the <code>[[#.5BUnit.5D_Section|[Unit]]]</code> section of the unit file.
See {{Internal|Systemd Declaring a Service Dependency|Declaring a Service Dependency}}
See {{Internal|Systemd Declaring a Service Dependency|Declaring a Service Dependency}}
==<tt>After</tt>==
==<tt>Before</tt>==
==<tt>Wants</tt>==
==<tt>Requires</tt>==


==After==
=<span id='Target'></span>Targets=
 
<font color=red>TODO</font>
 
==Before==
 
<font color=red>TODO</font>
 
==Wants==


<font color=red>TODO</font>
A <code>.target</code> is the configuration file for a [[#Unit|unit]] that provides a synchronization point for other units when booting up or changing state. Target units are used for grouping units and as well-known synchronization points during start-up.
 
==Requires==
 
<font color=red>TODO</font>


=systemd and network status=
=systemd and network status=
{{Internal|Linux systemd and Network Status|Linux systemd and Network Status}}
{{Internal|Linux systemd and Network Status|Linux systemd and Network Status}}
=Daemon Reload=
<code>systemctl</code> has a <code>daemon-reload</code> command, which reloads all <code>systemd</code> manager configuration. This will rerun all generators, reload all unit files and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.
<syntaxhighlight lang='bash'>
systemctl daemon-reload
</syntaxhighlight>


=journald=
=journald=

Latest revision as of 23:16, 19 August 2023

External

  • man systemd.service

Internal

Overview

systemd is a init system, a system and user space service manager for the Linux operating system. The purpose of an init system is to manage - initialize, start, stop - components in the user space, which are the programs that run after the kernel has booted. Some of those components are services and daemons that provide services.

systemd runs as the first process at boot, with PID 1, and acts as the init system that brings up and maintains the user-space services.

Unlike System V init, which starts services one at a time, moving to the next service after running dependency checks and waiting on the daemon to start, systemd can start services in parallel. It takes advantage of the daemon to daemon relationship in that dependent daemons do not actually need to be running, they only need the correct domain sockets to be available. systemd creates all sockets first, all the daemons second and any client requests to daemons not yet running are cached in the socket buffer and filled when the daemons come online.

systemd interprets its main configuration configuration file /etc/systemd/system.conf and the files in system.conf.d directories.

Differences between System V and systemd

Differences between System V and systemd

systemctl

systemctl is the central management tool for systemd. More operational details:

systemctl

Units

The resources managed by systemd are known as units. systemd provides a dependency system between units.

Units represent different types of resources. The units are defined in configuration files known as unit files. The unit type is given by the suffix of the corresponding unit file. There are 12 types of resources:

  • .service: A service unit describes how to manage a service or an application. This including starting and stopping the service, under which circumstance it should be automatically started and its dependencies. For more details, see the Services section, below.
  • .socket: A socket unit describes a network or IPC socket, or a FIFO buffer systemd uses for socket-based activation.
  • .device: A device unit describes a device that needs systemd management.
  • .mount: A mount unit defines a systemd-managed mountpoint.
  • .automount: Units that configure a mountpoint to be automatically mounted.
  • .swap: Units that describe the swap space on the system.
  • .target: A unit that provides a synchronization point for other units when booting up or changing state. For more details, see Targets section below.
  • .path: Units defining paths that can be used for path-based activation.
  • .timer: A timer unit defines a timer managed by systemd, similar to a cron job for delayed or scheduled activation. For more details see Timers section below.
  • .snapshot
  • .slice
  • .scope

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.

Query Known Units

To list all units known to systemd, use:

systemctl list-units

The command will list the units and their state.

To query units matching a certain pattern, use:

systemctl list-units PATTERN

Unit Files

Unit files are configuration files for units. They are not executable scripts. The type of each unit can be inferred from the suffix at the end of the file, as described in the Units section.

Unit File Location

The package maintainer unit files reside in /usr/lib/systemd/system (or /lib/systemd/system, as /lib is a symbolic link to /usr/lib).

The user-created unit files conventionally reside in /etc/systemd/system.

If a user wants to modify one of the default unit files, they should copy them in /etc/systemd/system, because systemd will give priority to /etc.

For more details see

man systemd-user.conf

Unit File Structure

A typical unit file is similar to:

[Unit]
Description=My Service
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/myserviced
PIDFile=/var/run/myservice.pid

[Install]
WantedBy=multi-user.target

[Unit] Section

The [Unit] section contains a description of the service and its dependency declarations.

In the example above, we declare that systemd must not attempt to start the service until the network is not running on the host. For more details on dependencies, see the Dependencies section, below. For more practical details on how to declare dependencies, see systemd Declaring a Service Dependency.

[Service] Section

Type can be set to one of simple, forking, oneshot, dbus, notify or idle.

Type=forking

ExecStart represents the path to the binary to execute when the service is started. The binary is expected to fork.

If set to "forking", it is expected that the process configured with ExecStart will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.

PIDFile takes an absolute file name pointing to the PID file of the service's daemon. PIDFile is recommended for services where Type is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. systemd uses this file to identify the main process of the daemon, but the file will need to be written by other means.

Type=oneshot

If the Type is set to oneshot, it is expected that the process configured with ExecStart is the main process of the service and will exit before systemd starts follow-up units. However, if RemainAfterExit is configured with true, systemd will consider the service active even after the ExecStart process had exited. You may want to specify the pair ExecStop wrapper so systemd knows how to cleanly shut down the process. This is a typical pattern for a Java server started by a wrapper script.

Typical oneshot [Service] section:

...
[Service]
Type=oneshot
ExecStart=/usr/lib/systemd/scripts/activemq start
ExecStop=/usr/lib/systemd/scripts/activemq stop
RemainAfterExit=true
...

Environment

Environment variables can be declared with Environment="variable_name=variable_value" as follows:

[Service]
...
Environment="JAVA_HOME=/opt/java"

Also see:

Setting Environment Variables for a systemd Service

[Install] Section

WantedBy=multi-user.target means that the service should be started while in multi-user mode (equivalent with System V runlevel 3).

Create a Custom Unit File for a Service

Custom systemd Unit and Unit File

Services

For service management tasks. use service units. The associated files have a .service extension.

Start (Enable) 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, if it is a standard system service, it usually maintained in /usr/lib/systemd/system, into a location on disk where systemd looks for autostart files. This location usually is a /etc/systemd/system/<some-target>.target.wants directory. See Target for more details.

Example:

systemctl enable docker
# ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'

Also see:

systemctl enable

Starting a Service

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

systemctl start <application>.service

The short form also works:

systemctl start <application>

See also:

systemctl start

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 the reload-or-restart command:

systemctl reload-or-restart <application>.service

Stop (Disable) a Service

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.

Create a Custom Unit File for a Service

Custom systemd Unit and Unit File

Dependencies

The dependencies are declared in the [Unit] section of the unit file.

See

Declaring a Service Dependency

After

Before

Wants

Requires

Targets

A .target is the configuration file for a unit that provides a synchronization point for other units when booting up or changing state. Target units are used for grouping units and as well-known synchronization points during start-up.

systemd and network status

Linux systemd and Network Status

Daemon Reload

systemctl has a daemon-reload command, which reloads all systemd manager configuration. This will rerun all generators, reload all unit files and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.

systemctl daemon-reload

journald

journald Concepts

Timers

systemctl list-timers

Timer Unit File

Timer unit files contain information about a timer controlled and supervised by systemd. By default, a service with the same name as the timer is activated. Also see service unit file.

For an example, see:

Let's Encrypt | Enable Automatic Renewal by Hand