As always Geo, I'll take your recommendations to heart. Geo Carncross wrote: > Add <&- >&- 2>&- and stuff your startup script. > > > But you should have already known to do that. init.d scripts are > unreliable and no decent unix administrator should recommend them for > running services. > > > Something as critical as email should probably be run from inittab (or > daemontools) anyway- unless you disabled the out-of-memory killer and > trust every user who connects to dbmail. > > That last part is kind of important- dbmail can eat an awful lot of > memory- not by its own fault or anything, but because of gmime, or the > mysql client caching, or so on. > > Making dbmail die quickly is pretty important. Using resource limits > makes sure that dbmail dies as soon as it acts unexpectedly. > > But making sure it comes back is something only pid#1 (init) can do. > > The current trend for init.d scripts is saddening. It's difficult for an > administrator to add resource limits and to make sure they "come back" > once started. Worse still: very few unixes using them bother to add > resource limits. > > How many "bind restarter" programs have we seen? Little tools that > resemble: > #!/bin/sh > while true; do > while pkill -0 named; do sleep 1; done > /etc/init.d/named start > done > > Daemons also run as root. Root-owned processes shouldn't be killed so > quickly by the OOM killer, so getting them killed by other means (say, > reasonable resource limits) is even more important. > > I've taken a draconian approach, and I recommend others do the same: If > you write a daemon, make it only run from inittab or daemontools. An > easy way to do this is to make sure ppid==1 /OR/ stdin/stdout/stderr is > either closed or attached to a fifo. fstat(0,&sb) should either return > -1, or S_ISFIFO(sb.st_mode) should be true. If none of that is true, > then getppid() == 1. Otherwise tell the user they didn't follow the > installation directions. > > [[ The reason to check fifos/closed is because while daemontools doesn't > start processes with ppid=1, it DOES restart them because daemontools is > started from init ]] > > A startup routine that doesn't guarantee either of these two things is > probably wrong anyway- yes I do largely mean that it's probably an > init.d script, but it's also probably wrong for other reasons too. > > I also recommend daemon implementors make sure their resources aren't > unlimited by checking getrlimit() and making sure that some limits are > set on something that is recommended. Honoring $EAT_ALL_MEMORY as a way > to disable this is good for debugging (!), and it reminds the user who > thinks about using it to find out exactly why they want dbmail to > actually eat all of their memory. > > There's absolutely nothing wrong with running things from inittab. I run > mail, dns, web services- hell, anything that's "important that it stay > running" runs from inittab. Why? Because I don't want to tell my > customers: "Oh, well, apache killed itself, so I restarted it. You're > fixed now!" > > I'm sorry, that's just wrong. And init.d/ scripts are just that kind of > wrong. > > Maybe init.d/networking is okay- something that doesn't actually keep a > process running (but when it does: say with pump or dhcpc, then it is > wrong) is okay, but really, init.d is wrong. Stop using it. > > Stop recommending it. Actively defend against using it. Make services > reliable and unix administrators smarter... > > > On Mon, 2006-03-06 at 12:51 +0100, Marc Dirix wrote: > >>I've installed dbmail from svn over the debian rules script, >> >>The problem I think is, that one of the dbmail processes (lmtp or imap >>I use both) doesn't completely detach from the console. Because after >>starting dbmail from the init script I can't logout off the console >>anymore. >> >>Kind regards, >> >>Marc >>_______________________________________________ >>Dbmail-dev mailing list >>[email protected] >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
-- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
