From: Vincent Danen <vdanen@annvix.org>
Cc: "<supervision@list.skarnet.org><supervision@list.skarnet.org>"
<supervision@list.skarnet.org>
Subject: Re: supervising postfix
Date: Sat, 16 Oct 2004 13:28:02 -0600 [thread overview]
Message-ID: <7F25AD67-1FA9-11D9-8DD8-000A9598BFB2@annvix.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0410161255440.4200-100000@e-smith.charlieb.ott.istop.com>
[-- Attachment #1: Type: text/plain, Size: 4716 bytes --]
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}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
next prev parent reply other threads:[~2004-10-16 19:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-16 4:35 Vincent Danen
2004-10-16 19:11 ` Charlie Brady
2004-10-16 19:28 ` Vincent Danen [this message]
2004-10-16 20:11 ` Charlie Brady
2004-10-16 23:37 ` Vincent Danen
2004-10-17 1:38 ` Vincent Danen
2004-10-16 20:42 ` Charlie Brady
2004-11-01 21:45 ` Csillag Tamas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7F25AD67-1FA9-11D9-8DD8-000A9598BFB2@annvix.org \
--to=vdanen@annvix.org \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).