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/
