Hi, I'm looking for suggestion on how to enhance start-stop-daemon --wait N --pidfile behavior. Currently in apache init script we do following: start-stop-daemon --start -- ${APACHE2} ${APACHE2_OPTS} -k start i=0 while [ ! -e "${PIDFILE}" ] && [ $i -lt ${TIMEOUT} ]; do sleep 1 && i=$(expr $i + 1) done eend $(test -e "${PIDFILE}") But wait! If --wait N and --pidfile PIDFILE options are passed to start-stop-daemon it checks for PIDFILE existence after N miliseconds. So actually it does the same and the only problem that I see with current s-s-d implementation is that if timeout N is long enough (and it should be to be reliable), like: start-stop-daemon --start --pidfile "${PIDFILE}" \ --wait 10000 -- ${APACHE2} ${APACHE2_OPTS} -k start init script will sleep for 10 seconds (while on my system about 700 miliseconds is enough to create PIDFILE. So I'd like s-s-d to check for PIDFILE periodically. But thinking about this issue I found multiple possible solutions: 1. hardcode number of polling intervals (say 10 or 20) and check for PIDFILE every N/10 ms. 2. Update --wait syntax like: N[/T] and once /T is provided we'll check for PIDFILE every N/T ms. 3. Update --wait syntax like: N[/P] and once /P is provided we'll check for PIDFILE every P ms. 4. Provide default polling interval (like 100ms) and check for PIDFILE every 100ms. Also I think it's good idea to add inotify support for linux systems. Any other options? In any case looks like current implementation of --wait is not widely used (due to this problem I guess) so we can do whatever we want :) I'd like to hear any input before I start to code this.
let's use inotify and skip the whole polling concept
(In reply to comment #1) > let's use inotify and skip the whole polling concept We can do that for linux systems that have inotify, but we should also support those who aren't using it and bsd systems. I would vote for having the polling concept, but also supporting inotify. This is my first shot at the syntax, but something like: --wait n/t would wait a maximum of n seconds, but check every t interval for the existance of the pid file. The question here would be, what should t be measured in (ms or seconds)? --wait n would wait for a maximum number of seconds, with a possible default polling interval. --wait 0 (the number zero) would use inotify if it is available. The question here would be what should this do on a non-linux system or if inotify is not available?
i think you missed the point a bit. there should be no need for any extended --wait syntax. that would mean updating everyone who uses --wait to add the new syntax, and there's no real good way of figuring out a balance -- what is too high a period or too low. this needs to "just work". if the target supports some sort of notification mechanism, it will simply use it. if the target is Linux, that means inotify. if the target is FreeBSD, that means kqueue/kevent. if the target doesn't support anything, then it either does nothing (i.e. what we already do today), or if you really want, have it autopoll something like max(1, period/10).
and i'm not suggesting we have to go through and implement all these backends. we simply provide the framework. when interested parties (i.e. people who care about FreeBSD/etc...) get around to it, they can implement the piece and send it to us.
in the recent commit 9afdf5066766 by idl0r http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commit;h=9afdf50667661812be936fe6d3b3a939b0c54061 the daemon that is slow enough creating pidfile trigger error messages, which were hided by --quiet option before: * Mounting network filesystems ... [ ok ] * starting tincd.manifold ... * start-stop-daemon: fopen `/run/tinc.manifold.pid': No such file or directory [ ok ] * Bringing up interface wlan0 * Starting wpa_supplicant on wlan0 ... * start-stop-daemon: fopen `/var/run/wpa_supplicant-wlan0.pid': No such file or directory
