Re: gLSB: sysinit: clearify algorithm for determining status of programs

On Wed, Sep 03, 2003 at 05:46:08PM -0400, Bill Nottingham wrote:
> I don't like that as much because it implies duplicating that code
> in all the non-pidfile using scripts, but that's not a huge deal.

On Thu, Sep 04, 2003 at 07:15:49AM +0200, Thorsten Kukuk wrote:
> I don't like it at all and I don't see a real reason why we should
> change it in this way. Maybe we can say, that, if a pidfile is
> given on commandline, only this should be used and no fallback
> method?

Ok, I clearly underestimated the number of applications which don't have
a  pid file. There are three possibilities:

a) Forcing to use no other data but pid from pidfiles
["Compliant implementations shall not use other mechanisms
  besides using those based on pidfiles."]
While this has the beauty of beeing very deterministic (and is useful for
the cited real-world case, though it is rather special), there are
zillions of reasons to say: We don't want this!


b) Keep the gLSB 1.3.0 way:
["Compliant implementations of the LSB may attempt other mechanisms for
  determining the pid(s)"]
This makes it impossible use the init functions for daemons that are
started (independently) more than once. But it reflects the current
implementations and there are only a very few cases which need this.
(In this case one should add a <footnote> to point out that there may be
 problems when a daemon is started multiple times.)


c) other mechanisms are allowed, unless -p pidfile has been used
This kind of a compromise came not only to my mind (after leaving
the office) but also Thorsten had this idea. The advantage is that no
init script needs to be changed (who uses a -p pidfile argument
if there will never be a pidfile?) while it allows to start multiple
damons. How about this:
"Compliant implementations may use other mechanisms besides using those
 based on pidfiles, unless the -p pidfile option has been used."


Ok, (a) is dropped, can we agree on (c) or is there anyone who favours
(b) or a - to be defined - (d)?


Tobias


--- initfunctions.sgml  3 Sep 2003 20:23:32 -0000       1.14
+++ initfunctions.sgml  4 Sep 2003 13:32:41 -0000
@@ -35,2 +35,3 @@
-Compliant implementations may (but should not) use other mechanisms besides those based on
-pidfiles. Compliant applications should not rely on such mechanisms and should
+Compliant implementations may use other mechanisms besides those based on
+pidfiles, unless the -p pidfile option has been used. Compliant applications
+should not rely on such mechanisms and should