Kill init by touching a bunch of files
There are so many things in here that tempt me to comment about, so here goes:<p>1) For me, this is a prime example of why I personally like programming environments with exceptions. If libnih could throw an exception (I know it can't), then they could do that which would allow the caller to at least deal with the exception and not bring the system down. If they don't handle the exception, well, we're were we are today, but as it stands now, fixing this will require somebody to actually patch libnih.<p>Yes. libnih could also handle that error by returning an error code itself, but the library developers clearly didn't want to bother with that in other callers of the affected function.<p>By using exceptions, for the same amount of work it took to add the assertion they could also have at least provided the option for the machine to not go down.<p>Also, I do understand the reservations against exceptions, but stuff like this is what makes me personally prefer having exceptions over not having them.<p>2) I read some passive aggressive "this is what happens if your init system is too complicated" assertions between the lines.<p>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).<p>Yes, the system is not prepared to handle 10Ks of init scripts changing, but if you're root (which you have to be to trigger this), there are <i>way</i> more convenient (and quicker!) ways to bring down a machine (shutdown -h being one of them).<p>Just removing a convenient feature because of some risk that the feature could possibly be abused by an admin IMHO isn't the right thing to do.<p>3) I agree with not accepting the patch. You don't (ever! ever!) fix a problem by ignoring it somewhere down the stack. You also don't call exit() or an equivalent in a library either of course :-).<p>The correct fix would be to remove the assertion, to return an error code and to fix all call sites (good luck with the public API that you've just now changed).<p>Or to throw an exception which brings us back to point 1.<p>I'm not complaining, btw: Stuff has happened (great analysis of the issue, btw. Much appreciated as it allowed me to completely understand the issue and be able to write this comment without having to do the analysis myself). I see why and I also understand that fixing it isn't that easy. Software is complicated.<p>The one thing that I'm heavily disagreeing though is above point 2). Being able to just edit a file is way more convenient than also having to restart some daemon (especially if that has PID 1). The only fix from upstarts perspective would be to forego the usage of libnih (where the bug lives), but that would mean a lot of additional maintenance work in order to protect against a totally theoretical issue as this bug requires root rights to use.