Re: Linux LSB init script - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Linux LSB init script
Date
Msg-id 4A9BE4A3020000250002A666@gw.wicourts.gov
Whole thread Raw
In response to Re: Linux LSB init script  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: autovacuum launcher using InitPostgres
Next
From: Tom Lane
Date:
Subject: Re: set_client_encoding is broken