Thread: 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
Attachment
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
Attachment
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/> 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
Attachment
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
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@gmx.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@gmx.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.Grittner@wicourts.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@mit.edu> wrote:
> Kevin Grittner<Kevin.Grittner@wicourts.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@dunslane.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@dunslane.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@dunslane.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"
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.Grittner@wicourts.gov>
An: Andrew Dunstan <andrew@dunslane.net>
CC: David Fetter <david@fetter.org>; Greg Stark <gsstark@mit.edu>; pgsql-hackers@postgresql.org
Gesendet: Montag, den 31. August 2009, 21:06:22 Uhr
Betreff: Re: [HACKERS] Linux LSB init script
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
Wolfgang
Von: Kevin Grittner <Kevin.Grittner@wicourts.gov>
An: Andrew Dunstan <andrew@dunslane.net>
CC: David Fetter <david@fetter.org>; Greg Stark <gsstark@mit.edu>; pgsql-hackers@postgresql.org
Gesendet: Montag, den 31. August 2009, 21:06:22 Uhr
Betreff: Re: [HACKERS] Linux LSB init script
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
Attachment
Wolfgang Wilhelm <wolfgang20121964@yahoo.de> wrote: > if [ $# -lt 1 -o "$1" = "" ] ] ; then Oops. Fixed patch attached. Thanks! -Kevin
Attachment
On Wed, 2009-09-02 at 15:06 -0500, Kevin Grittner wrote: > Wolfgang Wilhelm <wolfgang20121964@yahoo.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@gmx.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@gmx.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 orservice 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, exitshould 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@gmx.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@gmx.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@kgrittn-desktop:~# . /lib/lsb/init-functions root@kgrittn-desktop:~# log_success_msg "test: started"* test: started root@kgrittn-desktop:~# log_warning_msg "test: unexpected state"* test: unexpected state root@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@gregsmith.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@gmx.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@gmx.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@gmail.com> wrote: > On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut <peter_e@gmx.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@gmx.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@gmail.com> wrote: > Peter Eisentraut <peter_e@gmx.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.