Re: Linux LSB init script - Mailing list pgsql-hackers
From | Kevin Grittner |
---|---|
Subject | Re: Linux LSB init script |
Date | |
Msg-id | 4AB2248A020000250002B2D0@gw.wicourts.gov Whole thread Raw |
In response to | Re: Linux LSB init script (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: Linux LSB init script
|
List | pgsql-hackers |
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
pgsql-hackers by date: