Linux start script updates
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
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
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.
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
"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
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
"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
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
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
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
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
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