Thread

Linux start script updates

Kevin Grittner <kevin.grittner@wicourts.gov> — 2009-08-20T15:31:40Z

Due to a thread about the neglect of the sample start scripts I took a
look at the current Linux file.  There's certainly room for several
improvements, but some of them might require discussion.  Attached are
a couple small changes which seem to me to be pretty tame.  Hopefully
a small, non-controversial step in the right direction.
 
(1)  It adds an LSB INIT INFO comment block, consistent with the
chkconfig comment block above it.
 
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
 
(2)  It doesn't exit with zero for a missing executable unless the
request is "stop".  It uses 5, which means "program is not installed".
 
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
 
-Kevin

Re: Linux start script updates

Bruce Momjian <bruce@momjian.us> — 2010-02-23T22:18:00Z

Kevin Grittner wrote:
> Due to a thread about the neglect of the sample start scripts I took a
> look at the current Linux file.  There's certainly room for several
> improvements, but some of them might require discussion.  Attached are
> a couple small changes which seem to me to be pretty tame.  Hopefully
> a small, non-controversial step in the right direction.
>  
> (1)  It adds an LSB INIT INFO comment block, consistent with the
> chkconfig comment block above it.
>  
> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
>  
> (2)  It doesn't exit with zero for a missing executable unless the
> request is "stop".  It uses 5, which means "program is not installed".
>  
> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

I applied a modified version of your script, attached.  I also modified
the FreeBSD one to output a message, but it still returns 0.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +

Re: Linux start script updates

Peter Eisentraut <peter_e@gmx.net> — 2010-03-01T13:13:14Z

On tor, 2009-08-20 at 10:31 -0500, Kevin Grittner wrote:
> (2)  It doesn't exit with zero for a missing executable unless the
> request is "stop".  It uses 5, which means "program is not installed".

Using 5 is correct, but special-casing "stop" is kind of useless.  Every
other init script I have ever seen that attempts to handle this, doesn't
bother.

Re: Linux start script updates

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-03-01T15:07:58Z

Peter Eisentraut <peter_e@gmx.net> wrote:
> On tor, 2009-08-20 at 10:31 -0500, Kevin Grittner wrote:
>> (2)  It doesn't exit with zero for a missing executable unless
>> the request is "stop".  It uses 5, which means "program is not
>> installed".
> 
> Using 5 is correct, but special-casing "stop" is kind of useless. 
> Every other init script I have ever seen that attempts to handle
> this, doesn't bother.

I can't see a clear case either way.  I know I *have* seen scripts
which took the trouble to special-case it, but I just poked around
and found that it seems much less common than unconditionally using
"exit 5".  Does anyone know of an environment where it matters?

-Kevin

Re: Linux start script updates

Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-01T16:31:18Z

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I can't see a clear case either way.  I know I *have* seen scripts
> which took the trouble to special-case it, but I just poked around
> and found that it seems much less common than unconditionally using
> "exit 5".  Does anyone know of an environment where it matters?

Probably not.  You might find it entertaining to read the current
Fedora guidelines for init scripts:

https://fedoraproject.org/wiki/Packaging:SysVInitScript

The skeleton shown there only bothers to throw exit 5 when the
program is missing at start time.

I think though that the answer to Peter's question is that "stop" has to
be special cased to some extent, because it is not supposed to be an
error to stop a service that's not running.  If it's not even installed,
then a fortiori it's not running, so the exit code *must* be 0 not 5 in
that case.  I've even been told that you should get 0 if you run
"service foo stop" on a non-running service as a non-superuser,
ie, a case where you *would* get a failure (no permissions) if the
service were running.  I'm not sure I believe that last bit myself,
but Red Hat has got some test scripts that think this.

			regards, tom lane

Re: Linux start script updates

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-03-01T16:56:45Z

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I think though that the answer to Peter's question is that "stop"
> has to be special cased to some extent, because it is not supposed
> to be an error to stop a service that's not running.  If it's not
> even installed, then a fortiori it's not running, so the exit code
> *must* be 0 not 5 in that case.

