Re: [Dbmail-dev] daemonize - proposing a new command line option
On Wed, 2006-03-15 at 14:30 -0800, Blake Mitchell wrote: Geo, I think you are confusing your forks. You are thinking fork as in run in the background by forking and then killing the parent. Where as Aaron is talking about forking child processes to handle each connection. If that's the case, then fine. Geo Carncross wrote: On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote: Aaron Stone wrote: If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: agreed. default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Ok by me. I'd recommend: default: no-fork, no-detach -d: detach -f: fork -d would simply be a synonym for - - 2- (etc) -f would simply be a synonym for possible other options: -g would set up a new process group -e would set up a new session That way, people using init.d might try: dbmail -defg people using /etc/rc would use: dbmail -df and people using /etc/inittab or daemontools would use: dbmail ALTHOUGH, really- I think dbmail should be called dbmail-start and live in libexec someplace and /usr/sbin/dbmail should instead be a wrapper script that looks like this: #!/bin/sh exec /usr/libexec/dbmail/dbmail-start -defg ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize - proposing a new command line option
On Wed, 2006-03-15 at 18:36 -0500, Geo Carncross wrote: On Wed, 2006-03-15 at 14:30 -0800, Blake Mitchell wrote: Geo, I think you are confusing your forks. You are thinking fork as in run in the background by forking and then killing the parent. Where as Aaron is talking about forking child processes to handle each connection. If that's the case, then fine. Right -- What I mean by fork and detach are: fork: children to handle connections. detach: double fork away from console. the -f option is already taken for alt. config file; that option runs across all of the command line programs and would be hard to change, needing to rearrange other options to make room in some cases. It would kinda neat if you ran 'dbmail-imapd' and the program returned Dbmail-IMAPd ready to rock and started speaking IMAP to you ;-) I'm not sure if I like this, though. I'll marinate with it some more. It might also be time to start using getopt_long... Geo Carncross wrote: On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote: Aaron Stone wrote: If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: agreed. default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Ok by me. I'd recommend: default: no-fork, no-detach -d: detach -f: fork -d would simply be a synonym for - - 2- (etc) -f would simply be a synonym for possible other options: -g would set up a new process group -e would set up a new session That way, people using init.d might try: dbmail -defg people using /etc/rc would use: dbmail -df and people using /etc/inittab or daemontools would use: dbmail ALTHOUGH, really- I think dbmail should be called dbmail-start and live in libexec someplace and /usr/sbin/dbmail should instead be a wrapper script that looks like this: #!/bin/sh exec /usr/libexec/dbmail/dbmail-start -defg ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] daemonize - proposing a new command line option
On Wed, 2006-03-15 at 16:33 -0800, Aaron Stone wrote: On Wed, 2006-03-15 at 18:36 -0500, Geo Carncross wrote: On Wed, 2006-03-15 at 14:30 -0800, Blake Mitchell wrote: Geo, I think you are confusing your forks. You are thinking fork as in run in the background by forking and then killing the parent. Where as Aaron is talking about forking child processes to handle each connection. If that's the case, then fine. Right -- What I mean by fork and detach are: fork: children to handle connections. detach: double fork away from console. Yeah, except note use you the word fork in defining detach. Better to say: -P: [pre]fork processes for handling children -D: detach from console by closing fds 0..93 inclusive after starting -B: put dbmail in the background (because for some reason you're starting dbmail from something that isn't a shell and you can't use ) -G: start dbmail in its own process group (setpgid) so that stupid programs (like pppd) don't kill it when a user disconnects- even more useful if someone starts it from a serial console and has a SAK -S: start dbmail in its own session (setsid)- implies -G, and requires -D (and the operations performed by -D must be done before setsid()) I'm not married to these switches- anything is fine, but there is something important about them: none of these definitions are negative; none of these switches stop dbmail from doing something. That's confusing. If the default should be something else, I recommend using a wrapper script as I described earlier. the -f option is already taken for alt. config file; that option runs across all of the command line programs and would be hard to change, needing to rearrange other options to make room in some cases. It would kinda neat if you ran 'dbmail-imapd' and the program returned Dbmail-IMAPd ready to rock and started speaking IMAP to you ;-) I'm not sure if I like this, though. I'll marinate with it some more. Supporting imap preauth isn't such a bad idea- it makes it so people can ssh-tunnel their IMAP mail without having to do port forwarding. As a side note- there's a reason I listed fds 0..93 as should be closed by -D; I'm sure everyone guesses 0 through 2 easily enough, but there might be some pipelines, so close a bit further- fds 15 or 16 is usually what I see. The Bourne shell (the REAL one) uses file descriptor 19 internally for reading scripts- we shouldn't close it in the parent- but after forking (-P) because the script running dbmail might not end in: exec dbmail-start but instead expect to be able to do some things afterwards. HP-UX uses file descriptor 59 instead of file descriptor 19, but for the same reason. I've heard reports of shells in this era using a descriptor as high as 92- but as you already know- I treat the detaching from the console as a significantly system-dependant, and non-portable thing, such that I let the administrator do it in the shell if they know they're using such a beast. Besides, THESE days, UNIX has close-on-exec (or ioctl FIOCLEX), so the shell doesn't need to use magic file descriptors anymore. so if -S is set and -D isn't, if we have FIOCLEX defined, or FD_CLOEXEC, setsid() will do the right thing otherwise, we need to close all file descriptors 0..93 otherwise if -D is set, we need to close all file descriptors 0..93 of course, if we DON'T have FD_CLOEXEC, then chances are we don't have setsid() either (FD_CLOEXEC and setsid() are both in POSIX 1003)- so really, this is more of a historical footnote- especially in case anyone wants to port dbmail to a V7 machine :) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize - proposing a new command line option
If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Aaron
Re: [Dbmail-dev] daemonize - proposing a new command line option
Aaron Stone wrote: If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: agreed. default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Ok by me. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize - proposing a new command line option
On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote: Aaron Stone wrote: If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: agreed. default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Ok by me. I'd recommend: default: no-fork, no-detach -d: detach -f: fork -d would simply be a synonym for - - 2- (etc) -f would simply be a synonym for possible other options: -g would set up a new process group -e would set up a new session That way, people using init.d might try: dbmail -defg people using /etc/rc would use: dbmail -df and people using /etc/inittab or daemontools would use: dbmail ALTHOUGH, really- I think dbmail should be called dbmail-start and live in libexec someplace and /usr/sbin/dbmail should instead be a wrapper script that looks like this: #!/bin/sh exec /usr/libexec/dbmail/dbmail-start -defg -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize - proposing a new command line option
Geo, I think you are confusing your forks. You are thinking fork as in run in the background by forking and then killing the parent. Where as Aaron is talking about forking child processes to handle each connection. Geo Carncross wrote: On Wed, 2006-03-15 at 09:19 +0100, Paul J Stevens wrote: Aaron Stone wrote: If we don't want to break existing scripts/installations: default: fork, detach. -n: no-fork, no-detach. (new) -d, fork, no-detach. Weirdness: -nd means what? same as -n? However I would rather break things sooner than later: agreed. default: fork, no-detach -n: no-fork, no-detach (new) -d: fork, detach -nd: no-fork, detach (unsupported, but could be) I think this would give us the best set of options that make sense. Ok by me. I'd recommend: default: no-fork, no-detach -d: detach -f: fork -d would simply be a synonym for - - 2- (etc) -f would simply be a synonym for possible other options: -g would set up a new process group -e would set up a new session That way, people using init.d might try: dbmail -defg people using /etc/rc would use: dbmail -df and people using /etc/inittab or daemontools would use: dbmail ALTHOUGH, really- I think dbmail should be called dbmail-start and live in libexec someplace and /usr/sbin/dbmail should instead be a wrapper script that looks like this: #!/bin/sh exec /usr/libexec/dbmail/dbmail-start -defg
Re: [Dbmail-dev] daemonize
On Tue, 2006-03-07 at 21:56 +0100, Marc Dirix wrote: Using the and the sorts is just plain wrong. Why? You want a daemon if it daemonizes itself to daemonize by itself without needing any shell implementation. No I don't. Daemons get started by the shell anyway. The shell is in a perfect position to do this. My question is why do _you_ want a daemon that daemonizes itself? In that way the daemon runs on any number off platforms, like w32 (if necessary). Win32 doesn't support the unix concept of daemons anyway, and the daemonizing process used in unix doesn't work on Windows. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
On Tue, 2006-03-07 at 21:33 +, 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 21
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 -m48 -d 48;/usr/libexec/dbmail-start
/dev/tty9 21
(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/
Re: [Dbmail-dev] daemonize
On Wed, 2006-03-08 at 00:49 +0100, Marc Dirix wrote: Like I said, a daemon should run indepedentally from the shell implemantation. But you haven't said _why_. And secondly, starting from inittab is IMHO only usefull for daemons which tend to get killed or die, and therefor is a quickfix for not propperly working daemons. You've already said this, but you haven't said _why_. Furthermore, a standard init only tries X time to restart a program, afterwards it stops anyways. Standard init doesn't do this. Standard init will back off after so many failed stops, but this is an effort to reduce CPU time. If the program dies 5 times in a second, a few minutes are delayed. If the program dies 5 times in a day, there's no delay. Furthermore, an init.d script won't get restarted EVER. And a good working init.d script doesn't stop my computer from booting when the daemon fails to start. It does give me a warning right away. It's the not-working init.d scripts or daemons that stop the computer from booting. But even working init.d scripts and working daemons can be killed or stopped for lots of reasons, and unless you duplicate the work of init, or manually intervene, they won't start back up. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
Ohhhkkaayy Geo's approach is really cool. Marc's approach is more typical. You guys are free to choose either one. I'm sure that Geo thinks that Marc will get bit in the butt by his choice at some point, and Marc thinks that Geo is being weird. For sure you're both right. Paul and I have both posted about how we're planning on supporting both modes of operation; it's just a matter of getting the code right. Aaron On Tue, Mar 7, 2006, Geo Carncross [EMAIL PROTECTED] said: On Tue, 2006-03-07 at 21:56 +0100, Marc Dirix wrote: Using the and the sorts is just plain wrong. Why? You want a daemon if it daemonizes itself to daemonize by itself without needing any shell implementation. No I don't. Daemons get started by the shell anyway. The shell is in a perfect position to do this. My question is why do _you_ want a daemon that daemonizes itself? In that way the daemon runs on any number off platforms, like w32 (if necessary). Win32 doesn't support the unix concept of daemons anyway, and the daemonizing process used in unix doesn't work on Windows. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/ ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev --
Re: [Dbmail-dev] daemonize
On Tue, Mar 7, 2006, Geo Carncross [EMAIL PROTECTED] said: 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. Write an article for freshmeat.net or one of the Sysadmin or Linux magazines. As you mentioned earlier the in thread, there are programs that behave in all sorts of different ways, with nothing particularly consistent about them. Aaron
Re: [Dbmail-dev] daemonize
Yes, I can find myself in your proposed sollution. If I get bit in the butt, I'll be happy to report it here. Furthermore, Paul and Aaron, many thanks for this great piece of software! I'm a very happy user! /Marc On Wed, Mar 08, 2006 at 12:08:32AM -, Aaron Stone wrote: Ohhhkkaayy Geo's approach is really cool. Marc's approach is more typical. You guys are free to choose either one. I'm sure that Geo thinks that Marc will get bit in the butt by his choice at some point, and Marc thinks that Geo is being weird. For sure you're both right. Paul and I have both posted about how we're planning on supporting both modes of operation; it's just a matter of getting the code right. Aaron On Tue, Mar 7, 2006, Geo Carncross [EMAIL PROTECTED] said: On Tue, 2006-03-07 at 21:56 +0100, Marc Dirix wrote: Using the and the sorts is just plain wrong. Why? You want a daemon if it daemonizes itself to daemonize by itself without needing any shell implementation. No I don't. Daemons get started by the shell anyway. The shell is in a perfect position to do this. My question is why do _you_ want a daemon that daemonizes itself? In that way the daemon runs on any number off platforms, like w32 (if necessary). Win32 doesn't support the unix concept of daemons anyway, and the daemonizing process used in unix doesn't work on Windows. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/ ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] daemonize
On Wed, 2006-03-08 at 00:23 +, Aaron Stone wrote: On Tue, Mar 7, 2006, Geo Carncross [EMAIL PROTECTED] said: 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. Write an article for freshmeat.net or one of the Sysadmin or Linux magazines. As you mentioned earlier the in thread, there are programs that behave in all sorts of different ways, with nothing particularly consistent about them. I keep saying I don't know why people use init.d - I don't mean There isn't any reason to use init.d - I mean: I don't know of any reason to use init.d. For critical services, I can see a very big reason NOT to use init.d- and for daemons in general, I can see that big reason extending to them in some part... I can't recommend init.d for any [critical] services- for exactly this reason, and I don't think system administrators _should_ recommend them. But I'm saying I don't know why people _use_ init.d, and I'm seeking enlightenment on that point. If I knew that I might know why there was such animosity toward using inittab. I've said the only good reason I heard was that it's easier to add entries to init.d than to inittab- and that's a real good reason, except as far as I know, NOBODY adds entries to init.d automatically except unixish system distributors- and those people are in the PERFECT PLACE to provide an automation for safe inittab editing. On the other hand, I say there is no reason for daemons to ``daemonize themselves'' because daemonizing is a complicated process that is already available to every way that the daemon could start- and that is because the shell is involved in any way that the daemon could start. I'm not adequately prepared to tell people init.d is dead yet, because I don't know if I'm missing anything or not. I'm not completely ready to evangelize this. What I do know is that init.d and init.d-like methods cause a particular problem for long-running services that inittab in fact solves. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
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 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 ?... 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 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. Would that make you happy? -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
Using the and the sorts is just plain wrong. You want a daemon if it daemonizes itself to daemonize by itself without needing any shell implementation. In that way the daemon runs on any number off platforms, like w32 (if necessary).
Re: [Dbmail-dev] daemonize
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. 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 21 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. 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. 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 ;-) Aaron
Re: [Dbmail-dev] daemonize
This is a long-standing issue. If anyone has any ideas I'd be happy to hear them. 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 Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
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 Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
As always Geo, I'll take your recommendations to heart. 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 Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
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 Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
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 21 - 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
Re: [Dbmail-dev] daemonize
Geo Carncross wrote: 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. The OOM Killer should be killed itself. I keep up with the PostgreSQL lists and they *HIGHLY* recommend disabling the OOM killer. The section 16.4.3 for details: http://www.postgresql.org/docs/current/static/kernel-resources.html#AEN18105 Basically their view of the OOM killer is that it's a very bad idea for a server that you want to be reliable. Basically if you tell the Kernel not to overcommit memory, the OOM killer becomes moot, but you better have enough mem / swap space to handle your needs. Matt
Re: [Dbmail-dev] daemonize
Hello
Paul J Stevens wrote:
This is a long-standing issue. If anyone has any ideas I'd be happy to
hear them.
perldoc -q daemon :
How do I fork a daemon process?
If by daemon process you mean one that's detached (disassociated from its
tty), then the following process is reported to work on most Unixish systems.
o Open /dev/tty and use the TIOCNOTTY ioctl on it. See tty for details. Or
better yet, you can just use the POSIX::setsid() function, so you don't
have to worry about process groups.
o Change directory to /
o Reopen STDIN, STDOUT, and STDERR so they're not connected to the old tty.
o Background yourself like this:
fork exit;
And this is Proc::Daemon module (I think, this help you):
sub Fork {
my($pid);
FORK: {
if (defined($pid = fork)) {
return $pid;
} elsif ($! =~ /No more process/) {
sleep 5;
redo FORK;
} else {
croak Can't fork: $!;
}
}
}
sub OpenMax {
my $openmax = POSIX::sysconf( POSIX::_SC_OPEN_MAX );
(!defined($openmax) || $openmax 0) ? 64 : $openmax;
}
sub Init {
my $oldmode = shift || 0;
my($pid, $sess_id, $i);
## Fork and exit parent
if ($pid = Fork) { exit 0; }
## Detach ourselves from the terminal
croak Cannot detach from controlling terminal
unless $sess_id = POSIX::setsid();
## Prevent possibility of acquiring a controling terminal
if (!$oldmode) {
$SIG{'HUP'} = 'IGNORE';
if ($pid = Fork) { exit 0; }
}
## Change working directory
chdir /;
## Clear file creation mask
umask 0;
## Close open file descriptors
# May be close only STDIN STDOUT STDERR
foreach $i (0 .. OpenMax) { POSIX::close($i); }
## Reopen stderr, stdout, stdin to /dev/null
open(STDIN, +/dev/null);
open(STDOUT, +STDIN);
open(STDERR, +STDIN);
$oldmode ? $sess_id : 0;
}
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.
--
Oleg Lapshin
Re: [Dbmail-dev] daemonize
On Mon, 2006-03-06 at 13:26 -0500, Matthew T. O'Connor wrote: Geo Carncross wrote: 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. The OOM Killer should be killed itself. I keep up with the PostgreSQL lists and they *HIGHLY* recommend disabling the OOM killer. The section 16.4.3 for details: http://www.postgresql.org/docs/current/static/kernel-resources.html#AEN18105 Basically their view of the OOM killer is that it's a very bad idea for a server that you want to be reliable. Basically if you tell the Kernel not to overcommit memory, the OOM killer becomes moot, but you better have enough mem / swap space to handle your needs. The OOMK isn't _causing_ the problem. The problem is already there! You're simply out of memory! It doesn't matter if malloc() fails or not. The OOMK is simply one way of fixing it. ``to avoid this problem is to run PostgreSQL on a machine where you can be sure that other processes will not run the machine out of memory.'' This is the nugget of truth. If you disable overcommit, then malloc() or mmap() can fail. If you use overcommit, then the process gets killed someplace else. Pg has to be resistant to failure anyway- it has to protect against the power cord getting yanked. OOMK or not- you run out of memory, and Pg stops doing it's job. Daemons should be resistant to accidental death. Whether it be OOMK, signal, or bug in the software. Daemons cannot be resistant on their own: The only way to make a program stay running is by init- and that's only because init (pid 1) cannot be killed. If you run postmaster from init (as I do) then if Pg dies, it gets restarted. This can be because Pg has a bug in it, or a signal gets sent to the wrong process group, the OOMK goes nuts, or any number of other reasons. YES: there will be a short time in which queries aren't answered, but that's better than a LONG time where queries aren't answered, and the OOMK has absolutely nothing to do with that. ... just whether you use init.d or inittab. My point here is that when a process (like dbmail) daemonizes itself, it's no longer possible to keep it running, and instead, we have to resort to watchdog-style scripts. I personally, think watchdog-style scripts are stupid. You don't have to- I'm not trying to convince YOU that they're bad or anything, as I mentioned elsewhere on the thread, init.d can daemonize a program WITHOUT the assistance of the program, but if the program DOES daemonize on it's own, then it can no longer be kept running. So you say: turn off the OOMK so Pg stays running I say: Turn off init.d so Pg stays running -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
Geo Carncross wrote: On Mon, 2006-03-06 at 13:26 -0500, Matthew T. O'Connor wrote: The OOM Killer should be killed itself. I keep up with the PostgreSQL lists and they *HIGHLY* recommend disabling the OOM killer. The section 16.4.3 for details: http://www.postgresql.org/docs/current/static/kernel-resources.html#AEN18105 Basically their view of the OOM killer is that it's a very bad idea for a server that you want to be reliable. Basically if you tell the Kernel not to overcommit memory, the OOM killer becomes moot, but you better have enough mem / swap space to handle your needs. The OOMK isn't _causing_ the problem. The problem is already there! You're simply out of memory! It doesn't matter if malloc() fails or not. The OOMK is simply one way of fixing it. I disagree here, a program can intelligently deal with a malloc() failure, PostgreSQL does this very well in fact. A program can not deal intelligently with getting killed at random moments. So I disagree that OOM is a way of fixing the problem. This is the nugget of truth. If you disable overcommit, then malloc() or mmap() can fail. If you use overcommit, then the process gets killed someplace else. Same comment as above, a well written program can deal with a malloc failure. Pg has to be resistant to failure anyway- it has to protect against the power cord getting yanked. And it is. OOMK or not- you run out of memory, and Pg stops doing it's job. No, PG allocates most of what it needs on startup, a particular query may fail due to a malloc() failure, but the postmaster will keep running. Also, the OOM killer often does not kill the program that is causing the OOM problem. Daemons should be resistant to accidental death. Whether it be OOMK, signal, or bug in the software. Right, and PG is, however there is a stability loss when using OOM, you can't predict when PG will get killed, and it might not even be PG's fault, that is, some other program might be using all the memory. Daemons cannot be resistant on their own: The only way to make a program stay running is by init- and that's only because init (pid 1) cannot be killed. If you run postmaster from init (as I do) then if Pg dies, it gets restarted. This can be because Pg has a bug in it, or a signal gets sent to the wrong process group, the OOMK goes nuts, or any number of other reasons. That's fine, but the only program I run from init are ones I don't trust, I have never run PG from init, and I have never had a problem with it dying. So you say: turn off the OOMK so Pg stays running I say: Turn off init.d so Pg stays running NO PG does not stay running from init any better than from init.d, it just gets back up faster (assuming it can be restarted). I don't like this since it may mask a larger problem. Bottom line is PG shouldn't die very often and doesn't if it's setup properly. Matt
Re: [Dbmail-dev] daemonize
On Mon, 2006-03-06 at 14:33 -0500, Matthew T. O'Connor wrote: I disagree here, a program can intelligently deal with a malloc() failure, PostgreSQL does this very well in fact. A program can not deal intelligently with getting killed at random moments. So I disagree that OOM is a way of fixing the problem. This depends on what you mean by deal with the problem. Queries will not be handled/answered when Pg runs out of memory, no matter HOW good it is with malloc(). Furthermore, the stack space can be exhausted. There's no way to tell for certain when this would occur - especially with recursive stack use. In _my_ opinion, it's better to simply deal with what happens when a program dies, instead of trying to prevent all the reasons that it could. It's _because_ that's my opinion that I use init. OOMK or not- you run out of memory, and Pg stops doing it's job. No, PG allocates most of what it needs on startup, a particular query may fail due to a malloc() failure, but the postmaster will keep running. Also, the OOM killer often does not kill the program that is causing the OOM problem. It doesn't matter if postmaster keeps running or not. What matters is that queries will fail when the system runs out of memory. There isn't anything the daemon can do about this (short of, not using any heap or stack), and like it or not, Pg uses the heap and the stack. Also note, that if the OOMK goes off, it's because there's a problem someplace. You mention later that you're adverse to masking the problem- but that's exactly what turning off the OOMK does-- you have problems that need more memory than is available. Daemons should be resistant to accidental death. Whether it be OOMK, signal, or bug in the software. Right, and PG is, however there is a stability loss when using OOM, you can't predict when PG will get killed, and it might not even be PG's fault, that is, some other program might be using all the memory. That can happen anyway. See above. Note, I'm not specifically making a case for OOMK, but for init. That's fine, but the only program I run from init are ones I don't trust, I have never run PG from init, and I have never had a problem with it dying. So what? So you say: turn off the OOMK so Pg stays running I say: Turn off init.d so Pg stays running NO PG does not stay running from init any better than from init.d, it just gets back up faster (assuming it can be restarted). Just gets back up faster. That's the important part. If postgresql dies, nothing calls /etc/init.d/postgresql start except an ad-hoc keepalive script similar to the ones I mentioned earlier. I use init because it gets Pg back up faster. Now stay with me for a moment: I don't want DBMAIL to go through EXTRA CONTORTIONS that will make it difficult for me to get it back up faster. I think that if somebody REALLY WANTS init.d to be used, their init.d script can do the daemonizing and backgrounding because the shell can already do it, and that's what they think they want. I _PERSONALLY_ don't think there's a use for init.d that involves daemons, but don't get confused by what I'm saying there: It is important to _ME_ that Pg just gets back up faster. do realize that doesn't matter to you, all I want is for you to understand that it's important to me. If dbmail daemonizes through weird contortions it makes my life more difficult, and doesn't make your life any easier. If dbmail makes it easy to run from init, it makes my life easier, and doesn't make your life any more difficult. I don't like this since it may mask a larger problem. I don't care. I want Pg to stay running. Bottom line is PG shouldn't die very often and doesn't if it's setup properly. That's where we differ: The bottom line for me is that queries must get answered. There is no if they don't, they simply must be answered. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
Oleg Lapshin wrote: o Reopen STDIN, STDOUT, and STDERR so they're not connected to the old tty. Heh! That must be it. Makes sense, and it's the only thing not being done already. Will try, thanks. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
problem fixed, bug closed. calling freopen on the std streams does the trick. Code extracted to new function in server.c,server_daemonize if you want to see how it's done atm. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
I think if you want to start the process in your special way, you could make an option for dbmail to not daemonize, and let the others use it like they are used to. There are a lott good daemons who have an console switch to not fork and kill tty. /Marc
Re: [Dbmail-dev] daemonize
Marc Dirix wrote: I think if you want to start the process in your special way, you could make an option for dbmail to not daemonize, and let the others use it like they are used to. There are a lott good daemons who have an console switch to not fork and kill tty. As does dbmail. dbmail-imapd -n won't fork and stay attached. But I guess Geo want's to be able to both fork and stay attached, something currently not accomodated. Would be rather trivial though. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl
Re: [Dbmail-dev] daemonize
Let's see if I got the gist of this thread: Fork detach: the intended the default (although broken in 2.1.4) because most people expect it to work this way. Fork no-detach: parents stays connected to the tty so that failures are quickly detected by an appropriate wrapper script / init / whatever. Should be trivial to do, and makes a lot of sense. No-fork no-detach (-n flag): required for inetd operation. Works. Aaron On Mon, 2006-03-06 at 22:54 +0100, Marc Dirix wrote: I think if you want to start the process in your special way, you could make an option for dbmail to not daemonize, and let the others use it like they are used to. There are a lott good daemons who have an console switch to not fork and kill tty. /Marc ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] daemonize
On Mon, 2006-03-06 at 23:06 +0100, Paul J Stevens wrote: Marc Dirix wrote: I think if you want to start the process in your special way, you could make an option for dbmail to not daemonize, and let the others use it like they are used to. There are a lott good daemons who have an console switch to not fork and kill tty. As does dbmail. dbmail-imapd -n won't fork and stay attached. Right. dbmail is somewhat good in this respect. It's my opinion that it should be the default, and that daemonizing code doesn't belong in daemons. Below group #1 is preferred, #2 is acceptable (i.e. I can do what I want), #3 is tolorated (although wrong) and #4 makes me unhappy. I think there's loads of stuff to do besides daemonizing, and every time someone goes in there, it breaks it from #2 into #4 (as did happen). [1] Some examples of daemons that don't daemonize: MySQL Qmail SpamAssassin (spamd) Courier/MTA [2] Examples of daemons that need a special flag/config file: ClamAV (clamd) Apache DBMail (-n) XNTPD [3] Examples of daemons that require a special flag used for something else (i.e. debug mode): OpenSSH [4] Examples of daemons that fork and detach like it or not: SSH PostgreSQL Postfix For me to run programs in group #4, I need a hack; like fghack which opens up a bunch of file descriptors to await EPIPE, or pgrphack which monitors a process group. This is just plain wrong. Daemons don't HAVE to daemonize themselves, and as a result they shouldn't. People that expect them have no reason to expect them to operate this way. They just use the supplied init script and be done with it. 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. I really need to work on my communication skills, don't I? :) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
Re: [Dbmail-dev] daemonize
Paul J Stevens wrote: problem fixed, bug closed. calling freopen on the std streams does the trick. Code extracted to new function in server.c,server_daemonize if you want to see how it's done atm. Let's see. TRACE_STDERR 0 dbmail daemonizes and ? we have nothing on STDERR ;) And: revision 2014. dbmail.h: #define DEFAULT_PID_DIR /var/run/dbmail/ may be /var/run/ ? dbmail.h: #define DEFAULT_CONFIG_FILE /etc/dbmail/dbmail.conf may be /etc/dbmail.conf ? server.c: freopen(/var/log/dbmail/dbmail.log,a,stdout); server.c: freopen(/var/log/dbmail/dbmail.err,a,stderr); may be this mus be configurable ? And: # make . db.c: In function `acl_query': db.c:3751: error: `mailbox' undeclared (first use in this function) db.c:3751: error: (Each undeclared identifier is reported only once db.c:3751: error: for each function it appears in.) db.c: At top level: db.c:3748: warning: unused parameter 'mailbox_idnr' make[2]: *** [libdbmail_la-db.lo] Error 1 make[2]: Leaving directory `/export/hda3/0TMP/dbmail-2.1.5pre/dbmail' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/hda3/0TMP/dbmail-2.1.5pre/dbmail' make: *** [all] Error 2 -- Oleg Lapshin
Re: [Dbmail-dev] daemonize
Same error here! And: # make . db.c: In function `acl_query': db.c:3751: error: `mailbox' undeclared (first use in this function) db.c:3751: error: (Each undeclared identifier is reported only once db.c:3751: error: for each function it appears in.) db.c: At top level: db.c:3748: warning: unused parameter 'mailbox_idnr' make[2]: *** [libdbmail_la-db.lo] Error 1 make[2]: Leaving directory `/export/hda3/0TMP/dbmail-2.1.5pre/dbmail' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/hda3/0TMP/dbmail-2.1.5pre/dbmail' make: *** [all] Error 2
