Re: Linux LSB init script

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Wolfgang Wilhelm" <wolfgang20121964(at)yahoo(dot)de>
Subject: Re: Linux LSB init script
Date: 2009-09-17 16:59:06
Message-ID: 4AB2248A020000250002B2D0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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(at)kgrittn-desktop:~# . /lib/lsb/init-functions
root(at)kgrittn-desktop:~# log_success_msg "test: started"
* test: started
root(at)kgrittn-desktop:~# log_warning_msg "test: unexpected state"
* test: unexpected state
root(at)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-09-17 17:02:35 Re: Feedback on getting rid of VACUUM FULL
Previous Message Tom Lane 2009-09-17 16:36:40 Re: Feedback on getting rid of VACUUM FULL