Exactly.  With Fedora respecting the standard in this regard, I'm
convinced we should, too.  In reviewing things based on Peter's
question, I did start to have doubts about *not* special-casing
"status" -- it has its own set of values and 5 is not assigned, so
using it seems wrong.  It seems like it should be 3 ("program is not
running").  Agreed?

-Kevin

Re: Linux start script updates

Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-01T17:04:38Z

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Exactly.  With Fedora respecting the standard in this regard, I'm
> convinced we should, too.  In reviewing things based on Peter's
> question, I did start to have doubts about *not* special-casing
> "status" -- it has its own set of values and 5 is not assigned, so
> using it seems wrong.  It seems like it should be 3 ("program is not
> running").  Agreed?

Probably.  I think that in practice most scripts are not very tense
about this --- as long as the exit code is 0 or not-0 per spec, which
not-0 value is reported is not so exciting to most people.

			regards, tom lane

Re: Linux start script updates

Bruce Momjian <bruce@momjian.us> — 2010-03-03T23:07:24Z

Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > Exactly.  With Fedora respecting the standard in this regard, I'm
> > convinced we should, too.  In reviewing things based on Peter's
> > question, I did start to have doubts about *not* special-casing
> > "status" -- it has its own set of values and 5 is not assigned, so
> > using it seems wrong.  It seems like it should be 3 ("program is not
> > running").  Agreed?
> 
> Probably.  I think that in practice most scripts are not very tense
> about this --- as long as the exit code is 0 or not-0 per spec, which
> not-0 value is reported is not so exciting to most people.

So, do the startup scripts as they exist in CVS need any adjustment?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

Re: Linux start script updates

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-03-04T14:46:08Z

Bruce Momjian <bruce@momjian.us> wrote:
> Tom Lane wrote:
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> > Exactly.  With Fedora respecting the standard in this regard,
>> > I'm convinced we should, too.  In reviewing things based on
>> > Peter's question, I did start to have doubts about *not*
>> > special-casing "status" -- it has its own set of values and 5
>> > is not assigned, so using it seems wrong.  It seems like it
>> > should be 3 ("program is not running").  Agreed?
>> 
>> Probably.  I think that in practice most scripts are not very
>> tense about this --- as long as the exit code is 0 or not-0 per
>> spec, which not-0 value is reported is not so exciting to most
>> people.
> 
> So, do the startup scripts as they exist in CVS need any
> adjustment?

It would be trivial to make it a tiny bit more correct, but it's
probably not worth it.  Almost all init scripts I've seen don't
bother to make this more correct, and some in the community seem to
prefer brevity in this script over correctness -- we got a complaint
about having a few characters in there to take it this far.  I'm
inclined to say it's good enough.

If we want a more compliant Linux script, the community preference
seems to be that we do most of that work in pg_ctl, for which we now
have a TODO or two.

-Kevin

Re: Linux start script updates

Robert Haas <robertmhaas@gmail.com> — 2010-03-04T15:46:22Z

On Thu, Mar 4, 2010 at 9:46 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
>> Tom Lane wrote:
>>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>>> > Exactly.  With Fedora respecting the standard in this regard,
>>> > I'm convinced we should, too.  In reviewing things based on
>>> > Peter's question, I did start to have doubts about *not*
>>> > special-casing "status" -- it has its own set of values and 5
>>> > is not assigned, so using it seems wrong.  It seems like it
>>> > should be 3 ("program is not running").  Agreed?
>>>
>>> Probably.  I think that in practice most scripts are not very
>>> tense about this --- as long as the exit code is 0 or not-0 per
>>> spec, which not-0 value is reported is not so exciting to most
>>> people.
>>
>> So, do the startup scripts as they exist in CVS need any
>> adjustment?
>
> It would be trivial to make it a tiny bit more correct, but it's
> probably not worth it.  Almost all init scripts I've seen don't
> bother to make this more correct, and some in the community seem to
> prefer brevity in this script over correctness -- we got a complaint
> about having a few characters in there to take it this far.  I'm
> inclined to say it's good enough.
>
> If we want a more compliant Linux script, the community preference
> seems to be that we do most of that work in pg_ctl, for which we now
> have a TODO or two.

AFAIR Peter is the only one who has complained about the script being
longer, and I'm really not sure why that's a big deal.

...Robert

Re: Linux start script updates

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-03-04T17:00:46Z

Robert Haas <robertmhaas@gmail.com> wrote:

> AFAIR Peter is the only one who has complained about the script
> being longer, and I'm really not sure why that's a big deal.

I'll take that under advisement for later.  I'm not inclined to
think there's anything here worth trying to squeeze into 9.0, and
I'm assuming that isn't what you were suggesting, either.

Personally, though, I don't understand his concern about length per
se, but recognize that some of the improvements could have value
outside of Linux environments; which makes a case for putting what
we can into pg_ctl.  That the script becomes shorter and easier to
read and understand may have some limited value, but I see that as
secondary.

-Kevin

Re: Linux start script updates

Robert Haas <robertmhaas@gmail.com> — 2010-03-04T17:05:55Z

On Thu, Mar 4, 2010 at 12:00 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> AFAIR Peter is the only one who has complained about the script
>> being longer, and I'm really not sure why that's a big deal.
>
> I'll take that under advisement for later.  I'm not inclined to
> think there's anything here worth trying to squeeze into 9.0, and
> I'm assuming that isn't what you were suggesting, either.

I'm OK either way.  Changes to init scripts are unlikely to break
anything since many users won't use them.  And if the changes are
minor even moreso.  But postponing it is one less thing to deal with,
so I'm happy with that.

> Personally, though, I don't understand his concern about length per
> se, but recognize that some of the improvements could have value
> outside of Linux environments; which makes a case for putting what
> we can into pg_ctl.  That the script becomes shorter and easier to
> read and understand may have some limited value, but I see that as
> secondary.

That's a good point.

...Robert