On Wed, 2006-03-08 at 11:47 -0500, Matthew T. O'Connor wrote: > Geo Carncross wrote: > > Nonetheless, "hung" processes are another deal: "hung" processes are the > > result of broken code, or a broken design. > > No more so than a program that crashes or a kernel that randomly kills > off processes.
But certainly more so than programs that don't crash. > > The problem I've been pointing out is that processes can be killed for > > any reason- and no amount of defensive programming in the program itself > > can protect against those kills. > > I still totally 100% disagree with this statement. Really? I would like to see a process that can resist kill -9 > > The only process guaranteed to be running is pid=1, aka init. > > Not true, the kernel can crash too. That's true. That's what watchdog hardware is for. The init if you will, for the kernel. > This whole thread, and your crusade against init.d really bothers me. Why? > If init were really such a good answer why haven't all the really smart > people put distros together use it for more than a few simple processes > that are designed to exit and be restarted by init. That's a really good question. Why don't people use it? I don't know the answer to that either. My current suspicions are that they're using the same argument you are: ``All the other smart people are using init.d- I'm smart, so I've got to be using init.d as well.'' Since I've already demonstrated that init solves problems with init.d, it's already demonstrated in at least some ways init is better than init.d I've also already stated that I don't know ALL the ways init might be better than init.d, and I don't know ALL the ways init.d might be better than init. In the meantime, I've collected this: * It's easier to add services to init.d than to inittab- but nobody does that automatically EXCEPT for the people who don't have to. It's weak; it COULD be a good reason- or rather, it COULD supply a recommendation for how to improve inittab, but I suppose until people start actively taking advantage of this, I can't see it being a priority. I've also collected the conjecture: If something unexpected happens, it's better to deny services than to restore service I don't know as I can agree with that- My job is to provide service, and I can find out what the unexpected thing was later. If you really believe this though, consider using inittab and the following: #!/bin/sh [ -f /started.1 ] && exec halt touch /started.1 exec my-daemon That way the whole system will freeze the instant your daemon crashes. That should really satisfy that condition. Again: something else inittab can do better than init.d On the other hand, if you don't know why you use init.d then maybe you should think about it too! That's what this is all about- finding out exactly why people use init.d > DBMail shouldn't crash, and it should be killed by the kernel if you > don't overcommit your memory. If DBMail still dies then as an admin I > want to know if something is wrong on my server and be able to figure it > out. If DBMail crashes too often, then I shouldn't be using it. I don't care if it shouldn't crash. I care that if it dies- for ANY REASON, that I don't lose data and my users don't notice. I can find out _why_ later. My systems run for years and years without any involvement. If something crashes once every 5 years, I would prefer no users notice and no data is lost, to users noticing and data being lost. That's what init buys me and init.d does not. > Personally, I find DBMail really stable enough, but I like it so I limp > along with it. I'm really looking forward to the 2.2 release so that I > can run it from xinetd, should make the whole system more stable. I think DBMail is plenty stable. I don't think that it can protect against kill -9 or stupidity of other forms. I also don't think it can protect against everything, and I know it can't protect against what happens 5 years from now, after I haven't been "messing with" dbmail in a while, and something happens. Someone might forget "what this does" and so on. That happens. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
