> Being able to quickly change something in /etc/init and then have the system react to that is actually very convenient (and a must if you are pid 1 and don't want to force restarts on users).
I'm not sure I see how it's a must. Why not just have init respond to SIGHUP like so many daemons and reload its configuration then?
And that points to a fairly simple defensive practice to avoid this type of problem:
Run it in a different process. Have said process signal if a change is found. If they want to handle the case where /etc/init.d is potentially huge and you don't want to rescan everything, have it write changes via a pipe.
(In fact there's a program that will do that for you: inotifywait)
Agreed, it's pretty standard behaviour to signal daemons to cause them to reload config. SIGHUP'ing it is how you get sysvinit to reload its config too.
I see why and I also understand that fixing it isn't that easy. Software is complicated.
The flip side of this is that perhaps we should aim to reduce the complexity of software. In this case, it's not like libnih is providing any significant increase in functionality over just using inotify anyway.
I'm not sure I see how it's a must. Why not just have init respond to SIGHUP like so many daemons and reload its configuration then?