[systemd-devel] Notify type service as non-root user fails

[Lennart Poettering]

On Mo, 15.07.19 13:33, KIESEL, BRIAN S (bk9825 at att.com) wrote:

> I have a simple example of a service unit and bash script on rhel7
> using Type=notify that I was trying to get working.  When the
> service unit is configured to start the script as root things work
> as expected.  When adding User=testuser it fails.  While the script
> initially starts (as seen on process list), Journalct -xe reports
> many lines like the following and the service eventually timesout.
> I am not even clear what these referenced PIDs are associated with
> as they don't exist in the process list.

So this is messy:

sd_notify() messages always originate from a process identified by a
PID. The kernel will implicitly attach this info to all messages, but
privileged userspace can override it if it likes. The originating PID
of a message is then used by systemd to find the cgroup of the process
and with that the unit the message belongs to. This is racy for
processes down the tree that send a message and die quickly, because
systemd doesn't directly watch such processes (it directly watches
only the "main" process of a service) and can only use the cgroup of
the PID to make sense of it. If by the time systemd tries to figure
this out the process already died the data from /proc/$PID/cgroup is
already gone, and you get the message you are seeing. Now, the
"systemd-notify" binary knows this, and tries to override the sending
PID for its messages to be its immediate parent's PID instead, so that
systemd sees the program systemd-notify is invoked from as originator,
and not systemd-notify itself. That kind of overriding only works if
systemd-notify itself is privileged however. If it isn't, then it
won't work, and the actual systemd-notify PID is used as originator.

There's little we can do about this. Ideally the kernel would just
pass the cgroup of the orignator directly to us. If we'd get that the
problem would be gone (and a couple of others too):

https://github.com/systemd/systemd/issues/2913

Lennart

--
Lennart Poettering, Berlin