systemctl does have a mode suitable for scripting; use
show rather than
status, and add the
--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 (or otherwise) is a
SubState. If you want to know whether a service is active, use the property
$ systemctl show -p ActiveState --value x11-common
$ systemctl show -p SubState --value x11-common
Notes from the
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.
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
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
systemctl show -a polkit
The possible values for
SubState are unfortunately undocumented in the manpage(s); instead they are documented in the D-Bus interface description for
LoadState contains a state value that reflects whether the configuration file of this unit has been loaded. The following states are currently defined: "
error", and "
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: "
activating", and "
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
ActiveEnterTimestamp=Thu 2020-07-02 07:24:40 IST