Re: Linux LSB init script

Here's a first rough cut of Linux script which attempts to launch
PostgreSQL as a somewhat LSB conforming application. It's very
lightly tested and I haven't gone through to confirm that every corner
case is handled exactly right; in fact on my kubuntu workstation (the
only place I've tested so far) the status command returns 4 ("program
or service status is unknown") when I think it should be returning 3
("program is not running"), so I've got something to chase down there.
And I haven't even tried to deal with the "false positive" problem
yet.

But before I spend a lot of time fine-tuning it, I wanted to post this
as a proof-of-concept draft and see if people think it's on the right
track.

Did I do anything which is considered "bad technique"?

Am I using any techniques which aren't sufficiently portable?

Is anything just outright *wrong*?

Comments welcome.

-Kevin

I wrote:

> But before I spend a lot of time fine-tuning it, I wanted to post
> this as a proof-of-concept draft and see if people think it's on the
> right track.

I chose to take the lack of response as an indication that nobody who
cares about this thought there was anything seriously wrong with the
draft, so I tidied it up and did more testing. I'm submitting this
for the next CommitFest.

I'm attaching the file which I propose to include in the
contrib/start-scripts subdirectory. If it is preferred that a new
file be in patch form, I need a clue from someone how to create that.

-Kevin

On Fri, Aug 28, 2009 at 04:41:47PM -0500, Kevin Grittner wrote:
> I wrote:
>
> > But before I spend a lot of time fine-tuning it, I wanted to post
> > this as a proof-of-concept draft and see if people think it's on
> > the right track.
>
> I chose to take the lack of response as an indication that nobody
> who cares about this thought there was anything seriously wrong with
> the draft, so I tidied it up and did more testing. I'm submitting
> this for the next CommitFest.
>
> I'm attaching the file which I propose to include in the
> contrib/start-scripts subdirectory. If it is preferred that a new
> file be in patch form, I need a clue from someone how to create
> that.

cvs diff if you're on CVS. If you're using git, commit to your local
repository and git-diff.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david(at)fetter(dot)org> wrote:

> cvs diff if you're on CVS. If you're using git, commit to your
> local repository and git-diff.

I tried that. When I just did it at the top level, it ignored the new
file. When I specified the file:

kgrittn(at)kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N
contrib/start-scripts/linux-lsb > ../linux-lsb.patch
cvs diff: I know nothing about contrib/start-scripts/linux-lsb

Same behavior with and without the -N flag. What am I missing?

-Kevin

On Fri, Aug 28, 2009 at 04:57:24PM -0500, Kevin Grittner wrote:
> David Fetter <david(at)fetter(dot)org> wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the
> new file. When I specified the file:
>
> kgrittn(at)kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N
> contrib/start-scripts/linux-lsb > ../linux-lsb.patch
> cvs diff: I know nothing about contrib/start-scripts/linux-lsb
>
> Same behavior with and without the -N flag. What am I missing?

Might be easier with git, then :/

Cheers,
David (let's move to git!)
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, Aug 28, 2009 at 10:57 PM, Kevin
Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> David Fetter <david(at)fetter(dot)org> wrote:
>
>> cvs diff if you're on CVS.  If you're using git, commit to your
>> local repository and git-diff.
>
> I tried that.  When I just did it at the top level, it ignored the new
> file.  When I specified the file:

You have to "cvs add" the file

--
greg
http://mit.edu/~gsstark/resume.pdf

On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
> On Fri, Aug 28, 2009 at 10:57 PM, Kevin
> Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> > David Fetter <david(at)fetter(dot)org> wrote:
> >
> >> cvs diff if you're on CVS.  If you're using git, commit to your
> >> local repository and git-diff.
> >
> > I tried that.  When I just did it at the top level, it ignored the new
> > file.  When I specified the file:
>
> You have to "cvs add" the file

That only works if you have write permissions to the central repo. I
don't.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On fre, 2009-08-28 at 16:57 -0500, Kevin Grittner wrote:
> David Fetter <david(at)fetter(dot)org> wrote:
>
> > cvs diff if you're on CVS. If you're using git, commit to your
> > local repository and git-diff.
>
> I tried that. When I just did it at the top level, it ignored the new
> file. When I specified the file:
>
> kgrittn(at)kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N
> contrib/start-scripts/linux-lsb > ../linux-lsb.patch
> cvs diff: I know nothing about contrib/start-scripts/linux-lsb
>
> Same behavior with and without the -N flag. What am I missing?

If it's a new file, it's pointless to send a patch anyway.

You could also consider putting it in place of the linux file.

On Fri, Aug 28, 2009 at 11:59 PM, David Fetter<david(at)fetter(dot)org> wrote:
>> You have to "cvs add" the file
>
> That only works if you have write permissions to the central repo.  I
> don't.

True. The only workable way to use cvs that i found was to rsync the
repository and then check out from that. If you cvs add then then the
next rsync will overwrite your cvs add but in the meantime i think you
could do cvs diff.

--
greg
http://mit.edu/~gsstark/resume.pdf

David Fetter wrote:
> On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote:
>
>> On Fri, Aug 28, 2009 at 10:57 PM, Kevin
>> Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>
>>> David Fetter <david(at)fetter(dot)org> wrote:
>>>
>>>
>>>> cvs diff if you're on CVS. If you're using git, commit to your
>>>> local repository and git-diff.
>>>>
>>> I tried that. When I just did it at the top level, it ignored the new
>>> file. When I specified the file:
>>>
>> You have to "cvs add" the file
>>
>
> That only works if you have write permissions to the central repo. I
> don't.
>
>
>

cvsutils IYF. See <http://www.red-bean.com/cvsutils/>

If you're on Fedora at least "yum install cvsutils" should be all you
need to do.

cheers

andrew

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> If it's a new file, it's pointless to send a patch anyway.

If people are OK with just sending the new file, that's cool with me.
>From the other posts, it appears that I need to have my own copy of
the repository to do it as a patch, or download a tool. (Thanks to
those who offered the suggestions.)

> You could also consider putting it in place of the linux file.

Is the LSB standard sufficiently widely adopted to omit the older
format? I was concerned that there might be Linux versions we wanted
to support which wouldn't have a /lib/lsb/init-functions file to
source. If that's not an issue, I could submit this as a patch to the
existing file. (It'd be a - for almost every non-blank line in the
old, and a + for almost every non-blank line in the new, of course.)

-Kevin

Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> cvsutils

That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a couple minor fixes to what I posted in "new
file" form. I was holding off on the CommitFest entry until I sorted
out the format; I'll link here as version 1 of the patch.

-Kevin

On Mon, 31 Aug 2009, Kevin Grittner wrote:

> Is the LSB standard sufficiently widely adopted to omit the older
> format?

I'm not sure, and I'm similarly not sure just what the benefits of a LSB
compatible script are here given that several major distributions like
RHEL/Debian have their own thing they're doing and are unlikely to change.
Given that there was recent chatter on removing the Linux init scripts
altogether, I think that the first thing to do here is survey where the
current script and a LSB-based one might fit into current/future Linux
init script plans on the most popular platforms. Your code is interesting
but I'm not sure what problem it's intended to solve yet.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith(at)gregsmith(dot)com> wrote:

> I'm similarly not sure just what the benefits of a LSB compatible
> script are here given that several major distributions like
> RHEL/Debian have their own thing they're doing and are unlikely to
> change.

I don't know about other platforms, but on SuSE Linux, you're not
likely to get things installed properly to start and stop in the right
timing with other services unless you have a good INIT INFO block and
use the appropriate OS tools to "install" it. You might get it right
for the time being by adding a bunch of symlinks by hand, but it'd be
liable to break next time something was installed "by the book."

> Given that there was recent chatter on removing the Linux init
> scripts altogether,

I thought that suggestion got rather a cool reception...

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01393.php
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01394.php
http://archives.postgresql.org/pgsql-hackers/2009-08/msg01398.php

> I think that the first thing to do here is survey where the
> current script and a LSB-based one might fit into current/future
> Linux init script plans on the most popular platforms. Your code is
> interesting but I'm not sure what problem it's intended to solve
> yet.

The current linux script, and the techniques recommended so far, don't
play well in an environment where you want the LSB INIT INFO
specifications of the services to ensure that each services waits
until the right time to start.

It's still somewhat flawed, in that PostgreSQL doesn't give you a way
to wait until it's ready to accept connections:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01735.php

but this script could be expanded to deal with that better. I see it
as a pretty solid base to build on. I think it might be premature to
try to address that issue because of the interest in creating a
pg_ping functionality, which is what would make this nice and clean:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01741.php

I didn't proceed to try to write up a solid patch which I felt
suitable for public distribution without someone seconding the motion,
as it were:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01780.php

Let me know if you have any concerns I didn't address.

-Kevin

On mån, 2009-08-31 at 12:07 -0500, Kevin Grittner wrote:
> Is the LSB standard sufficiently widely adopted to omit the older
> format? I was concerned that there might be Linux versions we wanted
> to support which wouldn't have a /lib/lsb/init-functions file to
> source. If that's not an issue, I could submit this as a patch to the
> existing file. (It'd be a - for almost every non-blank line in the
> old, and a + for almost every non-blank line in the new, of course.)

While the major distributions support LSB, the major distributions also
have PostgreSQL packages available and so will likely not need the init
script shipped in the source. It will most likely be useful for various
do-it-yourself setups on fringe distributions. So I don't know; it
might be best to keep both, if they are maintained.

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> While the major distributions support LSB, the major distributions
> also have PostgreSQL packages available and so will likely not need
> the init script shipped in the source.

My counter-argument to that would be that the SuSE distribution's
version of PostgreSQL is so out-of-date that we don't install it. It
also doesn't enable debug info or integer date times. So we switched
to build from source before we actually got as far as loading any
data. I'm inclined to recommend the same to others.

> it might be best to keep both, if they are maintained.

Sounds good to me; although, now that there is a full LSB version, I
should probably withdraw my meager suggested patch to the existing
linux script, eh? (If they're using an LSB conforming implementation,
they'll want the linux-lsb script, and if they're not, the suggested
patch has no point, I think.) Unless someone thinks otherwise, I'll
drop that patch to the linux script from the CF page. Any thoughts on
what that script needs, if anything?

-Kevin

On Mon, 31 Aug 2009, Kevin Grittner wrote:

> My counter-argument to that would be that the SuSE distribution's
> version of PostgreSQL is so out-of-date that we don't install it.

Given that it's also RPM based, is it possible to get SuSE in sync so that
it shares the same init script as RHEL? Devrim is in the middle of a
major overhaul of the RHEL/Fedora init script lately, adding better
support for multiple postmasters and the like, and I'd think that SuSE
users would like to take advantage of that work too.

It seems to me that the only popular Linux versions that people use for
PostgreSQL work that don't have active init script maintainers are SuSE
and Gentoo. If your LSB-based approach could be made to work on both
those, that would be a nice step forward. I don't know what the state of
the init script that Gentoo ships is though, I'm guessing it may diverge
from the standard approach due to its slots implementation.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On mån, 2009-08-31 at 20:54 -0400, Greg Smith wrote:
> On Mon, 31 Aug 2009, Kevin Grittner wrote:
>
> > My counter-argument to that would be that the SuSE distribution's
> > version of PostgreSQL is so out-of-date that we don't install it.
>
> Given that it's also RPM based, is it possible to get SuSE in sync so that
> it shares the same init script as RHEL? Devrim is in the middle of a
> major overhaul of the RHEL/Fedora init script lately, adding better
> support for multiple postmasters and the like, and I'd think that SuSE
> users would like to take advantage of that work too.

Well, the init script of the SUSE RPM is not the problem. (It was,
arguably, one of the bright spots for a long time, since they removed
lots of legacy wackyness accumulated from the Red Hat era.)

On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:
> My counter-argument to that would be that the SuSE distribution's
> version of PostgreSQL is so out-of-date that we don't install it. It
> also doesn't enable debug info or integer date times. So we switched
> to build from source before we actually got as far as loading any
> data. I'm inclined to recommend the same to others.

Fixes and help are welcome, btw.

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote:

>> the SuSE distribution's version of PostgreSQL is so out-of-date
>> that we don't install it. It also doesn't enable debug info or
>> integer date times.

> Fixes and help are welcome, btw.

We're using SLES10. If we installed the latest from the SuSE site, we
would be at PostgreSQL version 8.1. Now, to their credit, that is
8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
whether to go back to 8.1.

And unless I'm remembering incorrectly, the configure options are not
what we would want. I don't see any reason the packaged build
shouldn't be with --enable-debug on a platform where that has no
performance hit. I never understood why anyone converting to
PostgreSQL would want the floating point approximate timestamps rather
than using --enable-integer-datetimes. We don't have a need for
multiple languages, so I figure it's best to use --diable-nls,
although I doubt that one's a huge deal. Since we have much XML in
our database, I'm building with --with-libxml, just in case someone
decides they want to use xpath. And since we often need more than one
version of PostgreSQL on a server, we always use a prefix of
/usr/local/pgsql-<version> and use a symlink to map one version to the
"default" we put on our PATH. (Our init scripts always point to the
version-specific locations.)

I wouldn't expect a packaged SuSE build to cater to all of that; but
it would be nice if they donated their init script to the PostgreSQL
project, so that those of us who have a reason to build from source
on SuSE have have a convenient starting point in the source
distribution of PostgreSQL.

I seem to remember that SuSE has an abstraction layer similar to the
functions I defined in my linux-lsb script. I couldn't use those in a
portable LSB submission, but if there's anything in what I did which
is of any use to SuSE, there's no reason for SuSE not to use it. I'm
putting it under the same license as the rest of PostgreSQL.
Although, now that I think of it, I don't think I actually put any
copyright or license message into the file yet.

In any event, I think I've come up with something which should work
pretty well on any LSB conforming implementation, including SuSE. If
we get the pg_ping functionality which is occassionally discussed, it
can be made really bulletproof.

-Kevin

On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
> We're using SLES10. If we installed the latest from the SuSE site, we
> would be at PostgreSQL version 8.1. Now, to their credit, that is
> 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
> whether to go back to 8.1.

Well, that is not surprising. At the time SLES 10 was released,
PostgreSQL 8.1 was the stable PostgreSQL release. If you want major
upgrades, you shouldn't be looking for the SLES 10 upgrade channel to
provide you that. If you want to have out-of-line, unsupported updates,
you can get them from the OpenSuse build service. I think you will find
exactly the same/analogous situation for any enterprise Linux
distribution or other operating system.

> And unless I'm remembering incorrectly, the configure options are not
> what we would want. I don't see any reason the packaged build
> shouldn't be with --enable-debug on a platform where that has no
> performance hit.

Debatable, but it's not upstream default, so why should it be downstream
default?

> I never understood why anyone converting to
> PostgreSQL would want the floating point approximate timestamps rather
> than using --enable-integer-datetimes.

Backward compatibility. Same issue with RHEL; discussion in archives.

> We don't have a need for
> multiple languages, so I figure it's best to use --diable-nls,
> although I doubt that one's a huge deal.

Well, that's not a reason to rebuild from source, although it could be a
reason to rebuild the RPM.

> I wouldn't expect a packaged SuSE build to cater to all of that; but
> it would be nice if they donated their init script to the PostgreSQL
> project, so that those of us who have a reason to build from source
> on SuSE have have a convenient starting point in the source
> distribution of PostgreSQL.

Well, no one needs to donate anything. If you are interested in
maintaining it, just take it and put it under contrib/start-scripts.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> And unless I'm remembering incorrectly, the configure options are not
>> what we would want. I don't see any reason the packaged build
>> shouldn't be with --enable-debug on a platform where that has no
>> performance hit.

> Debatable, but it's not upstream default, so why should it be downstream
> default?

FWIW, that particular issue is invariably a matter of distro policy;
they could care less what upstream's default is. For instance Red Hat
*always* builds all RPMs with debug enabled, and then splits the debug
data off into separate "debuginfo" RPMs, which are not installed by
default for space/bandwidth reasons. But you can get debug symbols when
you need 'em. I don't know what Debian or SUSE do, but I'm sure they do
it consistently across all their packages. A lot of other packaging
choices are likewise driven by distro-wide policy and not what a
particular upstream package might choose as default.

regards, tom lane

On Sep 1, 2009, at 6:43 PM, Tom Lane wrote:

>> Debatable, but it's not upstream default, so why should it be
>> downstream
>> default?
>
> FWIW, that particular issue is invariably a matter of distro policy;
> they could care less what upstream's default is.

Well, they could, but do they?

/me offers Tom a "not".

Best,

David

Kevin Grittner wrote:
>
> We're using SLES10. If we installed the latest from the SuSE site, we
> would be at PostgreSQL version 8.1. Now, to their credit, that is
> 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
> whether to go back to 8.1.
>

I recently build 8.4 RPMs for SLES10/SP2 and they are running very
nicely for a very happy customer. IIRC I got the SRPM from the OpenSuse
site.

cheers

andrew

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:

>> I wouldn't expect a packaged SuSE build to cater to all of that;
>> but it would be nice if they donated their init script to the
>> PostgreSQL project, so that those of us who have a reason to build
>> from source on SuSE have have a convenient starting point in the
>> source distribution of PostgreSQL.
>
> Well, no one needs to donate anything. If you are interested in
> maintaining it, just take it and put it under contrib/start-scripts.

Hmmm... I didn't look at the SuSE init script for PostgreSQL before
writing my LSB script because

(1) I was concerned that any similarities might be considered a
violation of some copyright. By writing them "cold" I had the "clean
room" argument -- similarities are because it's the obvious way to
solve the problem; noting was copied, so there is no violation of the
copyright.

(2) We don't have the distribution's PostgreSQL package installed on
any of our machines, so I'd have to install it and risk breaking
something to even have a look at it.

My assumption was that, like most of the init scripts in the SuSE
distribution, it would contain this:

# Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
# All rights reserved.

and that I would be violating that copyright by copying it to
PostgreSQL. Am I wrong?

-Kevin

Kevin Grittner wrote:
>
> (2) We don't have the distribution's PostgreSQL package installed on
> any of our machines, so I'd have to install it and risk breaking
> something to even have a look at it.
>
>
>

Umm, no, you could either install the SRPM in a build directory, and
look there, or extract the script from the built RPM using rpm2cpio.

cheers

andrew

On Wed, Sep 2, 2009 at 3:13 PM, Kevin
Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
> # All rights reserved.
>
> and that I would be violating that copyright by copying it to
> PostgreSQL.  Am I wrong?

The above is just a statement of fact. It doesn't change the legal
status (well not much). What you need to know is what license SUSE has
granted. I would expect it to be either GPL or BSD but I don't really
know SUSE.

If it's BSD or anything more liberal it's fine. If it was GPL it
would be legally fine but it's against our policy because we want to
keep the whole package covered by BSD restrictions at most.

--
greg
http://mit.edu/~gsstark/resume.pdf

Greg Stark <gsstark(at)mit(dot)edu> wrote:
> Kevin Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
>> # All rights reserved.
>>
>> and that I would be violating that copyright by copying it to
>> PostgreSQL. Am I wrong?
>
> The above is just a statement of fact. It doesn't change the legal
> status (well not much). What you need to know is what license SUSE
> has granted. I would expect it to be either GPL or BSD but I don't
> really know SUSE.
>
> If it's BSD or anything more liberal it's fine. If it was GPL it
> would be legally fine but it's against our policy because we want to
> keep the whole package covered by BSD restrictions at most.

I tracked down the license text. It includes these sections, which
leave me disinclined to copy the init script to the PostgreSQL contrib
directory:

The Software is a collective work of Novell.
You must acquire a license for each
installation of the Software and for each
additional copy (or partial copy) of the
Software stored or loaded in memory or virtual
memory beyond the initial copy necessary for
execution of the Software installed on the
hardware.

. . .

The Software is protected by the copyright laws and treaties of the
United States ("U.S.") and other countries and is subject to the terms
of this Agreement. The Software is licensed to You, not sold.

. . .

Novell reserves all rights not expressly granted to You. You may not:
(1) reverse engineer, decompile, or disassemble the Software except
and only to the extent it is expressly permitted by applicable law or
the license terms accompanying a component of the Software; or
(2) transfer the Software or Your license rights under this Agreement,
in whole or in part.

-Kevin

Kevin Grittner wrote:
>
> I tracked down the license text. It includes these sections, which
> leave me disinclined to copy the init script to the PostgreSQL contrib
> directory:
>
> The Software is a collective work of Novell.
> You must acquire a license for each
> installation of the Software and for each
> additional copy (or partial copy) of the
> Software stored or loaded in memory or virtual
> memory beyond the initial copy necessary for
> execution of the Software installed on the
> hardware.
>
> . . .
>
> The Software is protected by the copyright laws and treaties of the
> United States ("U.S.") and other countries and is subject to the terms
> of this Agreement. The Software is licensed to You, not sold.
>
> . . .
>
> Novell reserves all rights not expressly granted to You. You may not:
> (1) reverse engineer, decompile, or disassemble the Software except
> and only to the extent it is expressly permitted by applicable law or
> the license terms accompanying a component of the Software; or
> (2) transfer the Software or Your license rights under this Agreement,
> in whole or in part.
>

here is what's in what I got from OpenSuse:

# Copyright (c) 1995-2004 SUSE Linux AG, Nuernberg, Germany.
# All rights reserved.
#
# Author: Kurt Garloff
# Please send feedback to http://www.suse.de/feedback/
#
# /etc/init.d/postgresql
# and its symbolic link
# /(usr/)sbin/rcpostgresql
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
# System startup script for PostgreSQL
#
# LSB compatible service control script; see http://www.linuxbase.org/spec/
#

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Kevin Grittner wrote:

>> [SuSE Linux Enterprise Server license]
>> Novell reserves all rights not expressly granted to You. You may
>> not:

>> (2) transfer the Software or Your license rights under this
>> Agreement, in whole or in part.

> here is what's in what I got from OpenSuse:

> GNU General Public License

So while OpenSuse seems a little less restrictive, it's still not
something we can copy into the PostgreSQL distribution, right?

-Kevin

Kevin Grittner wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> Kevin Grittner wrote:
>>
>
>
>>> [SuSE Linux Enterprise Server license]
>>> Novell reserves all rights not expressly granted to You. You may
>>> not:
>>>
>
>
>>> (2) transfer the Software or Your license rights under this
>>> Agreement, in whole or in part.
>>>
>
>
>> here is what's in what I got from OpenSuse:
>>
>
>
>> GNU General Public License
>>
>
> So while OpenSuse seems a little less restrictive, it's still not
> something we can copy into the PostgreSQL distribution, right?
>
>
>

right.

cheers

andrew

On Wed, 2009-09-02 at 10:21 -0400, Andrew Dunstan wrote:
>
> Umm, no, you could either install the SRPM in a build directory, and
> look there, or extract the script from the built RPM using rpm2cpio.

... actually I am maintaining SuSE spec and patches unofficially in RPM
repository:

https://projects.commandprompt.com/public/pgcore/browser/rpm/suse/8.3/postgresql/OS-11.1/

I'm open to contributions.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Kevin Grittner wrote:
>> So while OpenSuse seems a little less restrictive, it's still not
>> something we can copy into the PostgreSQL distribution, right?

> right.

Right. Your clean-room approach seems to have been the right thing.

regards, tom lane

On ons, 2009-09-02 at 09:13 -0500, Kevin Grittner wrote:
> We don't have the distribution's PostgreSQL package installed on
> any of our machines, so I'd have to install it and risk breaking
> something to even have a look at it.

Using Midnight Commander is the canonical way to peek inside uninstalled
RPM packages. :)

Hello Kevin,

a technical comment about line 71 and following of your shell script:

# Check that we have one parameter: action
if [ $# -ne 1 ] ; then
if [ $# -lt 1 -o "$1" = "" ] ] ; then
log_failure_msg "$0: action not specified"
else
log_failure_msg "$0: too many parameters"
fi
log_warning_msg "$usage"
exit 2
fi
action="$1"

I think in the second "if" there's a closing square bracket too much.

Wolfgang

________________________________
Von: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
An: Andrew Dunstan <andrew(at)dunslane(dot)net>
CC: David Fetter <david(at)fetter(dot)org>; Greg Stark <gsstark(at)mit(dot)edu>; pgsql-hackers(at)postgresql(dot)org
Gesendet: Montag, den 31. August 2009, 21:06:22 Uhr
Betreff: Re: [HACKERS] Linux LSB init script

Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> cvsutils

That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a couple minor fixes to what I posted in "new
file" form. I was holding off on the CommitFest entry until I sorted
out the format; I'll link here as version 1 of the patch.

-Kevin

Wolfgang Wilhelm <wolfgang20121964(at)yahoo(dot)de> wrote:

> if [ $# -lt 1 -o "$1" = "" ] ] ; then

Oops. Fixed patch attached. Thanks!

-Kevin

On Wed, 2009-09-02 at 15:06 -0500, Kevin Grittner wrote:
> Wolfgang Wilhelm <wolfgang20121964(at)yahoo(dot)de> wrote:
>
> > if [ $# -lt 1 -o "$1" = "" ] ] ; then
>
> Oops. Fixed patch attached. Thanks!

The commitfest lists this as the last patch, but there was some
discussion after this. Could you/we clarify what is actually proposed
for inclusion now? I have seen proposals for:

- Linux LSB init script
- Linux non-LSB init script
- SUSE specific init script

I can see all of these as being useful, but the question might be what
we want to commit to maintaining.

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> The commitfest lists this as the last patch, but there was some
> discussion after this. Could you/we clarify what is actually
> proposed for inclusion now? I have seen proposals for:
>
> - Linux LSB init script
> - Linux non-LSB init script
> - SUSE specific init script
>
> I can see all of these as being useful, but the question might be
> what we want to commit to maintaining.

The patch is for Linux LSB init script.

I withdrew an earlier suggested patch for the "generic" Linux init
script, since what's already there seems to be pretty good, even if
it hasn't been modified in years. The only change I had suggested
was to add an LSB block, which I later decided was better addressed
by a separate script. A few people have commented that the non-LSB
script could use some improvements, but I don't recall any specific
suggestions; and I couldn't see any obvious ones.

SuSE supplies a script with its distribution of PostgreSQL. The
SuSE licenses prelude incorporating it or any derivative work in the
PostgreSQL product. The LSB init script should also work for SuSE;
I see no point in trying to produce some other SuSE-specific script.

-Kevin

OK, I have a number of comments on this proposal.

What does it buy us, in general, and compared to the existing (non-LSB)
script?

This becomes clearer when you consider what LSB actually entails, which
is:

- INFO header
- standardized exit codes
- functions from /lib/lsb/init-functions

My argument is that it might be better to just merge the INFO header and
the exit codes into the existing script and forget about using the
functions.

The old script already has a chkconfig header, which was the moral
predecessor to the LSB INFO section. So someone evidently thought this
sort of thing was useful, and so we might as well update it.

Differentiating the exit codes is the bulk of your code, but what about
merging this part into pg_ctl itself?

The init-functions then don't really buy you anything, except that you
replace pg_ctl with start_daemon and killproc, and good old echo with
log_failure_msg. And then you proceed in pg_initd_stop to basically
reimplement half of the pg_ctl logic in shell code.

And using the init-functions is the only thing here that is not backward
compatible, so removing it would address the concern about support
pre/non-LSB distributions.

On the code itself, I think you might have gone a bit overboard with
commenting and error checking.

First, the is, in my mind, no need to repeat half of the LSB spec in the
comments.

Second, there is no need to check for the existence of every script,
program, file, and command line argument separately. The existing
script actually does that well enough. If something is missing, the
shell itself will complain soon enough.

Quite aside from anything else, I'm fairly sure a bloated script like
that will scare users away when they given the alternative choice of
using the small and easy-to-navigate old script in the same directory.

So in summary my proposal would be to take the existing linux script,
add the INFO header, and try to put all the other functionality that is
missing into pg_ctl, making the init script a small wrapper around it.
That would actually benefit the mainstream init scripts as well.

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> OK, I have a number of comments on this proposal.

Thanks for looking at it.

> What does it buy us, in general, and compared to the existing
> (non-LSB) script?

A conforming script for use in LSB conforming implementations.

> what LSB actually entails, which is:
>
> - INFO header
> - standardized exit codes
> - functions from /lib/lsb/init-functions

As well as a standardized set of actions and standard semantics for
them, if we're only talking about the init script parts.

> My argument is that it might be better to just merge the INFO header
> and the exit codes into the existing script and forget about using
> the functions.

That's where I started, but felt that it was of no benefit unless the
OS used them, in which case I thought conforming behavior would be
wanted.

> The old script already has a chkconfig header, which was the moral
> predecessor to the LSB INFO section. So someone evidently thought
> this sort of thing was useful, and so we might as well update it.

I'm not following what you say here. Is there something wrong with
the current chkconfig header in the non-LSB script?

> Differentiating the exit codes is the bulk of your code, but what
> about merging this part into pg_ctl itself?

That would result in different exit codes for a lot of circumstances.
I'm OK with that, if everyone agrees that we want, for example an exit
code of 0 for an attempt to start a server which is already running
or an attempt to stop a server which isn't running. (These are only
two examples of differences between what is required of an LSB
conforming init script and what pg_ctl does. Are we all in universal
agreement to make such a change to pg_ctl?

> The init-functions then don't really buy you anything, except that
> you replace pg_ctl with start_daemon and killproc, and good old echo
> with log_failure_msg. And then you proceed in pg_initd_stop to
> basically reimplement half of the pg_ctl logic in shell code.

Well, with differences in behavior, of course, like attempting a fast
shutdown, and escalating to an immediate shutdown if that doesn't
succeed in the allowed time.

> And using the init-functions is the only thing here that is not
> backward compatible, so removing it would address the concern about
> support pre/non-LSB distributions.

Use of these functions is a requirement for LSB conforming scripts.
If you don't use them, particularly for success and failure messages,
you're not conforming. For one thing, using these functions causes
the success and failure messages to be formatted like those for other
services on the machine, and the format varies a lot between
distributions. Also, consider this statement in the spec:

| Error and status messages should be printed with the logging
| functions (see Init Script Functions) log_success_msg(),
| log_failure_msg() and log_warning_msg(). Scripts may write to
| standard error or standard output, but implementations need not
| present text written to standard error/output to the user or do
| anything else with it.

Not using the functions would cause the script to only work for some
undefined subset of conforming implementations.

> First, the is, in my mind, no need to repeat half of the LSB spec in
> the comments.

Well, that's a bit of hyperbole -- I did the math and it's less than
10% of what I consider to be the part of the spec fairly directly
related to init scripts.

Which parts of these comments do you feel should be omitted?:

# Actions other than status may use these return codes:
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (for example, "reload")
# 4 - user had insufficient privilege
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running

# Start the service.
# If already running, return success without start attempt.

# Stop the service.
# If not running, return success without stop attempt.

# Stop and restart the service if the service is already running,
# otherwise start the service.

# Restart the service if the service is already running.
# If stopped, return success without stop attempt.

# Cause the configuration of the service to be reloaded
# without actually stopping and restarting the service.
# (Since PostgreSQL supports reload, force-reload should use
that.)

# Print the current status of the service.
# Return codes differ from other actions:
# 0 - program is running or service is OK
# 1 - program is dead and /var/run pid file exists
# 2 - program is dead and /var/lock lock file exists
# 3 - program is not running
# 4 - program or service status is unknown

# If we don't recognize action, consider it an invalid argument.
# If the standard adds actions we don't support, exit should be 3
for those.

I put in as much as I found useful to myself while working on the
script. I left it in on the assumption that it might also help
someone reading it.

> Second, there is no need to check for the existence of every script,
> program, file, and command line argument separately. The existing
> script actually does that well enough. If something is missing, the
> shell itself will complain soon enough.

But not with the exit code which LSB requires. I don't think the
script complies with the spec as well if you rip out the checks. You
could also get weird behavior, like a success code and nothing done
when things actually fail. (I believe you have now identified a
place where the non-LSB script could use improvement.)

> Quite aside from anything else, I'm fairly sure a bloated script
> like that will scare users away when they given the alternative
> choice of using the small and easy-to-navigate old script in the
> same directory.

If you search the web for LSB conforming scripts, you'll find this is
one of the shorter ones. I was intending to leave the old script
there, to satisfy those who want a short, simple script without LSB
compliance.

> So in summary my proposal would be to take the existing linux
> script, add the INFO header, and try to put all the other
> functionality that is missing into pg_ctl, making the init script a
> small wrapper around it. That would actually benefit the mainstream
> init scripts as well.

I wouldn't object to adding the LSB comment header into the other
script, but it seems kinda pointless. If you want that, I'd expect
you'd want compliant behavior, so that the OS can do the right thing
during startup and shutdown. If we have consensus on making pg_ctl
behave very differently than it does now, to comply with the LSB
standard, we could have a much shorter script, for sure. I didn't
expect we would get there, for backward compatibility reasons, if
nothing else. I suppose I should have asked first. So, who would
prefer that and who wouldn't? If we do this, should it be based on
some switch, so that the old behavior is preserved unless
LSB-conformance is requested?

-Kevin

On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
> > what LSB actually entails, which is:
> >
> > - INFO header
> > - standardized exit codes
> > - functions from /lib/lsb/init-functions
>
> As well as a standardized set of actions and standard semantics for
> them, if we're only talking about the init script parts.

Yes, I didn't fully realize that the existing script didn't implement
all possible actions. But that can obviously be "backported" as well.

> > My argument is that it might be better to just merge the INFO header
> > and the exit codes into the existing script and forget about using
> > the functions.
>
> That's where I started, but felt that it was of no benefit unless the
> OS used them, in which case I thought conforming behavior would be
> wanted.

I think it's important to consider what the "conforming behavior" really
achieves in practice. The INFO section is essential nowadays for
correct functioning on a large portion of distributions. The exit codes
are relatively uninteresting but occasionally useful. The
init-functions don't make a difference at all, as far as I'm aware.

> > The old script already has a chkconfig header, which was the moral
> > predecessor to the LSB INFO section. So someone evidently thought
> > this sort of thing was useful, and so we might as well update it.
>
> I'm not following what you say here. Is there something wrong with
> the current chkconfig header in the non-LSB script?

Well, you mentioned earlier that you were hesitant about backporting the
INFO header without adding all the other "conforming" stuff. From a
practical point of view, I think an INFO header is nowadays essential
independent of what the rest of the script does.

> > Differentiating the exit codes is the bulk of your code, but what
> > about merging this part into pg_ctl itself?
>
> That would result in different exit codes for a lot of circumstances.
> I'm OK with that, if everyone agrees that we want, for example an exit
> code of 0 for an attempt to start a server which is already running
> or an attempt to stop a server which isn't running. (These are only
> two examples of differences between what is required of an LSB
> conforming init script and what pg_ctl does. Are we all in universal
> agreement to make such a change to pg_ctl?

Well, in such cases it may be useful to add an option such as --oknodo
to select the idempotent behavior.

> > The init-functions then don't really buy you anything, except that
> > you replace pg_ctl with start_daemon and killproc, and good old echo
> > with log_failure_msg. And then you proceed in pg_initd_stop to
> > basically reimplement half of the pg_ctl logic in shell code.
>
> Well, with differences in behavior, of course, like attempting a fast
> shutdown, and escalating to an immediate shutdown if that doesn't
> succeed in the allowed time.

Right, but if you think that this behavior the right/better one (which
it arguably isn't), why shouldn't it be available from the mainline
tools? Obviously, most people have felt for the last N years that
pg_ctl provides adequate shutdown options. If not, then let's look
there. We shouldn't hardcode an alternative policy into a marginal init
script, which it will receive little testing and scrutiny.

> > And using the init-functions is the only thing here that is not
> > backward compatible, so removing it would address the concern about
> > support pre/non-LSB distributions.
>
> Use of these functions is a requirement for LSB conforming scripts.
> If you don't use them, particularly for success and failure messages,
> you're not conforming. For one thing, using these functions causes
> the success and failure messages to be formatted like those for other
> services on the machine, and the format varies a lot between
> distributions. Also, consider this statement in the spec:
>
> | Error and status messages should be printed with the logging
> | functions (see Init Script Functions) log_success_msg(),
> | log_failure_msg() and log_warning_msg(). Scripts may write to
> | standard error or standard output, but implementations need not
> | present text written to standard error/output to the user or do
> | anything else with it.
>
> Not using the functions would cause the script to only work for some
> undefined subset of conforming implementations.

Yeah, except that part of the spec is hilariously unrealistic. And
there is no evidence to suggest that use of these functions will cause
messages to be formatted like other services on the machine.
Debian/Ubuntu for example have given up on those functions because they
don't anything useful and provide their own set of functions that you
ought to use to format messages like on those systems.

> > First, the is, in my mind, no need to repeat half of the LSB spec in
> > the comments.
>
> Well, that's a bit of hyperbole -- I did the math and it's less than
> 10% of what I consider to be the part of the spec fairly directly
> related to init scripts.
>
> Which parts of these comments do you feel should be omitted?:
>
> # Actions other than status may use these return codes:
> # 1 - generic or unspecified error
> # 2 - invalid or excess argument(s)
> # 3 - unimplemented feature (for example, "reload")
> # 4 - user had insufficient privilege
> # 5 - program is not installed
> # 6 - program is not configured
> # 7 - program is not running
>
> # Start the service.
> # If already running, return success without start attempt.
>
> # Stop the service.
> # If not running, return success without stop attempt.
>
> # Stop and restart the service if the service is already running,
> # otherwise start the service.
>
> # Restart the service if the service is already running.
> # If stopped, return success without stop attempt.
>
> # Cause the configuration of the service to be reloaded
> # without actually stopping and restarting the service.
> # (Since PostgreSQL supports reload, force-reload should use
> that.)
>
> # Print the current status of the service.
> # Return codes differ from other actions:
> # 0 - program is running or service is OK
> # 1 - program is dead and /var/run pid file exists
> # 2 - program is dead and /var/lock lock file exists
> # 3 - program is not running
> # 4 - program or service status is unknown
>
> # If we don't recognize action, consider it an invalid argument.
> # If the standard adds actions we don't support, exit should be 3
> for those.

I would pretty much remove all of that completely and replace it with a
link to the spec.

> I wouldn't object to adding the LSB comment header into the other
> script, but it seems kinda pointless. If you want that, I'd expect
> you'd want compliant behavior, so that the OS can do the right thing
> during startup and shutdown. If we have consensus on making pg_ctl
> behave very differently than it does now, to comply with the LSB
> standard, we could have a much shorter script, for sure. I didn't
> expect we would get there, for backward compatibility reasons, if
> nothing else. I suppose I should have asked first. So, who would
> prefer that and who wouldn't? If we do this, should it be based on
> some switch, so that the old behavior is preserved unless
> LSB-conformance is requested?

How about making a list of current behavior of pg_ctl vs. required
behavior under LSB, and then we can judge how much of that could become
a standard behavior and how much would have to be hidden behind an
option.

I think figuring this out could be a key improvement; all the stuff
above is just cosmetic after all.

On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Well, in such cases it may be useful to add an option such as --oknodo
> to select the idempotent behavior.

It took me about 60 seconds to figure out what I thought you were
going for there, so I submit that's not a good choice of option name.

> Yeah, except that part of the spec is hilariously unrealistic.  And

But since when do we worry about such things? :-)

> I would pretty much remove all of that completely and replace it with a
> link to the spec.

FWIW, the comments Kevin quoted seem reasonable to me.

...Robert

Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> I think it's important to consider what the "conforming behavior"
> really achieves in practice. The INFO section is essential nowadays
> for correct functioning on a large portion of distributions. The
> exit codes are relatively uninteresting but occasionally useful.
> The init-functions don't make a difference at all, as far as I'm
> aware.

I don't claim to be aware of how heavily current and planned
conforming implementations make use of which features; which is why I
felt it best to conform as fully as possible. As far as I can tell,
full conformance in the script only has the down side of bloating it
to 300 lines, including current comments; it would be much shorter if
we modified pg_ctl as you propose. I'm not clear on any other
benefits of pseudo-conformance.

> Well, you mentioned earlier that you were hesitant about backporting
> the INFO header without adding all the other "conforming" stuff.
> From a practical point of view, I think an INFO header is nowadays
> essential independent of what the rest of the script does.

The only down side to including it in a script which doesn't behave in
an LSB conforming manner is that it could convince a conforming
environment that it is a conforming script. Lying about that might be
worse than remaining silent on the matter.

> Well, in such cases it may be useful to add an option such as
> --oknodo to select the idempotent behavior.

I found that confusing (as did Robert); how about --lsm-conforming?

>> > And then you proceed in pg_initd_stop to basically reimplement
>> > half of the pg_ctl logic in shell code.
>>
>> Well, with differences in behavior, of course, like attempting a
>> fast shutdown, and escalating to an immediate shutdown if that
>> doesn't succeed in the allowed time.
>
> Right, but if you think that this behavior the right/better one
> (which it arguably isn't), why shouldn't it be available from the
> mainline tools?

Well, it's certainly the best behavior for my shop, because the stop
command is used by the OS shutdown. If the command never returns, the
shutdown hangs indefinitely, which can be very bad in our environment.
If the shutdown returns without actually stopping PostgreSQL, the
system will kill -9 it as a last resort before power-off or reboot.
I like my heuristic better than either of those.

> Obviously, most people have felt for the last N years that
> pg_ctl provides adequate shutdown options.

Which is why I didn't suggest changing pg_ctl; but perhaps that was
overly timid.

>> Not using the functions would cause the script to only work for
>> some undefined subset of conforming implementations.
>
> Yeah, except that part of the spec is hilariously unrealistic. And
> there is no evidence to suggest that use of these functions will
> cause messages to be formatted like other services on the machine.
> Debian/Ubuntu for example have given up on those functions because
> they don't anything useful and provide their own set of functions
> that you ought to use to format messages like on those systems.

SuSE also wraps these with their own functions, but I really don't
want to try to learn the implementation details of every distribution
when there is a supported standard. I think you're wrong about
current support.

On my kubuntu system:

root(at)kgrittn-desktop:~# . /lib/lsb/init-functions
root(at)kgrittn-desktop:~# log_success_msg "test: started"
* test: started
root(at)kgrittn-desktop:~# log_warning_msg "test: unexpected state"
* test: unexpected state
root(at)kgrittn-desktop:~# log_failure_msg "test: insufficient
priviledges"
* test: insufficient priviledges

The star is black, yellow, or red, depending on the function used.
This matches the behavior of init scripts which come with the OS.

On my SLES10 systems:

CIRDEV:~ # . /lib/lsb/init-functions
CIRDEV:~ # log_success_msg "test: started"
test: started done
CIRDEV:~ # log_warning_msg "test: unexpected state"
test: unexpected state warning
CIRDEV:~ # log_failure_msg "test: insufficient priviledges"
test: insufficient priviledges failed

Where the word off to the right lines up near the right edge of
whatever the line width is, and the colors of those words is green,
yellow, or red based on the function used. This matches the
behavior of init scripts which come with the OS.

> I would pretty much remove all of that completely and replace it
> with a link to the spec.

I'm skeptical. Robert didn't think those were over the top. I would
like to hear what others think, but I, personally, appreciate such
comments when I'm reading code. (Even my own, if it's been a few
months.)

> How about making a list of current behavior of pg_ctl vs. required
> behavior under LSB, and then we can judge how much of that could
> become a standard behavior and how much would have to be hidden
> behind an option.
>
> I think figuring this out could be a key improvement; all the stuff
> above is just cosmetic after all.

Fair enough. I'll work on that.

Anything beyond this email may have to wait a week or so, though. I
have to deal with a family medical issue this afternoon, and after
that I'm going to be on vacation with limited Internet access.
Hopefully this can be picked up after my vacation; otherwise, there's
always the next CF....

Thanks again for the review.

-Kevin

On Thu, 17 Sep 2009, Peter Eisentraut wrote:

> On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote:
>> Well, with differences in behavior, of course, like attempting a fast
>> shutdown, and escalating to an immediate shutdown if that doesn't
>> succeed in the allowed time.
>
> Right, but if you think that this behavior the right/better one (which
> it arguably isn't), why shouldn't it be available from the mainline
> tools? Obviously, most people have felt for the last N years that
> pg_ctl provides adequate shutdown options.

I've implemented exactly the same logic Kevin describes for a past
consulting customer and for multiple forms of shutdown scripts at Truviso.
I would suggest the situation here is that it's so easy to script a custom
solution that the other people who have done the same don't have any
motivation to get that fixed upstream, which would take a bunch of arguing
on this list to accomplish. Easier to just work around it and move on.

You're correct that pg_ctl provides "adequate" options here in the respect
that it's possible to build the behavior many people want from the
primitives available. I'm with Kevin that what many people would like to
see in a system shutdown script is not possible using pg_ctl alone. Fast
shutdown, timeout, then immediate shutdown is absolutely the best default
behavior if the server must go down, but you can afford to wait a bit to
try and do that more cleanly than going straight to immediate.

To answer the next question, "why doesn't fast shutdown work for you?",
see http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php

If that were fixed maybe fast shutdown would be more useful, as it is I
have to assume it will fail because open COPYs are pretty common for our
apps. But I don't want to go straight to immediate for the sake of other
programs that can shut themselves down more cleanly if the server goes
through the fast shutdown stage first.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On tor, 2009-09-17 at 09:26 -0400, Robert Haas wrote:
> On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > Well, in such cases it may be useful to add an option such as --oknodo
> > to select the idempotent behavior.
>
> It took me about 60 seconds to figure out what I thought you were
> going for there, so I submit that's not a good choice of option name.

This is the name that the start-stop-daemon program in Debian uses, but
I can see how it can be puzzling. We don't have to use this exact
spelling.

> > Yeah, except that part of the spec is hilariously unrealistic. And
>
> But since when do we worry about such things? :-)

I submit to this quip, but note that there is a difference between an
implementation of a standard and an application using that standard. I
have done a fair amount of work on the LSB init script support in Debian
over the years, and yes, there I favor going with the standard behavior
if at all possible. But when it comes to writing an application that is
supposed to work with an LSB or SQL platform, you have to take a more
pragmatic approach. At least that is my approach.

On tor, 2009-09-17 at 14:21 -0400, Greg Smith wrote:
> I've implemented exactly the same logic Kevin describes for a past
> consulting customer and for multiple forms of shutdown scripts at
> Truviso.
> I would suggest the situation here is that it's so easy to script a
> custom
> solution that the other people who have done the same don't have any
> motivation to get that fixed upstream, which would take a bunch of
> arguing
> on this list to accomplish. Easier to just work around it and move
> on.

I grant you all that, but this sort of thing is best not slipped in via
a patch tagged LSB init script. If there is a problem to be fixed,
let's discuss it. If it can't be fixed, let's at least document it. Or
if you don't have the motivation, there are other places to host "custom
solutions".

On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
> > Well, in such cases it may be useful to add an option such as
> > --oknodo to select the idempotent behavior.
>
> I found that confusing (as did Robert); how about --lsm-conforming?

s/lsm/lsb/

I'm not so sure that I would label it as LSB, because that is too broad,
and not very descriptive.

I think this option should only control whether start and stop are
idempotent. Other LSB issues such as exit codes ought to become the
default, or possibly a different option if necessary.

On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
>> > Well, in such cases it may be useful to add an option such as
>> > --oknodo to select the idempotent behavior.
>>
>> I found that confusing (as did Robert); how about --lsm-conforming?
>
> s/lsm/lsb/
>
> I'm not so sure that I would label it as LSB, because that is too broad,
> and not very descriptive.
>
> I think this option should only control whether start and stop are
> idempotent.  Other LSB issues such as exit codes ought to become the
> default, or possibly a different option if necessary.

Maybe we should just call it --idempotent.

Or, they could be additional actions, like ensure-start/ensure-stop.

...Robert

On Thu, Sep 17, 2009 at 4:52 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
>>> > Well, in such cases it may be useful to add an option such as
>>> > --oknodo to select the idempotent behavior.
>>>
>>> I found that confusing (as did Robert); how about --lsm-conforming?
>>
>> s/lsm/lsb/
>>
>> I'm not so sure that I would label it as LSB, because that is too broad,
>> and not very descriptive.
>>
>> I think this option should only control whether start and stop are
>> idempotent.  Other LSB issues such as exit codes ought to become the
>> default, or possibly a different option if necessary.
>
> Maybe we should just call it --idempotent.
>
> Or, they could be additional actions, like ensure-start/ensure-stop.

It seems like there is some support for what this patch is trying to
do, but much disagreement about the details of how to get there.
Where do we go from here?

...Robert

On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
> It seems like there is some support for what this patch is trying to
> do, but much disagreement about the details of how to get there.
> Where do we go from here?

I think the next step would be to outline what changes would be
necessary in pg_ctl to implement LSB behavior. And then decide case by
case whether it should become the default, an option, or is not
appropriate for pg_ctl.

Kevin apparently sort of agreed to do that when he came back.

On Mon, Sep 21, 2009 at 3:20 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
>> It seems like there is some support for what this patch is trying to
>> do, but much disagreement about the details of how to get there.
>> Where do we go from here?
>
> I think the next step would be to outline what changes would be
> necessary in pg_ctl to implement LSB behavior.  And then decide case by
> case whether it should become the default, an option, or is not
> appropriate for pg_ctl.
>
> Kevin apparently sort of agreed to do that when he came back.

Given the lack of progress here, I'm going to move this one to
"Returned with Feedback" for now. I think Kevin is busy with his
non-PostgreSQL life, and there's always next CommitFest.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
>>> It seems like there is some support for what this patch is trying
>>> to do, but much disagreement about the details of how to get
>>> there. Where do we go from here?
>>
>> I think the next step would be to outline what changes would be
>> necessary in pg_ctl to implement LSB behavior. And then decide
>> case by case whether it should become the default, an option, or is
>> not appropriate for pg_ctl.
>>
>> Kevin apparently sort of agreed to do that when he came back.

Right. It seems that, in addition to the above, there also remains
some disagreement about:

(1) how much checking the script should do to provide error messages
and exit codes which target the specific problems versus generic "I'm
broken" messages for problems which prevent it from getting to the
point of being able to run pg_ctl,

(2) whether the log functions required by the standard should be
used, or whether we should assume that output to stdout and/or stderr
(which the standard says may be silently discarded without showing
anywhere) should be used instead,

(3) whether we should provide comments of the general intent of
sections of code when the implementing code is providing functionality
required by the standard, versus assuming that the reader can match
the code portions to the relevant sections of the standard without
supporting comments.

In general, I think most of the disputed points revolve around
balancing strict compliance against keeping the script short. (The
existing Linux script is about 100 lines of shell script; the LSB
conforming proposal, without any pg_ctl changes which might make it
shorter, is about 300 lines.)

There's also disagreement about whether we should source
/lib/lsb/init-functions -- which is required by the LSB standard, and
provides the logging functions which the standard requires scripts to
use.

> Given the lack of progress here, I'm going to move this one to
> "Returned with Feedback" for now. I think Kevin is busy with his
> non-PostgreSQL life, and there's always next CommitFest.

Yeah, I'm back now, but given the research needed and the level of
disagreement, completion in the CF seems unlikely. If all the stars
align correctly and this gets completed in the next two weeks, we can
always resurrect it.

-Kevin

On Wed, 2009-09-30 at 11:58 -0500, Kevin Grittner wrote:
> Right. It seems that, in addition to the above, there also remains
> some disagreement about:
>
> (1) how much checking the script should do to provide error messages
> and exit codes which target the specific problems versus generic "I'm
> broken" messages for problems which prevent it from getting to the
> point of being able to run pg_ctl,
>
> (2) whether the log functions required by the standard should be
> used, or whether we should assume that output to stdout and/or stderr
> (which the standard says may be silently discarded without showing
> anywhere) should be used instead,
>
> (3) whether we should provide comments of the general intent of
> sections of code when the implementing code is providing functionality
> required by the standard, versus assuming that the reader can match
> the code portions to the relevant sections of the standard without
> supporting comments.

I'm not so worried about these points. They can always be adjusted
later. The point about how to involve pg_ctl is more critical.