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