Re: Linux LSB init script

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.