Skip site navigation (1) Skip section navigation (2)

Re: Linux LSB init script

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "David Fetter" <david(at)fetter(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Linux LSB init script
Date: 2009-08-31 19:56:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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...
> 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:
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:
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:
Let me know if you have any concerns I didn't address.

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-08-31 19:59:40
Subject: Re: set_client_encoding is broken
Previous:From: Tom LaneDate: 2009-08-31 19:49:02
Subject: Re: autovacuum launcher using InitPostgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group