Bug 75680

Summary:	systemd-notify notifications often lost
Product:	systemd	Reporter:	Jan Alexander Steffens (heftig) <jan.steffens>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	normal
Priority:	medium	CC:	benjarobin+freedesktop
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Jan Alexander Steffens (heftig) 2014-03-02 19:20:54 UTC

I have a shell script service here using systemd-notify for readiness and watchdog, with NotifyAccess=all. In the journal I often see messages like "systemd[1]: Cannot find unit for notify message of PID 9834", with subsequent watchdog timeouts by my service.

Is systemd trying to find out the unit of the notification sender, but the sender (a forked systemd-notify) has already terminated?

Sometimes it even happens when the service is started, so the READY message is lost.

I think this currently makes systemd-notify useless.

systemd 210

Comment 1 Lennart Poettering 2014-05-24 09:22:45 UTC

One option would be to change systemd-notify to fake the ucred bits of the message systemd-notify sends to contain the PID of the parent of the process, rather than its own. This will not fix the issue fully, but it will fix many instances of it, where the parent process is long-running, where it usually is.

Comment 2 Zbigniew Jedrzejewski-Szmek 2014-06-21 03:38:50 UTC

(In reply to comment #1)
> One option would be to change systemd-notify to fake the ucred bits of the
> message systemd-notify sends to contain the PID of the parent of the
> process, rather than its own. This will not fix the issue fully, but it will
> fix many instances of it, where the parent process is long-running, where it
> usually is.
This is implemented in http://cgit.freedesktop.org/systemd/systemd/commit/?id=be8f4e9e.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.