> 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. Hm it makes sense...
> In the end, those are just bugs in the sysv init scripts which are > papered over by sprinkling a sleep here and there. Well since bash programming isn't C or Python and there are no callbacks, usually in bash functions (which are executable files) should be synchronous rather than asynchronous. Start-stop-daemon terminates when the signal has been sent, not when the process has terminated, waiting for the process to terminate would make the scripts easier. After all they are trying to stop a daemon not to send a signal, so they are interested in the effective termination of the process. In alternative all the scripts should do the following: start-stop-daemon --stop && (waitpid; start-stop-daemon --start) Which is quite unreadable as pseudo-bash-code, it would be even worst as real working bash. The sleep is just a poor workaround for a problem in start-stop-daemon, by putting a waitpid in it, all those sleeps during the restart could be safely eliminated. -- Salvo Tomaselli
signature.asc
Description: This is a digitally signed message part.
