On 02.12.2012 22:11, Michael Biebl wrote: > On 02.12.2012 22:04, Salvo Tomaselli wrote: >> >>> if start-stop-daemon -K --retry=TERM/30/KILL/5 -o -q -p $PIDFILE -x >>> $DAEMON -u $USER; then >> Okay, it seems to be working now, but also seemed to be working in general, >> the problem doesn't occur every time... > > that's the nature of race conditions :-) > > Some explanation why you see different behaviour between sysvinit and > systemd: > systemd internally translates "restart" to "stop + start", i.e. it calls > /etc/init.d/foo stop && /etc/init.d/foo start. > That's why the "sleep 1" hack is only active under sysvinit. > I bet, if you removed the "sleep 1" in restart), you'd run into the same > problem under sysvinit. > > In the end, those are just bugs in the sysv init scripts which are > papered over by sprinkling a sleep here and there.
I guess we can conclude that this is a bug in the fetchmail sysv init script and should best be addressed there using --retry in a proper way. That said, I did a quick grep over the 1194 sysv init scripts [1] we have in Debian and found 1101 occurrences of "sleep" [2]. So I was wondering if we should implement a workaround in systemd and insert an explicit "sleep 1" on systemctl restart between stop and start for LSB/sysv type services (or some other workaround). The right place of course to fix those types of bugs is in the sysv init scripts themselves. With that many potentially affected packages this can become quite tedious though. Michael [1] http://people.debian.org/~biebl/init-2012-10-14.tar.gz [2] grep "\<sleep\>" */*/* | wc -l -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
