How can I determine, within a shell script, whether it is being called by systemd or not?

Question

We have a shell script that -- for various reasons -- wraps a vendor's application. We have system administrators and application owners who have mixed levels of familiarity with systemd. As a result, in situations where the application has failed (systemctl indicates as much), some end users (including “root” system administrators) might start an application “directly” with the wrapper script instead of using systemctl restart. This can cause issues during reboots, because systemd does not call the proper shutdown script -- because as far as it's concerned, the application was already stopped.

To help guide the transition to systemd, I want to update the wrapper script to determine whether it is being called by systemd or by an end-user; if it's being called outside systemd, I want to print a message to the caller, telling them to use systemctl.

How can I determine, within a shell script, whether it is being called by systemd or not?

You may assume:

• a bash shell for the wrapper script
• the wrapper script successfully starts and stops the application
• the systemd service works as expected

An example of the systemd service could be:

[Unit]
Description=Vendor's Application 
After=network-online.target
[Service]
ExecStart=/path/to/wrapper start
ExecStop=/path/to/wrapper stop
Type=forking
[Install]
WantedBy=multi-user.target

I am not interested in Detecting the init system, since I already know it's systemd.

Answer 1

From Lucas Werkmeister's informative answer on Server Fault:

• With systemd versions 231 and later, there's a JOURNAL_STREAM variable that is set for services whose stdout or stderr is connected to the journal.
• With systemd versions 232 and later, there's an INVOCATION_ID variable that is set.

If you don't want to rely on those variables, or for systemd versions before 231, you can check if the parent PID is equal to 1:

if [[ $PPID -ne 1 ]]
then
  echo "Don't call me directly; instead, call 'systemctl start/stop service-name'"
  exit 1
fi >&2

Answer 2

The Short Answer

if ! grep -qEe '[.]service$' /proc/self/cgroup; then
    echo "This script should be started with systemctl" >&2
    exit 1
fi

...or, if you know the specific service name you're expected to run as, and want to be robust against misconfigurations that prevent a user session from being created:

if ! grep -qEe '/myservice[.]service$' /proc/self/cgroup; then
    echo "This service should be started with systemctl start myservice" >&2
    exit 1
fi

---

Why It Works

One way to determine which service -- if any -- started the current process is checking /proc/self/cgroup. For a systemd-triggered service, this will contain the service name; for example:

12:pids:/system.slice/dhcpcd.service
11:rdma:/
10:memory:/system.slice/dhcpcd.service
9:blkio:/system.slice/dhcpcd.service
8:devices:/system.slice/dhcpcd.service
7:hugetlb:/
6:cpuset:/
5:freezer:/
4:cpu,cpuacct:/system.slice/dhcpcd.service
3:net_cls,net_prio:/
2:perf_event:/
1:name=systemd:/system.slice/dhcpcd.service
0::/system.slice/dhcpcd.service

...whereas for a process associated with a user's session, the cgroup will be something more like /user.slice/user-1000.slice/session-337.scope (assuming that this is the user with UID 1000's 337th session on the system since its last reboot).

---

A Fancier Implementation

If one wants to detect the specific service being run as, this too can be extracted from /proc/self/cgroup. Consider, for example:

cgroup_full=$(awk -F: '$1 == 0 { print $3 }' /proc/self/cgroup)
cgroup_short=${cgroup_full##*/}
case $cgroup_full in
  /system.slice/*.service) echo "Run from system service ${cgroup_short%.*}";;
  /user.slice/*.service)   echo "Run from user service ${cgroup_short%.*}";;
  *.service)               echo "Service ${cgroup_short%.*} type unknown";;
  *)                       echo "Not run from a systemd service; in $cgroup_full";;
esac

Answer 3

Another obvious solution that comes to mind is to add something like

Environment=FROM_SYSTEMD=1

to the service file, and test on that envvar.

Answer 4

I like Jeff Schaller's answer, which is probably The Right Thing™. Another approach could be to use two scripts. Move the actual wrapper from /path/to/wrapper to some other filename, and use that name in the systemd unit file. And then create another script, with the original name, that does nothing but display a helpful error message.

Answer 5

Another approach may be to query systemd explicitly, to obtain more tightly-coupled checks.

For instance, for analogous use-cases I have been doing like this:

if [ "$(systemctl show -p ControlPID vendorservice)" != "ControlPID=$$" ]; then
    echo 'no go'
    exit 1
fi

The snippet above works only for type=forking services because it leverages the particular states that that kind of job can be in during its lifetime.

Specifically, it queries the ControlPID value set by systemd that, for type=forking jobs, indicates the process spawn directly by systemd itself in the meantime it is waiting for the PIDFile to appear (or GuessMainPID to retrieve something), after which the ControlPID value is set back to 0. This particular behavior by systemd should also protect that check against possible PID wraparounds.

There are many properties that can be retrieved through systemctl show, some of which vary depending on the specific type= used, so for service types other than type=forking, and/or depending on the specific use-case, it may be a matter of querying the most appropriate one(s) to perform equivalent "tethering" checks.

So this one here is not a generic solution, but it is possibly more robust and backwards compatible¹ as well as future-proof².

Note also that you must already know the correct service name to query, and particularly for instance services you need to know the exact instance name (like vendorservice@1) to query.

---

¹ the ControlPID property and the systemctl show command with its the -p option have always existed since the first release of systemd

² systemctl show output is part of the stability promise