systemctl
does have a mode suitable for scripting; use show
rather than status
, and add the -p
/ --properties
and --value
options to get only the output you want.
Here's an example (from an Ubuntu 17.04 system):
$ systemctl show -p SubState --value NetworkManager
running
Running (or otherwise) is a SubState
. If you want to know whether a service is active, use the property ActiveState
$ systemctl show -p ActiveState --value x11-common
inactive
$ systemctl show -p SubState --value x11-common
dead
Notes from the man
:
show [PATTERN...|JOB...]
Show properties of one or more units, jobs, or the manager
itself. If no argument is specified, properties of the
manager will be shown. If a unit name is specified, properties
of the unit are shown, and if a job ID is 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.
-p, --property=
When showing unit/job/manager properties with the show command,
limit display to properties specified in the argument. The
argument should be a comma-separated list of property names,
such as "MainPID". Unless specified, 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.
--value
When printing properties with show, only print the value, and
skip the property name and "=".
To see available properties for a service, run (for example, for polkit
)
systemctl show -a polkit
The possible values for LoadState
, ActiveState
and SubState
are unfortunately undocumented in the manpage(s); instead they are documented in the D-Bus interface description for org.freedesktop.systemd1
: https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html
LoadState
contains a state value that reflects whether the configuration file of this unit has been loaded. The following states are currently defined: "loaded
", "error
", and "masked
". "loaded
" indicates that the configuration was successfully loaded. "error
" indicates that the configuration failed to load. The LoadError
field (see below) contains information about the cause of this failure. "masked
" indicates that the unit is currently masked out (i.e. symlinked to /dev/null
or empty). Note that the LoadState
is fully orthogonal to the ActiveState
(see below) as units without valid loaded configuration might be active (because configuration might have been reloaded at a time where a unit was already active).
ActiveState
contains a state value that reflects whether the unit is currently active or not. The following states are currently defined: "active
", "reloading
", "inactive
", "failed
", "activating
", and "deactivating
". "active
" indicates that unit is active (obviously...). "reloading
" indicates that the unit is active and currently reloading its configuration. "inactive
" indicates that it is inactive and the previous run was successful or no previous run has taken place yet. "failed
" indicates that it is inactive and the previous run was not successful (more information about the reason for this is available on the unit type specific interfaces, for example for services in the Result property, see below). "activating
" indicates that the unit has previously been inactive but is currently in the process of entering an active state. Conversely "deactivating
" indicates that the unit is currently in the process of deactivation.
SubState
encodes states of the same state machine that ActiveState
covers, but knows more fine-grained states that are unit-type-specific. Where ActiveState
only covers six high-level states, SubState
covers possibly many more low-level unit-type-specific states that are mapped to the six high-level states. Note that multiple low-level states might map to the same high-level state, but not vice versa. Not all high-level states have low-level counterparts on all unit types. At this point the low-level states are not documented here, and are more likely to be extended later on than the common high-level states explained above.
There are many properties, so if you know what you're looking for...
$ systemctl show - polkit | grep Active
ActiveState=active
ActiveEnterTimestamp=Thu 2020-07-02 07:24:40 IST
ActiveEnterTimestampMonotonic=6682102
ActiveExitTimestamp=
ActiveExitTimestampMonotonic=0