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.

> I know there was a problem with using the postgresql native tests
> because they didn't detect a stale pid file.

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
User Communication List                      openpkg-users@openpkg.org

Reply via email to