On 08/09/15 13:24, Laurent Bercot wrote:
On 08/09/2015 10:49, Jan Bramkamp wrote:
- Have one polling daemon.
- A wrapper registers polled services with the polling daemon.
No can do, sorry.
You can't make a supervision infrastructure depend on daemons,
because daemons depend on a supervision infrastructure. The
polling daemon would have to be supervised; of course it would
not perform polling itself, but it would still need to be up
every time a polling service starts. That's way too much
bootstrap complexity and possibility of failure (with bad
consequences) for that kind of functionality.
Only daemons requiring external polling would depend on this daemon and
it would support the s6 notification interface itself.
Avoiding dependencies from s6 mechanisms to a daemon is the
reason for the fifodir stuff, for instance. If I could have a
daemon, I'd use one to pubsub notifications - it would be
cleaner. But no.
That's why I suggested a daemon only for services lacking support for
the s6 readiness notification API.
Also, what's wrong with a simple unsupervised background process
that dies when its job is done?
If the script fails for any reason the service is stuck and won't come
up. Such simple scripts shouldn't fail but they might still run into
resource limits or other (temporary) problems. I agree that a simple
background script forked from ./run will work in >99% of the cases.
I don't like this fail-safe behavior. A polling daemon could keep its
state (except the file descriptors) in the file system and restart any
polled services in transition at the time to reacquire the file descriptors.
