В Thu, 14 Aug 2014 19:24:54 +0200 Lennart Poettering <lenn...@poettering.net> пишет:
> On Thu, 14.08.14 21:16, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > > > В Thu, 14 Aug 2014 14:24:49 +0200 > > Lennart Poettering <lenn...@poettering.net> пишет: > > > > > On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: > > > > > > > but that still don't explain why "ExecStopPost=/sur/bin/true" or > > > > whatever "ExecStopPost" solves that and if it is not supported > > > > why "systemctl" don't return after the one and only process > > > > exited > > > > > > Well, this is a misunderstanding how ExecStop= and friends are supposed > > > to work. They are supposed to do what they did on sysvinit: > > > synchronously terminate a service. And not asynchronously do that. > > > > I have to ask again - why is forcing every package to re-implement busy > > loop waiting for process to exit better than doing this wait in one > > place - PID 1 - which is the most natural place to do it? > > Which is what we do. Except when you specify ExecStop= which basically > tells systemd that you want to do it instead. So there you go! > Those daemons I have seen are terminated after receiving signal/command to do it. Those sysvinit scripts that "synchronously" terminated services did it by implementing wait for daemon process to exit. What is worse, the only way to do it is busy looping as they cannot normally receive notification about process exit. So currently package author who needs to be sure daemon have enough time to finish housekeeping have choice between a) implement custom busy looping a la sysvinit script b) implement custom synchronous protocol between daemon and external program that somehow connects to daemon and blocks until daemon is terminated Compare this with "send daemon command - signal or whatever - and wait until it exits". This needs to be implemented just once in PID 1 - and PID 1 already does exactly this most of the time anyway. Why is this the wrong thing to do? You never explained this when you rejected my patch. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel