On Tue, 2006-03-07 at 21:33 +0000, Aaron Stone wrote:
> On Tue, Mar 7, 2006, Geo Carncross said:
> > On Tue, 2006-03-07 at 20:11 +0100, Paul J Stevens wrote:
> >> Since we already support 1 and 3, adding 2 would make this picture
> >> complete. We could then also allow selection of the default through
> >> configure (compile-time) or dbmail.conf (runtime), or both.
> >
> > I'd rather not configure it in dbmail.conf - that's what ClamAV makes
> > you do, and it's kind of gross.
>
> Agreed. I don't want to see this sort of runtime-mode-altering stuff in
> the config file. I also don't want a compile time option. We should
> dictate the default and provide command line options for the other two.
Agreed.
> > No, the init.d script should say:
> >
> > /usr/libexec/dbmail-start >&- <&- 2>&- &
> >
> > an xinet.d service file should say:
> >
> > server = /usr/libexec/dbmail-imapd
> >
> > and inittab could simply say:
> > dd:123456:respawn:/usr/libexec/dbmail-start >/dev/tty9 2>&1
>
> Egad! You're right that this *can* be done, and perhaps staying attached
> should even be the default (I'm warming up to the idea that '-d' means
> 'daemonize' and otherwise the process stays attached). I disagree that we
> shouldn't have that option, because it's what so many people expect.
They _always_ have the option. The shell can do it.
MySQL works this way, Qmail works this way, Spamassassin works this way,
Courier works this way, and others- lots of others work this way.
Debian has no (technical) problem putting any of these packages in
init.d
There's no reason DBMail couldn't work this way.
init.d scripts are run by the shell.
inittab lines are run by the shell.
xinet.d lines are run by the shell.
That's what the shell is there for.
I'd even go so far as to say something like this:
dd:123456:respawn:ulimit -m480000 -d 480000;/usr/libexec/dbmail-start
>/dev/tty9 2>&1
(after of course, finding out what exactly reasonable settings should
be)
But that's the ``other'' topic :)
> I do not want to deal with the potential support nightmare of explaining
> your proposed magic stdin/out/err incantation when "You forgot to use
> -n/-d/-whatever" suffices. It is pretty cool, though.
Well, they have to use the right .conf file don't they?
Really, I'm fine with -n/-d/-whatever. I just recommend a different
"default" because really, the defaults are supposed to work for
everybody, and inittab DOES work for everybody.
I have not heard a single reason that init.d might be even slightly
better than inittab -EXCEPT- that it's easier to add entries
automatically to init.d than to inittab.
... and THAT is a poor excuse considering the people that make that
excuse, don't install entries into init.d automatically :)
inittab is portable, so you don't need a different init.d script for
each "distribution", and it also keeps the program running.
Instructions:
1. Run the following command in single-user mode, _OR_ when you can
guarantee no other processes will be editing /etc/inittab:
./make-inittab-line < /etc/inittab > /etc/inittab.tmp &&
mv /etc/inittab.tmp /etc/inittab
2. Run:
init q
3. DBmail is now up and running. Have fun!
At this point, make-inittab-line is a very simple program- implemented
in AWK if you like:
#!/usr/bin/awk -f
BEGIN {
IFS=":"
}
{
if ($1 == "DB") {
print "DBMail already installed, or another /etc/inittab entry uses
DB" > "/dev/stderr"
exit 1
}
print $0
}
END {
print "DB:123456:respawn:/usr/libexec/dbmail-start"
}
[[ beware: not tested. ]]
> People use init.d because those scripts are already provided and they
> generally work. I've actually not heard of your inittab trick before,
> although I'm intrigued by it. May I suggest writing up a little whitepaper
> about it? Evangelizing among the community at large may do more good than
> trying to convince just a few people behind your favorite email server ;-)
Really, I am honestly still trying to figure out why people use init.d
and why they think self-daemonizing is a good idea.
I have no idea how to attack this for _all_programs_ i.e. the community
at large, when really, the problems that would affect dbmail DON'T
affect some other programs.
There's some stigma that "init.d" is "new" and "inittab" is "old"
perhaps, and perhaps the real reason people started using init.d has
long since been forgotten.
Whatever the reason, init.d is wrong for daemons, and part of this is to
find out exactly why :)
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
