&> and the sorts are sollutions to daemonize non daemons, not to use them for actual ones.
That has nothing to do with the fact that a "good" daemon has means to distantiate itself from the console it is started from. I'm going to start a flame-ware, but IMHO every systemadmin has to have the right to start a daemon by means he pleases. And if that's going to be init.d scripts then that's his choice. Wether started from init script, or inittab a good daemon closes it's pipes to the console, and distantiates itself from it. This should be done by: Fork the process pipe stdio to either a fifo or /dev/null close pipes to the console. Close/kill the parent process. I'll try to look into the daemonizing process of dbmail later this week, and see if I can find something. /Marc On Mon, Mar 06, 2006 at 10:33:32AM -0500, 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 > -- > Internet Connection High Quality Web Hosting > http://www.internetconnection.net/
