On Mon, 2006-03-06 at 17:19 +0100, Marc Dirix wrote: > &> and the sorts are sollutions to daemonize non daemons, not to > use them for actual ones.
Why? The shell is already there. What does the additional complexity actually bring? > That has nothing to do with the fact that a "good" daemon has means to > distantiate itself from the console it is started from. Why should daemons be started on the console? > 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. Sure, he has the right to modify dbmail. He has the right to make dbmail start when a USB fob is inserted into the machine. He has the right to start a daemon by pagan ritual. Rights are not being questioned or brought up. Nevertheless, programs that daemonize themselves take choices away- they make things like fghack and pgrphack necessary, and some really nasty "daemons" even defeat those tools. They make it hard to specify resource limits and to keep programs running. Since I want to put resource limits and privilege separation on everything- that is, I want to "start a daemon by any means I please"- I want it to NOT DELIBERATELY defeat the mechanisms I chose. The things I recommend be put at the beginning of daemons are to allow that. If you really want an init.d script- and I must ask, _dear_god_why_, then you can still use them by closing the file descriptors and putting it in the background _using_the_shell_. I cannot however, wait() on a process that double-fork'd, changed process groups, and closed all of its file descriptors. Oh wait, that's not true. I suppose I could use truss/strace but that'd be slow... > And if that's going to be init.d scripts then that's his choice. Why would a sysadmin WANT to use init.d scripts? If dbmail crashes- because the OOM killer gets it, or a bug in gmime, why turn a bug into a denial of service attack? If the init script fails, why should other services listed later in the rcX.d/ list be stopped? > Wether started from init script, or inittab a good daemon closes it's > pipes to the console, and distantiates itself from it. Not if started from inittab. What if I put this in my inittab yy:2345:respawn:dbmail -n -v >>/dev/tty9 2>&1 <&- > This should be done by: > Fork the process But then init can't restart it! > pipe stdio to either a fifo or /dev/null But then I can't watch for error messages on /dev/tty9! > close pipes to the console. There are no pipes to the console. What do you mean here? > Close/kill the parent process. What is this for? You cannot kill pid 1! > 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/ > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
