Summary: | [RFC] sys-apps/openrc: --wait should periodically check for pidfile existence | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Peter Volkov (RETIRED) <pva> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | bug, flow |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Volkov (RETIRED)
2011-10-14 09:08:22 UTC
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 |