On 23/07/2014 23:45, James Powell wrote:
> Now granted some things are not able to be supervised such as udev on my end. But honestly, does udev really require supervision?
Yes, it does - why wouldn't it ? Or, if it doesn't, why would any other service ?
We don't supervise services for the heck of it. We supervise services because:
1. the world is imperfect and programs sometimes crash, udevd included. Even
simple, failsafe programs can be killed by an administrator mistake, or by a
misconfigured OOM killer.
2. it makes it easy to control them with a minimal code path.
"one-shot daemons that do not need supervision, they need to be ran, and just
left alone" is exactly what sysvinit does. It works, until it doesn't. We aim
to do better. udevd is no different from socklog or s6-tcpserver or qmail-send,
except that it's bigger and messier so it's more likely to die: why would you
want to stick supervision on "true" services, and leave udevd out ? The early,
fundamental services, that really hose your whole system if they crash, are
the ones that need supervision the most. A long-lived process is a long-lived
process is a long-lived process, there's no reason to treat udevd, dhcpd,
getty or sshd in different ways.
Yes, a clear separation between initialization and supervision makes it
difficult to have everything under your supervision tree. This is why I am
suggesting a slightly more integrated approach, that solves this problem.
s6 makes it easy (and it will be done automatically when I release s6-init)
but it can be done with runit too. Have /etc/runit/1 simply fork the real init
script then exit. Have the real init script block on something that will only
unblock when runsvdir is running. Now your real init script only executes
when runsvdir is already running, and you can add whatever service you want
to it.
The scheme could probably be made to work with perp too, I just haven't
thought about it.
--
Laurent
Received on Thu Jul 24 2014 - 00:42:19 UTC