On 16-Oct-04, at 1:11 PM, Charlie Brady wrote:

>> In Annvix, we ship both exim and postfix (exim being preferred... it
>> runs awesome supervised).  The same can't be said of postfix, however.
>
> You can't expect any help from Postfix's author:
>
> http://archives.neohapsis.com/archives/postfix/2001-08/1455.html
>
>  Postfix must be started with the postfix-script shell script that
>  is provided with the Postfix source code. Other startup procedures
>  are not supported. In other words, if you start Postfix in a
>  different manner, then you've broken the Postfix warranty. You do
>  so at your own risk, and I don't care why it breaks.
>
> [In case you are not aware, there is a long running feud between DJB 
> and
> Wietse Venema.]

Oh, I'm well aware of this feud... unfortunately, it's not limited to 
Venema and DJB, but to the respective qmail and postfix users.  I used 
to be a (non-rabid) qmail user.. I prefer the tranquility of exim now.  
=)

>> $daemon_directory/master 2>&1
>>
>>
>> I can't use exec for master because if I do I get this written to my
>> mail.log:
>>
>> Oct  9 14:31:46 test postfix/master[1941]: fatal: unable to set 
>> session
>> and process group ID: Operation not permitted
>
> Wietse goes on to say:
>
>  That said, the problem described below could be evidence of a bug
>  in the implementation of the setsid() system call.
>
>  The Postfix master "super-server" calls setsid(). setsid() makes
>  the Postfix master the leader of a new process group. Any signals
>  sent by Postfix to the default process group are limited to processes
>  within that new process group. If such a signal kills the master's
>  parent process, then then the kernel's implementation of setsid()
>  is broken and needs to be fixed.
>
> Which is all very easy to say. Perhaps he made that statement before
> checking the return value of setsid(), as postfix now appears to do.
>
> "man 2 setsid" should help you:
>
> ERRORS
>        On error, -1 will be returned.  The only  error  which  can  
> happen  is
>        EPERM.  It  is returned when the process group ID of any 
> process equals
>        the PID of the calling process. Thus, in particular,  setsid  
> fails if
>        the calling process is already a process group leader.
>
> I don't see the logic in postfix interpreting this as a fatal error.
> Postfix wanted to be the process group leader. It already was. Where's
> the fatal problem?

Hmmm... yeah... that doesn't make much sense.

>> However, for some odd reason if I manually run the run script (ie. sh
>> -x ./run) the master process starts and starts the children properly,
>> etc.
>
> That'd be right, since your shell is not a process group leader.

Ahhh... makes sense.

>> I'm really stumped on this one...
>
> You'll either need to ensure that the run script is not a process group
> leader (remove -P from runsvdir, and possibly add "chpst -P" to most 
> other
> run scripts), or fix postfix to turn the fatal error into a warning.

runsvdir doesn't run with -P.  I tried using chpst -P on postfix, but 
that didn't work.  I'm not too terribly interested in changing all the 
runscripts to chpst -P every other service (I haven't had the need to 
do it for any yet).

Patching postfix is not my idea of a good time, either.  I'd prefer to 
not mangle as much software as possible because it becomes a 
maintenance nuisance.

> They're my guesses, anyway. Like you, I choose not to run postfix, so I
> don't have first-hand experience with it and its foibles.

Lucky us I guess... =)

I think what I may end up doing is calling "postfix start" from stage 2 
if something like /etc/sysconfig/postfix contains "START=yes" or 
something similar.  Then in stage 3 I'll issue a "postfix stop".  Goes 
against how I like to do things, but it seems like "master" is doing a 
bit of supervision on it's own so instead of using (on Annvix anyways) 
"srv stop postfix" one would have to issue "postfix stop".  I dislike 
that it needs to be different, but at least this way I don't have to 
fall back to a traditional initscript.  I could then have a runscript 
for service postfix that just checks every few seconds to make sure 
that master is still running, and if it is, sleep for another 5 seconds 
and then do another check.  If master doesn't seem to be running, then 
just issue "postfix start" and sleep again.

A bit of a compromise, but I think it might be the best solution.

Thanks for the insight, Charlie.

-- 
Annvix - Secure Linux Server: http://annvix.org/
*Please note gpg keyid FE6F2AFD has been replaced with keyid FEE30AD4*
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}