On Tue, 2006-03-07 at 20:11 +0100, Paul J Stevens wrote:
> Geo Carncross wrote:
> >
> >>But I guess Geo want's to be able to both fork and stay attached,
> >>something currently not accomodated. Would be rather trivial though.
> >
> >
> > No I don't. That's not what I want at all. I simply want to move dbmail
> > into category #1 instead of category #2 so that people will _stop_
> > making programs that run in #3 or #4.
>
> >From my point of view this is the age-old policy versus mechanism
> debate. As maintainer I don't much care other than not wanting to
> present the current userbase with unexpected behaviour by changing the
> default.
I understand; I just point out that there is no default- different
daemons do different things.
The only problem is that implementers don't seem to know _why_ one might
be better than another.
> I do care about helping my users (like yourself) with providing
> the mechanisms to implement whatever policy they prefer.
>
> > I really need to work on my communication skills, don't I? :)
>
> Is that your S.O. talking ?...
Hah...
> So I suggest we implement 3 runmodes:
>
> 1. DAEMON:
> use-case: init.d scripts
> double fork, detach, prefork workers
>
> 2. SERVER:
> use-case: inittab
> stay attached, prefork workers
Just so we're 100% clear- the "parent process" (i.e. the pid that is
fork'd and exec'd by init) needs to stick around as long as the process
is considered up.
If it dies (i.e. wait() returns) then DBMAIL is down.
> 3. SINGLE:
> use-case: (x)inetd, ssh-tunnel
> stay attached, single process worker only.
>
> 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.
An init.d script that runs dbmail should be able to use the same
dbmail.conf as an xinet.d service file, or a line in inittab- after all,
when I (one day) install the debian build of dbmail, I want to track it-
and I don't want to much about with a configuration file
(ForegroundOnly) and then have /etc/init.d/dbmail wake back up one day
and prevent my system from booting.
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
For compatibility (! something that I think is very important as well)
perhaps /usr/bin/dbmail (or /usr/sbin/dbmail) should contain a line like
this:
#!/bin/sh
exec /usr/libexec/dbmail-start >&- <&- 2>&- &
Note that in NO case do we need any switches, and we get to remove code
(that the shell already does fine) from dbmail. This makes dbmail
simpler, which is good.
This situation should satisfy the people here who say they need init.d.
Really though, I still want to know from people _why_ they use init.d
for critical services.
Even Matt admitted that inittab gets it back up faster- although his
primary misgiving appears to be that if a critical process DOES fail,
that it's more important to know why than to restore service.
I don't know as I agree with that, but that cannot be the reason
_everyone_ is using init.d because of all these watchdog scripts I keep
seeing on people's boxes.
My _theory_ is that people don't know, in which case, I'm evangelizing.
But if I'm wrong, I'd really want to know.
> Would that make you happy?
Handling #2 would make people in my situation happy- but as I mentioned
before I use dbmail+sqlite for single-server single-mailbox environments
over a unix domain socket. So while I'm advocating #2, I'm presently
using dbmail in situation #3 (or a situation very much like it).
Let me also say I'm really happy with dbmail. I think dbmail is great,
and I like that I haven't had to submit any patches or bust open the
profiler in a while :)
I want to help keep it great. I'm not bringing up this rant because I
hate dbmail or the way it's doing things or anything like that, but
because I am trying to help out.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
