On Wed, 2006-03-08 at 09:58 -0800, Christian G. Warden wrote: > Two benefits of init.d are that it makes it easier to stop services
Do we often want to stop services? > makes it easier to define dependencies between services. init.d has NO support for declaring dependencies, only the ability to specify explicit ordering. Unfortunately, there isn't a strict guide for all SYSVINIT based systems that says what order to pick- it's mostly experimentation to find the best place-- pick too early and your init script won't be able to start up. Pick too late, and you miss other dependencies for other processes. A human being involved might make decisions better by hand-selecting the order, but many systems have a large number of init.d scripts that make this difficult. So with that in-mind, I'd say it's easier to define dependencies in inittab than init.d - simply because I can look at one file instead of 20. > Initng combines the best of inittab and init.d. Initng looks exciting, unfortunately most of the documentation appears to be missing from the site right now. If I wasn't already so invested in daemontools I'd probably use it. I hope other distributions pick it up- if it does what I think it does. > I've long held the belief that when a daemon dies, something is wrong, > and it should be investigated. Restarting it automatically feels like a > bandaid. I'm pretty much won over now, though. On production machines, > keeping the service available is almost always much more important than > diagnosing the reason for a crashed daemon. Halting on a daemon crash > is, of course, the worse of both worlds as it denies service and > precludes investigation. Very good. On that front, I usually make my daemons drop core into a private (write only) directory, so that if they DO crash, I can find out later (on another machine)- without disturbing regular services. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
