Re: supervising postfix

[Charlie Brady <charlieb-supervision@budge.apana.org.au>]

On Fri, 15 Oct 2004, Vincent Danen 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.]

> $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?
 
> 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.

> 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. 

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.

> Anyone have any ideas they could toss to me?  I'm about ready for any 
> bones here and willing to try anything.  If I had hair I'd be ripping 
> it out.

:-)

---
Charlie