Linux start script updates

Started by Kevin Grittnerover 16 years ago12 messages
#1Kevin Grittner
Kevin.Grittner@wicourts.gov
1 attachment(s)

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

Attachments:

start-linux-1.diffapplication/octet-stream; name=start-linux-1.diffDownload
Index: contrib/start-scripts/linux
===================================================================
RCS file: /projects/cvsroot/pgsql/contrib/start-scripts/linux,v
retrieving revision 1.8
diff -c -d -r1.8 linux
*** contrib/start-scripts/linux	13 Jul 2006 14:44:33 -0000	1.8
--- contrib/start-scripts/linux	20 Aug 2009 14:44:44 -0000
***************
*** 3,8 ****
--- 3,20 ----
  # chkconfig: 2345 98 02
  # description: PostgreSQL RDBMS
  
+ ### BEGIN INIT INFO
+ # Provides: postgresql
+ # Required-Start: $local_fs $network $syslog
+ # Should-Start: $named $time
+ # Required-Stop: $local_fs $network $syslog
+ # Should-Stop: $named
+ # Default-Start: 2 3 4 5
+ # Default-Stop: 0 1 6
+ # Short-Description: PostgreSQL RDBMS
+ # Description: PostgreSQL RDBMS service
+ ### END INIT INFO
+ 
  # This is an example of a start/stop script for SysV-style init, such
  # as is used on Linux systems.  You should edit some of the variables
  # and maybe the 'echo' commands.
***************
*** 56,62 ****
  set -e
  
  # Only start if we can find the postmaster.
! test -x $DAEMON || exit 0
  
  # Parse command line parameters.
  case $1 in
--- 68,79 ----
  set -e
  
  # Only start if we can find the postmaster.
! test -x $DAEMON || \
!   {
!     echo "$DAEMON not found" ;
!     if [ "$1" = "stop" ] ; then exit 0 ;
!     else exit 5 ; fi ;
!   }
  
  # Parse command line parameters.
  case $1 in
#2Bruce Momjian
bruce@momjian.us
In reply to: Kevin Grittner (#1)
1 attachment(s)
Re: Linux start script updates

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. +

Attachments:

/rtmp/difftext/x-diffDownload
Index: contrib/start-scripts/linux
===================================================================
RCS file: /cvsroot/pgsql/contrib/start-scripts/linux,v
retrieving revision 1.10
diff -c -c -r1.10 linux
*** contrib/start-scripts/linux	11 Jan 2010 18:39:32 -0000	1.10
--- contrib/start-scripts/linux	23 Feb 2010 22:08:13 -0000
***************
*** 64,70 ****
  set -e
  
  # Only start if we can find the postmaster.
! test -x $DAEMON || exit 0
  
  # Parse command line parameters.
  case $1 in
--- 64,78 ----
  set -e
  
  # Only start if we can find the postmaster.
! test -x $DAEMON ||
! {
! 	echo "$DAEMON not found"
! 	if [ "$1" = "stop" ]
! 	then exit 0
! 	else exit 5
! 	fi
! }
! 
  
  # Parse command line parameters.
  case $1 in
#3Peter Eisentraut
peter_e@gmx.net
In reply to: Kevin Grittner (#1)
Re: Linux start script updates

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.

#4Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Peter Eisentraut (#3)
Re: Linux start script updates

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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kevin Grittner (#4)
Re: Linux start script updates

"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

#6Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Tom Lane (#5)
Re: Linux start script updates

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

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kevin Grittner (#6)
Re: Linux start script updates

"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

#8Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#7)
Re: Linux start script updates

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

#9Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Bruce Momjian (#8)
Re: Linux start script updates

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

#10Robert Haas
robertmhaas@gmail.com
In reply to: Kevin Grittner (#9)
Re: Linux start script updates

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

#11Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: Robert Haas (#10)
Re: Linux start script updates

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

#12Robert Haas
robertmhaas@gmail.com
In reply to: Kevin Grittner (#11)
Re: Linux start script updates

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