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

>>> 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).
>
> It's a defensive measure. you can't control when or if a process will 
> kill
> its own process group. And you don't want any of those processes taking
> out all your stage 2. You won't have the need for it, until you have 
> the
> need for it!

Hmmm... so should I be running runsvdir with -P then?  And if I do, do 
I need to run chpst -P on all the other services?

Defensive measures are good, I'm just not sure of the best way to 
implement it.  Is running runsvdir with -P sufficient, I guess is what 
I'm asking.

>> 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.
>
> Sure, but you already have a maintenance problem, right now. Postfix
> doesn't run for you.

Well, it does.  Not the way that I exactly want, but I can start 
postfix from stage 1 and have it work.  Of course, if I do it this way 
I have to "exec chpst -P postfix start &" which isn't elegant.

I'm recompiling postfix now with the change to master.c you noted in 
your next email and we'll see if I can make master run under 
supervision and do the right thing.

> If you are not using -P anywhere, then maybe you've found a bug with
> postfix, and it is trying multiple times to become process group 
> leader or
> something. Have you straced it, so you can see what is being called 
> when?

Yeah, but most of that is greek to me.  =)

>> 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.
>
> Sounds aweful :-(

It's not, but not really what I want either.  It works, which is 
something, and it still doesn't rely on clumsy initscripts.  It just 
isn't quite the way I wanted it, but we'll see if making master warn on 
setsid() failure makes it work "properly".

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