Linux LSB init script

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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

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

David Fetter <david@fetter.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@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@fetter.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@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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.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.Grittner@wicourts.gov> wrote:

David Fetter <david@fetter.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.Grittner@wicourts.gov> wrote:

David Fetter <david@fetter.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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.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@fetter.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@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@fetter.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.Grittner@wicourts.gov> wrote:

David Fetter <david@fetter.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/&gt;

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

cheers

andrew

Peter Eisentraut <peter_e@gmx.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@dunslane.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@gregsmith.com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith@gregsmith.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@gmx.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@gregsmith.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@gmx.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