The issue I see is how complex do you want the implementation to be. For me, one shot services and system triggers that can be ran unsupervised, are safe to do so. Now granted you should supervise things like dhcpcd for example but does the ifup script need supervision also to keep eth0 online? I honestly see supervision of eth0 and ifup as entirely optional just as udev. These one-shot services simply can be ran once and never ran again. In fact, udev is really a supervision service for hardware and drivers, equal somewhat to runsv and s6-svscan as they relate to daemons and software. So its a debate if udev should or shouldn't be ran with or without supervision entirely.
Things like fsck, udev, sysstat, mount, entropy, swap, and ifup/down can be safely handled by Stages 1 and 3 respectively which saves you lots of complexity in the end regardless of the init solution. The rest get put into Stage 2 for supervision. However, the more complexity you add, when troubleshooting is required, you have more backtracking to do through the service dependencies. This was one of the major headaches with systemd early on. People implementing it were trying to put everything in parallel without regards to dependency resolution within the daemons. Services then had to be written and rewritten several times to use tree based dependency loading to load some services in linear mode. Networking was a prime example. Now networkd handles networking which defeats the purpose of using daemons. However, if the systemd designers were more willing to use a hybrid tree based dependency loading system, rather than create more and more projects, it would have worked without all the tentacles. The beauty of Runit, s6, djbdts, perp, etc. all give you the benefit of hybrid loading, and thusly work correctly by design without invasion into the system. Sent from my Windows Phone ________________________________ From: Joe M<mailto:joe9m...@gmail.com> Sent: 7/24/2014 6:31 AM To: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> Subject: Re: initialization vs supervision Hello James, > Stage-1's purpose is basically to mount file systems, load drivers, > check the file system, and load the disks. Now first off, yes, I > could move udev into stage-2, but there-in lies an issue, what would > then require a redrafting of many service scripts to check for udev, > then load? Udev in my opinion is a one-shot daemon. It loads devices > and it settles, and that's it. DBus already has many services check > for it. If we expand this it only increases the complexity factor, > so that's why things get moved around from stage-2 to stage-1, > unless otherwise shown to be necessary. I take your approach that udev should not need to be supervised. If it crashes, I have this line in my crontab: " */5 * * * * for svc in $(rc-status --crashed); do rc-service $svc -- --nodeps restart; done" On my system, I have atd, crond, acpid, klogd and svlogd as supervised processes. I plan to move from syslogd to rsyslogd, so, it might change a little. Thanks Joe
