[systemd-devel] systemd-notify --ready is not reliable

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 23, 2014 at 08:50:34PM +0200, Lennart Poettering wrote:
> On Wed, 23.04.14 15:15, Eelco Dolstra (eelco.dolstra at logicblox.com) wrote:
> 
> > Hi all,
> > 
> > I've noticed that the command "systemd-notify --ready" does not work reliably to
> > signal that a service is ready. It works sometimes, but most of the time you get
> > a message like:
> > 
> >   systemd[1]: Cannot find unit for notify message of PID 3137.
> > 
> > in the journal, and the service stays in the "activating" state.
> > 
> > The reason is that systemd-notify sends its message asynchronously and exits
> > immediately. So by the time systemd processes the message, systemd-notify has
> > probably already exited, and so systemd cannot gets cgroup. (Note that this
> > affects other systemd-notify messages as well, but for --ready it's particularly
> > bad because it causes services to "hang" in the "activating" state.)
> > 
> > Any suggestions what to do about this? I can see a few solutions:
> 
> There is ongoing work to fix the kernel to add SCM_CGROUPS for us to
> messages. With that in place we have a race-free way to get this data
> for incoming messages. I have some hopes that this will soonishly enter
> the kernel, but then again, this story has been cookie for the past 5
> years to no successs...
What about simply waiting in the background for 10s? An ugly workaround,
but should fix the issue until we have something better.

Zbyszek