systemctl – Control the systemd system and service manager
systemctl enable /path/to/my-service-file.serivce
systemctl [OPTIONS...] COMMAND [NAME...]
systemctl may be used to introspect and control the state of the “systemd” system and service manager. Please refer to systemd(1) for an introduction into the basic concepts and functionality this tool manages.
all known properties are shown. If specified more than once, all properties with the specified names are shown. Shell completion is implemented for property names.
Properties for units are documented in systemd.unit(5), and the pages for individual unit types systemd.service(5), systemd.socket(5), etc.
systemd.target(5)), and as a result of other directives (for example RequiresMountsFor=). Both explicitly and implicitly introduced dependencies are shown with list-dependencies.
to “replace”, except when the isolate command is used which implies the “isolate” job mode.
irreversible jobs are still pending). Irreversible jobs can still be cancelled using the cancel command.
dependencies will be honored. This is mostly a debugging and rescue tool for the administrator and should not be used by applications.
shutdown or a sleep state. Any user may take these locks and privileged users may override these locks. If any locks are taken, shutdown and sleep state requests will normally fail (regardless of whether privileged or
not) and a list of active locks is printed. However, if –ignore-inhibitors is specified, the locks are ignored and not printed, and the operation attempted anyway, possibly requiring additional privileges.
is only verified and enqueued. This option may not be combined with –wait.
particularly services which use “RemainAfterExit=yes”.
Unless this option is specified and the command is invoked from a terminal, systemctl will query the user on the terminal for the necessary secrets. Use this option to switch this behavior off. In this case, the password
must be supplied by some other means (for example graphical password agents) or the service might fail. This also disables querying the user for authentication for privileged operations.
the unit is the one that defines the life-time of it. A control process of a unit is one that is invoked by the manager to induce state changes of it. For example, all processes started due to the ExecStartPre=,
ExecStop= or ExecReload= settings of service units are control processes. Note that there is only one control process per unit at a time, as only one state change is executed at a time. For services of type Type=forking,
the initial process started by the manager for ExecStart= is a control process, while the process ultimately forked off by that one is then considered the main process of the unit (if it can be determined). This is
different for service units of other types, where the process forked off by the manager for ExecStart= is always the main process itself. A service unit consists of zero or one main process, zero or one control process
plus any number of additional processes. Not all unit types manage processes of these types however. For example, for mount units, control processes are defined (which are the invocations of /bin/mount and /bin/umount),
but no main process is defined. If omitted, defaults to all.
This is hence a drastic but relatively safe option to request an immediate reboot. If –force is specified twice for these operations (with the exception of kexec), they will be executed immediately, without terminating
any processes or unmounting any file systems. Warning: specifying –force twice with any of these operations might result in data loss. Note that when –force is specified twice the selected operation is executed by
systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager hangs or crashed.
communicating with the systemd daemon to carry out changes.
/run, with identical immediate effects, however, since the latter is lost on reboot, the changes are lost too.
specific container on the specified host. This will use SSH to talk to the remote machine manager instance. Container names may be enumerated with machinectl -H HOST.
The following commands are understood:
past and have failed. By default only units which are active, have pending jobs, or have failed are shown; this can be changed with option –all. If one or more PATTERNs are specified, only units matching one of them are
shown. The units that are shown are additionally filtered by –type= and –state= if those options are specified.
/dev/initctl systemd-initctl.socket systemd-initctl.service
[::]:22 sshd.socket sshd.service
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
addition, in case of instantiated units, systemd is often unaware of the instance name until the instance has been started. Therefore, using glob patterns with start has limited usefulness. Also, secondary alias names of
units are not considered.
you are currently using.
(subject to limitations specified with -t). If a PID is passed, show information about the unit the process belongs to.
terminal window. This can be changed with –lines and –full, see above. In addition, journalctl –unit=NAME or journalctl –user-unit=NAME use a similar filter for messages and might be more convenient.
specified, properties of the job are shown. By default, empty properties are suppressed. Use –all to show those too. To select specific properties to show, use –property=. This command is intended to be used whenever
computer-parsable output is required. Use status if you are looking for formatted human-readable output.
but many resource control settings (primarily those in systemd.resource-control(5)) may. The changes are applied instantly, and stored on disk for future boots, unless –runtime is passed, in which case the settings only
apply until the next reboot. The syntax of the property assignment follows closely the syntax of assignments in unit files.
reset the list.
out), it will automatically enter the “failed” state and its exit code and status is recorded for introspection by the administrator until the service is restarted or reset with this command.
Unit File Commands
matching unit file system paths are not supported).
is reloaded (in a way equivalent to daemon-reload), in order to ensure the changes are taken into account immediately. Note that this does not have the effect of also starting any of the units being enabled. If this is
desired, combine this command with the –now switch, or invoke start with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of the form
firstname.lastname@example.org), symlinks named
the same as instances are created in the unit configuration directory, however they point to the single template unit file they are instantiated from.
read directly). If a specified unit file is located outside of the usual unit file directories, an additional symlink is created, linking it into the unit configuration path, thus ensuring it is found when requested by
commands such as start.
free to make additional changes manually by placing or removing symlinks below this directory. This is particularly useful to create configurations that deviate from the suggested default installation. In this case, the
administrator must make sure to invoke daemon-reload manually as necessary, in order to ensure the changes are taken into account.
enabled. Enabling simply hooks the unit into various suggested places (for example, so that the unit is automatically started on boot or when a particular kind of hardware is plugged in). Starting actually spawns the
daemon process (in case of service units), or binds the socket (in case of socket units), and so on.
only this boot. Note that in the last case, no systemd daemon configuration is reloaded.
symlinks to matching unit files, including manually created symlinks, and not just those actually created by enable or link. Note that while disable undoes the effect of enable, the two commands are otherwise not
symmetric, as disable may remove more symlinks than a prior enable invocation of the same unit created.
command with the –now switch, or invoke the stop command with appropriate arguments later.
section. This command expects a unit name only, it does not accept paths to unit files.
listed in the preset files.
output, use –quiet. To show installation targets, use –full.
│Name │ Description │ Exit Code │
│”enabled” │ Enabled via .wants/, .requires/ or alias symlinks │ │
├──────────────────┤ (permanently in /etc/systemd/system/, or transiently in │ 0 │
│”enabled-runtime” │ /run/systemd/system/). │ │
│”linked” │ Made available through one or more symlinks to the unit │ │
├──────────────────┤ file (permanently in /etc/systemd/system/ or transiently │ > 0 │
│”linked-runtime” │ in /run/systemd/system/), even though the unit file might │ │
│ │ reside outside of the unit file search path. │ │
│”masked” │ Completely disabled, so that any start operation on it │ │
├──────────────────┤ fails (permanently in /etc/systemd/system/ or transiently │ > 0 │
│”masked-runtime” │ in /run/systemd/systemd/). │ │
│”static” │ The unit file is not enabled, and has no provisions for │ 0 │
│ │ enabling in the “[Install]” unit file section. │ │
│”indirect” │ The unit file itself is not enabled, but it has a │ 0 │
│ │ non-empty Also= setting in the “[Install]” unit file │ │
│ │ section, listing other unit files that might be enabled. │ │
│”disabled” │ The unit file is not enabled, but contains an “[Install]” │ > 0 │
│ │ section with installation instructions. │ │
│”generated” │ The unit file was generated dynamically via a generator │ 0 │
│ │ tool. See systemd.generator(7). Generated unit files may │ │
│ │ not be enabled, they are enabled implicitly by their │ │
│ │ generator. │ │
│”transient” │ The unit file has been created dynamically with the │ 0 │
│ │ runtime API. Transient units may not be enabled. │ │
│”bad” │ The unit file is invalid or another error occurred. Note │ > 0 │
│ │ that is-enabled will not actually return this state, but │ │
│ │ print an error message instead. However the unit file │ │
│ │ listing printed by list-unit-files might show it. │ │
activation of the unit, including enablement and manual activation. Use this option with care. This honors the –runtime option to only mask temporarily until the next reboot of the system. The –now option may be used
to ensure that the units are also stopped. This command expects valid unit names only, it does not accept unit file paths.
is that a unit file is made available for commands such as start, even though it is not installed directly in the unit search path.
unit file. Specifically, for a unit “foo.service” the matching directories “foo.service.d/” with all their contained files are removed, both below the persistent and runtime configuration directories (i.e. below
/etc/systemd/system and /run/systemd/system); if the unit file has a vendor-supplied version (i.e. a unit file located below /usr) any matching persistent or runtime unit file that overrides it is removed, too. Note that
if a unit file has no vendor-supplied version (i.e. is only defined below /etc/systemd/system or /run/systemd/system, but not in a unit file stored below /usr), then it is not removed. Also, if a unit is masked, it is
the editor (see the “Environment” section below) is invoked on temporary files which will be written to the real location if the editor exits successfully.
the specified value.
environment variable names should be passed, whose client-side values are then imported into the manager’s environment block.
Manager Lifecycle Commands
Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible.
returned otherwise (exit code non-zero). In addition, the current state is printed in a short string to standard output, see the table below. Use –quiet to suppress this output.
│Name │ Description │ Exit Code │
│initializing │ Early bootup, before basic.target is reached or the │ > 0 │
│ │ maintenance state entered. │ │
│starting │ Late bootup, before the job queue becomes idle for the │ > 0 │
│ │ first time, or one of the rescue targets are reached. │ │
│running │ The system is fully operational. │ 0 │
│degraded │ The system is operational but one or more units failed. │ > 0 │
│maintenance │ The rescue or emergency target is active. │ > 0 │
│stopping │ The manager is shutting down. │ > 0 │
│offline │ The manager is not running. Specifically, this is the │ > 0 │
│ │ operational state if an incompatible program is running as │ │
│ │ system manager (PID 1). │ │
│unknown │ The operational state could not be determined, due to lack │ > 0 │
│ │ of resources or another error cause. │ │
skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the system halt. If –force is specified twice, the operation is immediately executed without
terminating any processes or unmounting any file systems. This may result in data loss. Note that when –force is specified twice the halt operation is executed by systemctl itself, and the system manager is not
contacted. This means the command should succeed even when the system manager hangs or crashed.
services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the powering off. If –force is specified twice, the operation is immediately
executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when –force is specified twice the power-off operation is executed by systemctl itself, and the system
manager is not contacted. This means the command should succeed even when the system manager hangs or crashed.
is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the reboot. If –force is specified twice, the operation is immediately executed without
terminating any processes or unmounting any file systems. This may result in data loss. Note that when –force is specified twice the reboot operation is executed by systemctl itself, and the system manager is not
contacted. This means the command should succeed even when the system manager hangs or crashed.
recovery, and “fota” might be used to trigger a “firmware over the air” update.
services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the reboot.
“init” process) to the main system manager process which is loaded from the actual host volume. This call takes two arguments: the directory that is to become the new root directory, and the path to the new system
manager binary below it to execute as PID 1. If the latter is omitted or the empty string, a systemd binary will automatically be searched for and used as init. If the system manager path is omitted, equal to the empty
string or identical to the path to the systemd binary, the state of the initrd’s system manager process is passed to the main system manager, which allows later introspection of the state of the services involved in the
initrd boot phase.
suffix is not specified (unit name is “abbreviated”), systemctl will append a suitable suffix, “.service” by default, and a type-specific suffix in case of commands which operate only on specific unit types. For example,
# systemctl status /home
# systemctl status home.mount
unit names always refer to exactly one unit, but globs may match zero units and this is not considered an error.
patterns which do not match anything are silently skipped. For example:
execute well known editors in this order: editor(1), nano(1), vim(1), vi(1).
If no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string or the value “cat” is equivalent to passing –no-pager.
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)
man 1 systemctl, Version systemd 232
configuration – Systemd service files in non-default directory – Ask Ubuntu