Am Montag, 20. März 2006 18:52 schrieb Bernhard Reiter:
> Am Montag, 20. März 2006 18:41 schrieb Bill Campbell:
> > On Mon, Mar 20, 2006, Bernhard Reiter wrote:
> > >Am Montag, 20. März 2006 13:32 schrieb Bernhard Reiter:
> > >> Using OpenPKG 2.5
> > >>
> > >> b) postfix
> > >> /kolab/sbin/postfix start
> > >> failed, because of an old master.pid (without process).
> > >> The message of postfix-scripts did not end up in the logs
> > >> and openpkg did not fail.
> > >
> > >This was more complicated then I have thought.
> > >On a start attempt, OpenPKG will do
> > > rcService postfix enable yes || exit 0
> > > rcService postfix active yes && exit 0
> > > /kolab/sbin/postfix start
> > >
> > >The "rcService postfix active yes" line will call rc.kolab status
> > >which again calls master -t to test if the postfix is running or not.
> > >For whatever reasons "master -t" did return that postfix was still
> > > active, this probably was the stale lock. So the script of OpenPKG just
> > > did not try to restart postfix without any error message.
> > >
> > >Note that /kolab/sbin/postfix start would
> > >end up running /kolab/sbin/postfix-script
> > >which would have done the same test,
> > >but would have issued an error message.
> > >
> > >The main problem with this approach
> > >is that a non-negative return code of "master -t"
> > >cannot be used as a test that postfix is active.
> > >It means: postfix is active or the application is broken.
> > >
> > >In case of the special situation described,
> > >OpenPKG behaves badly.
> > >There does not seem to be an easy remedy.
> > >I did not discover a test if postfix is actually running,
> > >so the line cannot easily be exchanged.
> > >Maybe looking for "master" in the process table in addition to master
> > > -t, would make this test more robust.
> >
> > Perhaps it would be better to use the standard tests
> > on %{l_prefix}/var/postfix/pid/master.pid instead of the one
> > calling master -t?
>
> I have looked at the code for master -t and it first does an existance
> test for master.pid and the tries to get the lock for it.
> This is the right test in principle, so doing it manually instead of master
> -t will not prove the situation I think.
> Having master -t existing "1" and no "master" process before
> in the process list, would at least exculde other error conditions.Thus I am suggesting the following patch (only minimally tested).
--- rc.postfix.org 2006-03-21 08:41:50.775905000 +0100
+++ rc.postfix 2006-03-21 08:40:27.519905000 +0100
@@ -19,7 +19,9 @@
postfix_usable="no"
postfix_active="no"
/kolab/sbin/postfix check >/dev/null 2>&1 && postfix_usable="yes"
- /kolab/libexec/postfix/master -t >/dev/null 2>&1 || postfix_active="yes"
+ { ! ps -elf|grep postfix/m[a]ster >/dev/null 2>&1 && \
+ /kolab/libexec/postfix/master -t >/dev/null 2>&1 ; } || \
+ postfix_active="yes"
echo "postfix_enable=\"$postfix_enable\""
echo "postfix_usable=\"$postfix_usable\""
echo "postfix_active=\"$postfix_active\""
pgpoKS4UaSf3j.pgp
Description: PGP signature
