On Mo, 15.07.19 13:33, KIESEL, BRIAN S (bk9825@xxxxxxx) 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel