jmoellers at suse.de
Thu Apr 18 19:41:45 UTC 2019
On 18.04.19 18:17, Felipe Sateler wrote:
> On Thu, 18 Apr 2019 14:21:09 +0200, Josef Moellers wrote:
>> We're currently working on a bug which afaict is due to a race
>> 1) systemd starts xenstored.service
>> 2) /etc/xen/scripts/launch-xenstore does its work (starts /usr/lib/xen/
>> 3) /etc/xen/scripts/launch-xenstore runs "systemd-notify --ready"
>> 4) "systemd-notify --ready" sends a UDP-message to systemd 5)
>> /etc/xen/scripts/launch-xenstore exits 6) systemd gets SIGCHLD and
>> removes the PID from watch_pids
>> 7) systemd receives the UDP message, but
>> a) the process is gone b) the PID is not in watch_pids any more.
>> 8) "Cannot find unit for notify message of PID..."
>> 9) No start of depending units.
>> I see no proper way to get out of this but to make the systemd-notify
>> synchronous rather than fire-and-forget and expect it to wait for a
>> response from systemd.
> If the launch-xenstore script starts a daemon and then exists: why not
> make the unit Type=forking and thus forget about systemd-notify --ready ?
The problem is that there is no PID to look after: xenstorage runs in
another guest, so in the scope of systemd it simply has no PID.
But we think that we found the problem: a patch, which straighted out
handling of SIGCHLD and sd-notify messages, hadn't (yet) been included
in that version of systemd.
Lennart's reply pointed the way.
Thanks anyway to all who have spent some time thinking about the issue.
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
More information about the systemd-devel