Re: [HACKERS] Linux LSB init script
Robert Haas robertmh...@gmail.com wrote: Peter Eisentraut pete...@gmx.net wrote: On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote: It seems like there is some support for what this patch is trying to do, but much disagreement about the details of how to get there. Where do we go from here? I think the next step would be to outline what changes would be necessary in pg_ctl to implement LSB behavior. And then decide case by case whether it should become the default, an option, or is not appropriate for pg_ctl. Kevin apparently sort of agreed to do that when he came back. Right. It seems that, in addition to the above, there also remains some disagreement about: (1) how much checking the script should do to provide error messages and exit codes which target the specific problems versus generic I'm broken messages for problems which prevent it from getting to the point of being able to run pg_ctl, (2) whether the log functions required by the standard should be used, or whether we should assume that output to stdout and/or stderr (which the standard says may be silently discarded without showing anywhere) should be used instead, (3) whether we should provide comments of the general intent of sections of code when the implementing code is providing functionality required by the standard, versus assuming that the reader can match the code portions to the relevant sections of the standard without supporting comments. In general, I think most of the disputed points revolve around balancing strict compliance against keeping the script short. (The existing Linux script is about 100 lines of shell script; the LSB conforming proposal, without any pg_ctl changes which might make it shorter, is about 300 lines.) There's also disagreement about whether we should source /lib/lsb/init-functions -- which is required by the LSB standard, and provides the logging functions which the standard requires scripts to use. Given the lack of progress here, I'm going to move this one to Returned with Feedback for now. I think Kevin is busy with his non-PostgreSQL life, and there's always next CommitFest. Yeah, I'm back now, but given the research needed and the level of disagreement, completion in the CF seems unlikely. If all the stars align correctly and this gets completed in the next two weeks, we can always resurrect it. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Wed, 2009-09-30 at 11:58 -0500, Kevin Grittner wrote: Right. It seems that, in addition to the above, there also remains some disagreement about: (1) how much checking the script should do to provide error messages and exit codes which target the specific problems versus generic I'm broken messages for problems which prevent it from getting to the point of being able to run pg_ctl, (2) whether the log functions required by the standard should be used, or whether we should assume that output to stdout and/or stderr (which the standard says may be silently discarded without showing anywhere) should be used instead, (3) whether we should provide comments of the general intent of sections of code when the implementing code is providing functionality required by the standard, versus assuming that the reader can match the code portions to the relevant sections of the standard without supporting comments. I'm not so worried about these points. They can always be adjusted later. The point about how to involve pg_ctl is more critical. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Mon, Sep 21, 2009 at 3:20 AM, Peter Eisentraut pete...@gmx.net wrote: On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote: It seems like there is some support for what this patch is trying to do, but much disagreement about the details of how to get there. Where do we go from here? I think the next step would be to outline what changes would be necessary in pg_ctl to implement LSB behavior. And then decide case by case whether it should become the default, an option, or is not appropriate for pg_ctl. Kevin apparently sort of agreed to do that when he came back. Given the lack of progress here, I'm going to move this one to Returned with Feedback for now. I think Kevin is busy with his non-PostgreSQL life, and there's always next CommitFest. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote: It seems like there is some support for what this patch is trying to do, but much disagreement about the details of how to get there. Where do we go from here? I think the next step would be to outline what changes would be necessary in pg_ctl to implement LSB behavior. And then decide case by case whether it should become the default, an option, or is not appropriate for pg_ctl. Kevin apparently sort of agreed to do that when he came back. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Thu, Sep 17, 2009 at 4:52 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut pete...@gmx.net wrote: On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote: 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? s/lsm/lsb/ I'm not so sure that I would label it as LSB, because that is too broad, and not very descriptive. I think this option should only control whether start and stop are idempotent. Other LSB issues such as exit codes ought to become the default, or possibly a different option if necessary. Maybe we should just call it --idempotent. Or, they could be additional actions, like ensure-start/ensure-stop. It seems like there is some support for what this patch is trying to do, but much disagreement about the details of how to get there. Where do we go from here? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut pete...@gmx.net wrote: Well, in such cases it may be useful to add an option such as --oknodo to select the idempotent behavior. It took me about 60 seconds to figure out what I thought you were going for there, so I submit that's not a good choice of option name. Yeah, except that part of the spec is hilariously unrealistic. And But since when do we worry about such things? :-) I would pretty much remove all of that completely and replace it with a link to the spec. FWIW, the comments Kevin quoted seem reasonable to me. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@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: r...@kgrittn-desktop:~# . /lib/lsb/init-functions r...@kgrittn-desktop:~# log_success_msg test: started * test: started r...@kgrittn-desktop:~# log_warning_msg test: unexpected state * test: unexpected state r...@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
Re: [HACKERS] Linux LSB init script
On Thu, 17 Sep 2009, Peter Eisentraut wrote: On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote: 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? Obviously, most people have felt for the last N years that pg_ctl provides adequate shutdown options. I've implemented exactly the same logic Kevin describes for a past consulting customer and for multiple forms of shutdown scripts at Truviso. I would suggest the situation here is that it's so easy to script a custom solution that the other people who have done the same don't have any motivation to get that fixed upstream, which would take a bunch of arguing on this list to accomplish. Easier to just work around it and move on. You're correct that pg_ctl provides adequate options here in the respect that it's possible to build the behavior many people want from the primitives available. I'm with Kevin that what many people would like to see in a system shutdown script is not possible using pg_ctl alone. Fast shutdown, timeout, then immediate shutdown is absolutely the best default behavior if the server must go down, but you can afford to wait a bit to try and do that more cleanly than going straight to immediate. To answer the next question, why doesn't fast shutdown work for you?, see http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php If that were fixed maybe fast shutdown would be more useful, as it is I have to assume it will fail because open COPYs are pretty common for our apps. But I don't want to go straight to immediate for the sake of other programs that can shut themselves down more cleanly if the server goes through the fast shutdown stage first. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On tor, 2009-09-17 at 09:26 -0400, Robert Haas wrote: On Thu, Sep 17, 2009 at 1:30 AM, Peter Eisentraut pete...@gmx.net wrote: Well, in such cases it may be useful to add an option such as --oknodo to select the idempotent behavior. It took me about 60 seconds to figure out what I thought you were going for there, so I submit that's not a good choice of option name. This is the name that the start-stop-daemon program in Debian uses, but I can see how it can be puzzling. We don't have to use this exact spelling. Yeah, except that part of the spec is hilariously unrealistic. And But since when do we worry about such things? :-) I submit to this quip, but note that there is a difference between an implementation of a standard and an application using that standard. I have done a fair amount of work on the LSB init script support in Debian over the years, and yes, there I favor going with the standard behavior if at all possible. But when it comes to writing an application that is supposed to work with an LSB or SQL platform, you have to take a more pragmatic approach. At least that is my approach. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote: 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? s/lsm/lsb/ I'm not so sure that I would label it as LSB, because that is too broad, and not very descriptive. I think this option should only control whether start and stop are idempotent. Other LSB issues such as exit codes ought to become the default, or possibly a different option if necessary. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On tor, 2009-09-17 at 14:21 -0400, Greg Smith wrote: I've implemented exactly the same logic Kevin describes for a past consulting customer and for multiple forms of shutdown scripts at Truviso. I would suggest the situation here is that it's so easy to script a custom solution that the other people who have done the same don't have any motivation to get that fixed upstream, which would take a bunch of arguing on this list to accomplish. Easier to just work around it and move on. I grant you all that, but this sort of thing is best not slipped in via a patch tagged LSB init script. If there is a problem to be fixed, let's discuss it. If it can't be fixed, let's at least document it. Or if you don't have the motivation, there are other places to host custom solutions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut pete...@gmx.net wrote: On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote: 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? s/lsm/lsb/ I'm not so sure that I would label it as LSB, because that is too broad, and not very descriptive. I think this option should only control whether start and stop are idempotent. Other LSB issues such as exit codes ought to become the default, or possibly a different option if necessary. Maybe we should just call it --idempotent. Or, they could be additional actions, like ensure-start/ensure-stop. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: OK, I have a number of comments on this proposal. Thanks for looking at it. What does it buy us, in general, and compared to the existing (non-LSB) script? A conforming script for use in LSB conforming implementations. what LSB actually entails, which is: - INFO header - standardized exit codes - functions from /lib/lsb/init-functions As well as a standardized set of actions and standard semantics for them, if we're only talking about the init script parts. 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. That's where I started, but felt that it was of no benefit unless the OS used them, in which case I thought conforming behavior would be wanted. 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. I'm not following what you say here. Is there something wrong with the current chkconfig header in the non-LSB script? Differentiating the exit codes is the bulk of your code, but what about merging this part into pg_ctl itself? That would result in different exit codes for a lot of circumstances. I'm OK with that, if everyone agrees that we want, for example an exit code of 0 for an attempt to start a server which is already running or an attempt to stop a server which isn't running. (These are only two examples of differences between what is required of an LSB conforming init script and what pg_ctl does. Are we all in universal agreement to make such a change to pg_ctl? 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. 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. 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. Use of these functions is a requirement for LSB conforming scripts. If you don't use them, particularly for success and failure messages, you're not conforming. For one thing, using these functions causes the success and failure messages to be formatted like those for other services on the machine, and the format varies a lot between distributions. Also, consider this statement in the spec: | Error and status messages should be printed with the logging | functions (see Init Script Functions) log_success_msg(), | log_failure_msg() and log_warning_msg(). Scripts may write to | standard error or standard output, but implementations need not | present text written to standard error/output to the user or do | anything else with it. Not using the functions would cause the script to only work for some undefined subset of conforming implementations. First, the is, in my mind, no need to repeat half of the LSB spec in the comments. Well, that's a bit of hyperbole -- I did the math and it's less than 10% of what I consider to be the part of the spec fairly directly related to init scripts. Which parts of these comments do you feel should be omitted?: # Actions other than status may use these return codes: # 1 - generic or unspecified error # 2 - invalid or excess argument(s) # 3 - unimplemented feature (for example, reload) # 4 - user had insufficient privilege # 5 - program is not installed # 6 - program is not configured # 7 - program is not running # Start the service. # If already running, return success without start attempt. # Stop the service. # If not running, return success without stop attempt. # Stop and restart the service if the service is already running, # otherwise start the service. # Restart the service if the service is already running. # If stopped, return success without stop attempt. # Cause the configuration of the service to be reloaded # without actually stopping and restarting the service. # (Since PostgreSQL supports reload, force-reload should use that.) # Print the current status of the service. # Return codes differ from other actions: # 0 - program is running or service is OK # 1 - program is dead and /var/run pid file exists # 2 - program is dead and /var/lock lock file exists # 3 - program is not running # 4 - program or service status is unknown # If we don't recognize action, consider it an invalid argument. # If the standard adds actions we don't support, exit should be 3 for those. I put in as much as I found useful to myself while working on the script. I left it in on the
Re: [HACKERS] Linux LSB init script
On ons, 2009-09-16 at 12:05 -0500, Kevin Grittner wrote: what LSB actually entails, which is: - INFO header - standardized exit codes - functions from /lib/lsb/init-functions As well as a standardized set of actions and standard semantics for them, if we're only talking about the init script parts. Yes, I didn't fully realize that the existing script didn't implement all possible actions. But that can obviously be backported as well. 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. That's where I started, but felt that it was of no benefit unless the OS used them, in which case I thought conforming behavior would be wanted. 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. 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. I'm not following what you say here. Is there something wrong with the current chkconfig header in the non-LSB script? 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. Differentiating the exit codes is the bulk of your code, but what about merging this part into pg_ctl itself? That would result in different exit codes for a lot of circumstances. I'm OK with that, if everyone agrees that we want, for example an exit code of 0 for an attempt to start a server which is already running or an attempt to stop a server which isn't running. (These are only two examples of differences between what is required of an LSB conforming init script and what pg_ctl does. Are we all in universal agreement to make such a change to pg_ctl? Well, in such cases it may be useful to add an option such as --oknodo to select the idempotent behavior. 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. 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? Obviously, most people have felt for the last N years that pg_ctl provides adequate shutdown options. If not, then let's look there. We shouldn't hardcode an alternative policy into a marginal init script, which it will receive little testing and scrutiny. 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. Use of these functions is a requirement for LSB conforming scripts. If you don't use them, particularly for success and failure messages, you're not conforming. For one thing, using these functions causes the success and failure messages to be formatted like those for other services on the machine, and the format varies a lot between distributions. Also, consider this statement in the spec: | Error and status messages should be printed with the logging | functions (see Init Script Functions) log_success_msg(), | log_failure_msg() and log_warning_msg(). Scripts may write to | standard error or standard output, but implementations need not | present text written to standard error/output to the user or do | anything else with it. 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. First, the is, in my mind, no need to repeat half of the LSB spec in the comments. Well, that's a bit of hyperbole -- I did the math and it's less than 10% of what I consider to be the part of the spec fairly directly related to init scripts. Which parts of these comments do you feel should be
Re: [HACKERS] Linux LSB init script
On Wed, 2009-09-02 at 15:06 -0500, Kevin Grittner wrote: Wolfgang Wilhelm wolfgang20121...@yahoo.de wrote: if [ $# -lt 1 -o $1 = ] ] ; then Oops. Fixed patch attached. Thanks! The commitfest lists this as the last patch, but there was some discussion after this. Could you/we clarify what is actually proposed for inclusion now? I have seen proposals for: - Linux LSB init script - Linux non-LSB init script - SUSE specific init script I can see all of these as being useful, but the question might be what we want to commit to maintaining. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: The commitfest lists this as the last patch, but there was some discussion after this. Could you/we clarify what is actually proposed for inclusion now? I have seen proposals for: - Linux LSB init script - Linux non-LSB init script - SUSE specific init script I can see all of these as being useful, but the question might be what we want to commit to maintaining. The patch is for Linux LSB init script. I withdrew an earlier suggested patch for the generic Linux init script, since what's already there seems to be pretty good, even if it hasn't been modified in years. The only change I had suggested was to add an LSB block, which I later decided was better addressed by a separate script. A few people have commented that the non-LSB script could use some improvements, but I don't recall any specific suggestions; and I couldn't see any obvious ones. SuSE supplies a script with its distribution of PostgreSQL. The SuSE licenses prelude incorporating it or any derivative work in the PostgreSQL product. The LSB init script should also work for SuSE; I see no point in trying to produce some other SuSE-specific script. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote: I wouldn't expect a packaged SuSE build to cater to all of that; but it would be nice if they donated their init script to the PostgreSQL project, so that those of us who have a reason to build from source on SuSE have have a convenient starting point in the source distribution of PostgreSQL. Well, no one needs to donate anything. If you are interested in maintaining it, just take it and put it under contrib/start-scripts. Hmmm... I didn't look at the SuSE init script for PostgreSQL before writing my LSB script because (1) I was concerned that any similarities might be considered a violation of some copyright. By writing them cold I had the clean room argument -- similarities are because it's the obvious way to solve the problem; noting was copied, so there is no violation of the copyright. (2) We don't have the distribution's PostgreSQL package installed on any of our machines, so I'd have to install it and risk breaking something to even have a look at it. My assumption was that, like most of the init scripts in the SuSE distribution, it would contain this: # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany. # All rights reserved. and that I would be violating that copyright by copying it to PostgreSQL. Am I wrong? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Kevin Grittner wrote: (2) We don't have the distribution's PostgreSQL package installed on any of our machines, so I'd have to install it and risk breaking something to even have a look at it. Umm, no, you could either install the SRPM in a build directory, and look there, or extract the script from the built RPM using rpm2cpio. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Wed, Sep 2, 2009 at 3:13 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany. # All rights reserved. and that I would be violating that copyright by copying it to PostgreSQL. Am I wrong? The above is just a statement of fact. It doesn't change the legal status (well not much). What you need to know is what license SUSE has granted. I would expect it to be either GPL or BSD but I don't really know SUSE. If it's BSD or anything more liberal it's fine. If it was GPL it would be legally fine but it's against our policy because we want to keep the whole package covered by BSD restrictions at most. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Greg Stark gsst...@mit.edu wrote: Kevin Grittnerkevin.gritt...@wicourts.gov wrote: # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany. # All rights reserved. and that I would be violating that copyright by copying it to PostgreSQL. Am I wrong? The above is just a statement of fact. It doesn't change the legal status (well not much). What you need to know is what license SUSE has granted. I would expect it to be either GPL or BSD but I don't really know SUSE. If it's BSD or anything more liberal it's fine. If it was GPL it would be legally fine but it's against our policy because we want to keep the whole package covered by BSD restrictions at most. I tracked down the license text. It includes these sections, which leave me disinclined to copy the init script to the PostgreSQL contrib directory: The Software is a collective work of Novell. You must acquire a license for each installation of the Software and for each additional copy (or partial copy) of the Software stored or loaded in memory or virtual memory beyond the initial copy necessary for execution of the Software installed on the hardware. . . . The Software is protected by the copyright laws and treaties of the United States (U.S.) and other countries and is subject to the terms of this Agreement. The Software is licensed to You, not sold. . . . Novell reserves all rights not expressly granted to You. You may not: (1) reverse engineer, decompile, or disassemble the Software except and only to the extent it is expressly permitted by applicable law or the license terms accompanying a component of the Software; or (2) transfer the Software or Your license rights under this Agreement, in whole or in part. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Kevin Grittner wrote: I tracked down the license text. It includes these sections, which leave me disinclined to copy the init script to the PostgreSQL contrib directory: The Software is a collective work of Novell. You must acquire a license for each installation of the Software and for each additional copy (or partial copy) of the Software stored or loaded in memory or virtual memory beyond the initial copy necessary for execution of the Software installed on the hardware. . . . The Software is protected by the copyright laws and treaties of the United States (U.S.) and other countries and is subject to the terms of this Agreement. The Software is licensed to You, not sold. . . . Novell reserves all rights not expressly granted to You. You may not: (1) reverse engineer, decompile, or disassemble the Software except and only to the extent it is expressly permitted by applicable law or the license terms accompanying a component of the Software; or (2) transfer the Software or Your license rights under this Agreement, in whole or in part. here is what's in what I got from OpenSuse: # Copyright (c) 1995-2004 SUSE Linux AG, Nuernberg, Germany. # All rights reserved. # # Author: Kurt Garloff # Please send feedback to http://www.suse.de/feedback/ # # /etc/init.d/postgresql # and its symbolic link # /(usr/)sbin/rcpostgresql # #This program is free software; you can redistribute it and/or modify #it under the terms of the GNU General Public License as published by #the Free Software Foundation; either version 2 of the License, or #(at your option) any later version. # #This program is distributed in the hope that it will be useful, #but WITHOUT ANY WARRANTY; without even the implied warranty of #MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #GNU General Public License for more details. # #You should have received a copy of the GNU General Public License #along with this program; if not, write to the Free Software #Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # # System startup script for PostgreSQL # # LSB compatible service control script; see http://www.linuxbase.org/spec/ # cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Andrew Dunstan and...@dunslane.net wrote: Kevin Grittner wrote: [SuSE Linux Enterprise Server license] Novell reserves all rights not expressly granted to You. You may not: (2) transfer the Software or Your license rights under this Agreement, in whole or in part. here is what's in what I got from OpenSuse: GNU General Public License So while OpenSuse seems a little less restrictive, it's still not something we can copy into the PostgreSQL distribution, right? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Kevin Grittner wrote: Andrew Dunstan and...@dunslane.net wrote: Kevin Grittner wrote: [SuSE Linux Enterprise Server license] Novell reserves all rights not expressly granted to You. You may not: (2) transfer the Software or Your license rights under this Agreement, in whole or in part. here is what's in what I got from OpenSuse: GNU General Public License So while OpenSuse seems a little less restrictive, it's still not something we can copy into the PostgreSQL distribution, right? right. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Wed, 2009-09-02 at 10:21 -0400, Andrew Dunstan wrote: Umm, no, you could either install the SRPM in a build directory, and look there, or extract the script from the built RPM using rpm2cpio. ... actually I am maintaining SuSE spec and patches unofficially in RPM repository: https://projects.commandprompt.com/public/pgcore/browser/rpm/suse/8.3/postgresql/OS-11.1/ I'm open to contributions. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Linux LSB init script
Andrew Dunstan and...@dunslane.net writes: Kevin Grittner wrote: So while OpenSuse seems a little less restrictive, it's still not something we can copy into the PostgreSQL distribution, right? right. Right. Your clean-room approach seems to have been the right thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On ons, 2009-09-02 at 09:13 -0500, Kevin Grittner wrote: We don't have the distribution's PostgreSQL package installed on any of our machines, so I'd have to install it and risk breaking something to even have a look at it. Using Midnight Commander is the canonical way to peek inside uninstalled RPM packages. :) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Hello Kevin,
a technical comment about line 71 and following of your shell script:
# Check that we have one parameter: action
if [ $# -ne 1 ] ; then
if [ $# -lt 1 -o $1 = ] ] ; then
log_failure_msg $0: action not specified
else
log_failure_msg $0: too many parameters
fi
log_warning_msg $usage
exit 2
fi
action=$1
I think in the second if there's a closing square bracket too much.
Wolfgang
Von: Kevin Grittner kevin.gritt...@wicourts.gov
An: Andrew Dunstan and...@dunslane.net
CC: David Fetter da...@fetter.org; Greg Stark gsst...@mit.edu;
pgsql-hackers@postgresql.org
Gesendet: Montag, den 31. August 2009, 21:06:22 Uhr
Betreff: Re: [HACKERS] Linux LSB init script
Andrew Dunstan and...@dunslane.net wrote:
cvsutils
That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a couple minor fixes to what I posted in new
file form. I was holding off on the CommitFest entry until I sorted
out the format; I'll link here as version 1 of the patch.
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/linux-lsb
*** /dev/null 1 Jan 1970 00:00:00 -
--- contrib/start-scripts/linux-lsb 31 Aug 2009 19:02:11 -
***
*** 0
--- 1,298
+ #! /bin/sh
+
+ ### BEGIN INIT INFO
+ # Provides: postgresql
+ # Required-Start: $local_fs $network $syslog
+ # Should-Start: $remote_fs $named $time
+ # Required-Stop: $local_fs $network $syslog
+ # Should-Stop: $remote_fs $named
+ # Default-Start: 2 3 4 5
+ # Default-Stop: 0 1 6
+ # Short-Description: PostgreSQL RDBMS
+ # Description: PostgreSQL RDBMS service.
+ # The world's most advanced open source database.
+ # See http://www.postgresql.org/ for more information.
+ ### END INIT INFO
+
+ # This is an example of a Linux LSB conforming init script.
+ # See http://refspecs.freestandards.org/ for more information on LSB.
+
+ # Original author: Kevin Grittner
+
+ # $PostgreSQL$
+
+ #
+ # The only edits needed should be in the INIT INFO block above
+ # and between the lines of dashes below. If any other
+ # changes are needed, or you find a way to enhance the script,
+ # consider posting to the PostgreSQL hackers list.
+ #
+
+ # Installation prefix
+ prefix=/usr/local/pgsql
+
+ # Data directory
+ PGDATA=/var/local/pgsql/data
+
+ # Who to run the postmaster as, usually postgres. (NOT root)
+ PGUSER=postgres
+
+ # Where to keep a log file
+ PGLOG=$PGDATA/serverlog
+
+ #
+
+ # The path that is to be used for the script
+ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+
+ # The LSB functions must be present.
+ lsbf=/lib/lsb/init-functions
+ test -r $lsbf || {
+ echo $0: not able to read $lsbf: script cannot run 12
+ exit 5
+ }
+
+ # Source the functions.
+ . $lsbf
+ # All output from the script should be through the LSB msg functions after this.
+
+ # Define usage string, used in more than one place.
+ usage=Usage: $0 {start|stop|restart|try-restart|reload|force-reload|status}
+
+ # Check that we have one parameter: action
+ if [ $# -ne 1 ] ; then
+ if [ $# -lt 1 -o $1 = ] ] ; then
+ log_failure_msg $0: action not specified
+ else
+ log_failure_msg $0: too many parameters
+ fi
+ log_warning_msg $usage
+ exit 2
+ fi
+ action=$1
+
+ # What to use to manipulate the postmaster.
+ PGCTL=$prefix/bin/pg_ctl
+
+ # Only start if we can find pg_ctl.
+ test -x $PGCTL || {
+ if [ $action = stop ] ; then
+ log_warning_msg $0: executable $PGCTL not found: $action request ignored
+ exit 0
+ else
+ log_failure_msg $0: executable $PGCTL not found: $action request failed
+ exit 5
+ fi
+ }
+
+ pidfile=$PGDATA/postmaster.pid
+ servicename=$( basename $0 )
+ daemon=$prefix/bin/postgres
+
+ pg_initd_start () {
+ echo -n Starting $servicename:
+ su -c . '$lsbf' ; start_daemon -p '$pidfile' '$PGCTL' -w -D '$PGDATA' -l '$PGLOG' start - $PGUSER
+ rc=$?
+ }
+
+ pg_initd_stop () {
+ pidlist=$( pidofproc -p $pidfile $daemon )
+ if [ $pidlist = ] ; then
+ # If this happens, the process went away after the initial check.
+ echo $servicename: not running
+ rc=0
+ return
+ fi
+ echo -n Shutting down $servicename:
+ su -c . \$lsbf\ ; killproc -p '$pidfile' '$daemon' SIGINT - $PGUSER
+ echo -n 'waiting for server to stop...'
+ rc=1
+ # Try fast shutdown for a while.
+ for seconds in $( seq 50 ) ; do
+ echo -n '.'
+ if ! ps -o pid= -p $pidlist /dev/null ; then
+ rc=0
+ break
+ fi
+ sleep 1
+ done
+ # Fast didn't do it; try immediate shutdown.
+ if [ $rc -ne 0
Re: [HACKERS] Linux LSB init script
Wolfgang Wilhelm wolfgang20121...@yahoo.de wrote:
if [ $# -lt 1 -o $1 = ] ] ; then
Oops. Fixed patch attached. Thanks!
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/linux-lsb
*** /dev/null 1 Jan 1970 00:00:00 -
--- contrib/start-scripts/linux-lsb 2 Sep 2009 20:04:48 -
***
*** 0
--- 1,298
+ #! /bin/sh
+
+ ### BEGIN INIT INFO
+ # Provides: postgresql
+ # Required-Start: $local_fs $network $syslog
+ # Should-Start: $remote_fs $named $time
+ # Required-Stop: $local_fs $network $syslog
+ # Should-Stop: $remote_fs $named
+ # Default-Start: 2 3 4 5
+ # Default-Stop: 0 1 6
+ # Short-Description: PostgreSQL RDBMS
+ # Description: PostgreSQL RDBMS service.
+ # The world's most advanced open source database.
+ # See http://www.postgresql.org/ for more information.
+ ### END INIT INFO
+
+ # This is an example of a Linux LSB conforming init script.
+ # See http://refspecs.freestandards.org/ for more information on LSB.
+
+ # Original author: Kevin Grittner
+
+ # $PostgreSQL$
+
+ #
+ # The only edits needed should be in the INIT INFO block above
+ # and between the lines of dashes below. If any other
+ # changes are needed, or you find a way to enhance the script,
+ # consider posting to the PostgreSQL hackers list.
+ #
+
+ # Installation prefix
+ prefix=/usr/local/pgsql
+
+ # Data directory
+ PGDATA=/var/local/pgsql/data
+
+ # Who to run the postmaster as, usually postgres. (NOT root)
+ PGUSER=postgres
+
+ # Where to keep a log file
+ PGLOG=$PGDATA/serverlog
+
+ #
+
+ # The path that is to be used for the script
+ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+
+ # The LSB functions must be present.
+ lsbf=/lib/lsb/init-functions
+ test -r $lsbf || {
+ echo $0: not able to read $lsbf: script cannot run 12
+ exit 5
+ }
+
+ # Source the functions.
+ . $lsbf
+ # All output from the script should be through the LSB msg functions after
this.
+
+ # Define usage string, used in more than one place.
+ usage=Usage: $0 {start|stop|restart|try-restart|reload|force-reload|status}
+
+ # Check that we have one parameter: action
+ if [ $# -ne 1 ] ; then
+ if [ $# -lt 1 -o $1 = ] ; then
+ log_failure_msg $0: action not specified
+ else
+ log_failure_msg $0: too many parameters
+ fi
+ log_warning_msg $usage
+ exit 2
+ fi
+ action=$1
+
+ # What to use to manipulate the postmaster.
+ PGCTL=$prefix/bin/pg_ctl
+
+ # Only start if we can find pg_ctl.
+ test -x $PGCTL || {
+ if [ $action = stop ] ; then
+ log_warning_msg $0: executable $PGCTL not found: $action request
ignored
+ exit 0
+ else
+ log_failure_msg $0: executable $PGCTL not found: $action request
failed
+ exit 5
+ fi
+ }
+
+ pidfile=$PGDATA/postmaster.pid
+ servicename=$( basename $0 )
+ daemon=$prefix/bin/postgres
+
+ pg_initd_start () {
+ echo -n Starting $servicename:
+ su -c . '$lsbf' ; start_daemon -p '$pidfile' '$PGCTL' -w -D '$PGDATA' -l
'$PGLOG' start - $PGUSER
+ rc=$?
+ }
+
+ pg_initd_stop () {
+ pidlist=$( pidofproc -p $pidfile $daemon )
+ if [ $pidlist = ] ; then
+ # If this happens, the process went away after the initial check.
+ echo $servicename: not running
+ rc=0
+ return
+ fi
+ echo -n Shutting down $servicename:
+ su -c . \$lsbf\ ; killproc -p '$pidfile' '$daemon' SIGINT - $PGUSER
+ echo -n 'waiting for server to stop...'
+ rc=1
+ # Try fast shutdown for a while.
+ for seconds in $( seq 50 ) ; do
+ echo -n '.'
+ if ! ps -o pid= -p $pidlist /dev/null ; then
+ rc=0
+ break
+ fi
+ sleep 1
+ done
+ # Fast didn't do it; try immediate shutdown.
+ if [ $rc -ne 0 ] ; then
+ su -c . \$lsbf\ ; killproc -p '$pidfile' '$daemon' SIGQUIT - $PGUSER
+ for seconds in $( seq 10 ) ; do
+ echo -n '!'
+ if ! ps -o pid= -p $pidlist /dev/null ; then
+ rc=0
+ break
+ fi
+ sleep 1
+ done
+ fi
+ ! ps -o pid= -p $pidlist /dev/null
+ rc=$?
+ if [ $rc -eq 0 ] ; then
+ echo ' done'
+ rm -f $pidfile
+ else
+ echo ' failed'
+ fi
+ }
+
+ pg_initd_reload () {
+ su -c $PGCTL reload -D '$PGDATA' - $PGUSER
+ rc=$?
+ }
+
+ pg_initd_status () {
+ if [ ! -f $pidfile ] ; then
+ rc=3
+ else
+ su -c . \$lsbf\ ; pidofproc -p '$pidfile' '$daemon' - $PGUSER
1/dev/null
+ rc=$?
+ if [ $rc -eq 0 ] ; then
+ su -c . \$lsbf\ ; $PGCTL status -D '$PGDATA' - $PGUSER
+ rc=$?
+ if [ $rc -ne 0 ] ; then
+ # pg_ctl doesn't return LSB conforming values; treat non-success as
unknown
+
Re: [HACKERS] Linux LSB init script
On mån, 2009-08-31 at 20:54 -0400, Greg Smith wrote: On Mon, 31 Aug 2009, Kevin Grittner wrote: My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. Given that it's also RPM based, is it possible to get SuSE in sync so that it shares the same init script as RHEL? Devrim is in the middle of a major overhaul of the RHEL/Fedora init script lately, adding better support for multiple postmasters and the like, and I'd think that SuSE users would like to take advantage of that work too. Well, the init script of the SUSE RPM is not the problem. (It was, arguably, one of the bright spots for a long time, since they removed lots of legacy wackyness accumulated from the Red Hat era.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote: My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. It also doesn't enable debug info or integer date times. So we switched to build from source before we actually got as far as loading any data. I'm inclined to recommend the same to others. Fixes and help are welcome, btw. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: On mån, 2009-08-31 at 15:17 -0500, Kevin Grittner wrote: the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. It also doesn't enable debug info or integer date times. Fixes and help are welcome, btw. We're using SLES10. If we installed the latest from the SuSE site, we would be at PostgreSQL version 8.1. Now, to their credit, that is 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at whether to go back to 8.1. And unless I'm remembering incorrectly, the configure options are not what we would want. I don't see any reason the packaged build shouldn't be with --enable-debug on a platform where that has no performance hit. I never understood why anyone converting to PostgreSQL would want the floating point approximate timestamps rather than using --enable-integer-datetimes. We don't have a need for multiple languages, so I figure it's best to use --diable-nls, although I doubt that one's a huge deal. Since we have much XML in our database, I'm building with --with-libxml, just in case someone decides they want to use xpath. And since we often need more than one version of PostgreSQL on a server, we always use a prefix of /usr/local/pgsql-version and use a symlink to map one version to the default we put on our PATH. (Our init scripts always point to the version-specific locations.) I wouldn't expect a packaged SuSE build to cater to all of that; but it would be nice if they donated their init script to the PostgreSQL project, so that those of us who have a reason to build from source on SuSE have have a convenient starting point in the source distribution of PostgreSQL. I seem to remember that SuSE has an abstraction layer similar to the functions I defined in my linux-lsb script. I couldn't use those in a portable LSB submission, but if there's anything in what I did which is of any use to SuSE, there's no reason for SuSE not to use it. I'm putting it under the same license as the rest of PostgreSQL. Although, now that I think of it, I don't think I actually put any copyright or license message into the file yet. In any event, I think I've come up with something which should work pretty well on any LSB conforming implementation, including SuSE. If we get the pg_ping functionality which is occassionally discussed, it can be made really bulletproof. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote: We're using SLES10. If we installed the latest from the SuSE site, we would be at PostgreSQL version 8.1. Now, to their credit, that is 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at whether to go back to 8.1. Well, that is not surprising. At the time SLES 10 was released, PostgreSQL 8.1 was the stable PostgreSQL release. If you want major upgrades, you shouldn't be looking for the SLES 10 upgrade channel to provide you that. If you want to have out-of-line, unsupported updates, you can get them from the OpenSuse build service. I think you will find exactly the same/analogous situation for any enterprise Linux distribution or other operating system. And unless I'm remembering incorrectly, the configure options are not what we would want. I don't see any reason the packaged build shouldn't be with --enable-debug on a platform where that has no performance hit. Debatable, but it's not upstream default, so why should it be downstream default? I never understood why anyone converting to PostgreSQL would want the floating point approximate timestamps rather than using --enable-integer-datetimes. Backward compatibility. Same issue with RHEL; discussion in archives. We don't have a need for multiple languages, so I figure it's best to use --diable-nls, although I doubt that one's a huge deal. Well, that's not a reason to rebuild from source, although it could be a reason to rebuild the RPM. I wouldn't expect a packaged SuSE build to cater to all of that; but it would be nice if they donated their init script to the PostgreSQL project, so that those of us who have a reason to build from source on SuSE have have a convenient starting point in the source distribution of PostgreSQL. Well, no one needs to donate anything. If you are interested in maintaining it, just take it and put it under contrib/start-scripts. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net writes: On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote: And unless I'm remembering incorrectly, the configure options are not what we would want. I don't see any reason the packaged build shouldn't be with --enable-debug on a platform where that has no performance hit. Debatable, but it's not upstream default, so why should it be downstream default? FWIW, that particular issue is invariably a matter of distro policy; they could care less what upstream's default is. For instance Red Hat *always* builds all RPMs with debug enabled, and then splits the debug data off into separate debuginfo RPMs, which are not installed by default for space/bandwidth reasons. But you can get debug symbols when you need 'em. I don't know what Debian or SUSE do, but I'm sure they do it consistently across all their packages. A lot of other packaging choices are likewise driven by distro-wide policy and not what a particular upstream package might choose as default. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Sep 1, 2009, at 6:43 PM, Tom Lane wrote: Debatable, but it's not upstream default, so why should it be downstream default? FWIW, that particular issue is invariably a matter of distro policy; they could care less what upstream's default is. Well, they could, but do they? /me offers Tom a not. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Kevin Grittner wrote: We're using SLES10. If we installed the latest from the SuSE site, we would be at PostgreSQL version 8.1. Now, to their credit, that is 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at whether to go back to 8.1. I recently build 8.4 RPMs for SLES10/SP2 and they are running very nicely for a very happy customer. IIRC I got the SRPM from the OpenSuse site. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: If it's a new file, it's pointless to send a patch anyway. If people are OK with just sending the new file, that's cool with me. From the other posts, it appears that I need to have my own copy of the repository to do it as a patch, or download a tool. (Thanks to those who offered the suggestions.) You could also consider putting it in place of the linux file. Is the LSB standard sufficiently widely adopted to omit the older format? I was concerned that there might be Linux versions we wanted to support which wouldn't have a /lib/lsb/init-functions file to source. If that's not an issue, I could submit this as a patch to the existing file. (It'd be a - for almost every non-blank line in the old, and a + for almost every non-blank line in the new, of course.) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Andrew Dunstan and...@dunslane.net wrote:
cvsutils
That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the
attached. This contains a couple minor fixes to what I posted in new
file form. I was holding off on the CommitFest entry until I sorted
out the format; I'll link here as version 1 of the patch.
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/linux-lsb
*** /dev/null 1 Jan 1970 00:00:00 -
--- contrib/start-scripts/linux-lsb 31 Aug 2009 19:02:11 -
***
*** 0
--- 1,298
+ #! /bin/sh
+
+ ### BEGIN INIT INFO
+ # Provides: postgresql
+ # Required-Start: $local_fs $network $syslog
+ # Should-Start: $remote_fs $named $time
+ # Required-Stop: $local_fs $network $syslog
+ # Should-Stop: $remote_fs $named
+ # Default-Start: 2 3 4 5
+ # Default-Stop: 0 1 6
+ # Short-Description: PostgreSQL RDBMS
+ # Description: PostgreSQL RDBMS service.
+ # The world's most advanced open source database.
+ # See http://www.postgresql.org/ for more information.
+ ### END INIT INFO
+
+ # This is an example of a Linux LSB conforming init script.
+ # See http://refspecs.freestandards.org/ for more information on LSB.
+
+ # Original author: Kevin Grittner
+
+ # $PostgreSQL$
+
+ #
+ # The only edits needed should be in the INIT INFO block above
+ # and between the lines of dashes below. If any other
+ # changes are needed, or you find a way to enhance the script,
+ # consider posting to the PostgreSQL hackers list.
+ #
+
+ # Installation prefix
+ prefix=/usr/local/pgsql
+
+ # Data directory
+ PGDATA=/var/local/pgsql/data
+
+ # Who to run the postmaster as, usually postgres. (NOT root)
+ PGUSER=postgres
+
+ # Where to keep a log file
+ PGLOG=$PGDATA/serverlog
+
+ #
+
+ # The path that is to be used for the script
+ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+
+ # The LSB functions must be present.
+ lsbf=/lib/lsb/init-functions
+ test -r $lsbf || {
+ echo $0: not able to read $lsbf: script cannot run 12
+ exit 5
+ }
+
+ # Source the functions.
+ . $lsbf
+ # All output from the script should be through the LSB msg functions after
this.
+
+ # Define usage string, used in more than one place.
+ usage=Usage: $0 {start|stop|restart|try-restart|reload|force-reload|status}
+
+ # Check that we have one parameter: action
+ if [ $# -ne 1 ] ; then
+ if [ $# -lt 1 -o $1 = ] ] ; then
+ log_failure_msg $0: action not specified
+ else
+ log_failure_msg $0: too many parameters
+ fi
+ log_warning_msg $usage
+ exit 2
+ fi
+ action=$1
+
+ # What to use to manipulate the postmaster.
+ PGCTL=$prefix/bin/pg_ctl
+
+ # Only start if we can find pg_ctl.
+ test -x $PGCTL || {
+ if [ $action = stop ] ; then
+ log_warning_msg $0: executable $PGCTL not found: $action request
ignored
+ exit 0
+ else
+ log_failure_msg $0: executable $PGCTL not found: $action request
failed
+ exit 5
+ fi
+ }
+
+ pidfile=$PGDATA/postmaster.pid
+ servicename=$( basename $0 )
+ daemon=$prefix/bin/postgres
+
+ pg_initd_start () {
+ echo -n Starting $servicename:
+ su -c . '$lsbf' ; start_daemon -p '$pidfile' '$PGCTL' -w -D '$PGDATA' -l
'$PGLOG' start - $PGUSER
+ rc=$?
+ }
+
+ pg_initd_stop () {
+ pidlist=$( pidofproc -p $pidfile $daemon )
+ if [ $pidlist = ] ; then
+ # If this happens, the process went away after the initial check.
+ echo $servicename: not running
+ rc=0
+ return
+ fi
+ echo -n Shutting down $servicename:
+ su -c . \$lsbf\ ; killproc -p '$pidfile' '$daemon' SIGINT - $PGUSER
+ echo -n 'waiting for server to stop...'
+ rc=1
+ # Try fast shutdown for a while.
+ for seconds in $( seq 50 ) ; do
+ echo -n '.'
+ if ! ps -o pid= -p $pidlist /dev/null ; then
+ rc=0
+ break
+ fi
+ sleep 1
+ done
+ # Fast didn't do it; try immediate shutdown.
+ if [ $rc -ne 0 ] ; then
+ su -c . \$lsbf\ ; killproc -p '$pidfile' '$daemon' SIGQUIT - $PGUSER
+ for seconds in $( seq 10 ) ; do
+ echo -n '!'
+ if ! ps -o pid= -p $pidlist /dev/null ; then
+ rc=0
+ break
+ fi
+ sleep 1
+ done
+ fi
+ ! ps -o pid= -p $pidlist /dev/null
+ rc=$?
+ if [ $rc -eq 0 ] ; then
+ echo ' done'
+ rm -f $pidfile
+ else
+ echo ' failed'
+ fi
+ }
+
+ pg_initd_reload () {
+ su -c $PGCTL reload -D '$PGDATA' - $PGUSER
+ rc=$?
+ }
+
+ pg_initd_status () {
+ if [ ! -f $pidfile ] ; then
+ rc=3
+ else
+ su -c . \$lsbf\ ; pidofproc -p '$pidfile' '$daemon' - $PGUSER
1/dev/null
+ rc=$?
+ if [ $rc -eq 0 ] ; then
+ su
Re: [HACKERS] Linux LSB init script
On Mon, 31 Aug 2009, Kevin Grittner wrote: Is the LSB standard sufficiently widely adopted to omit the older format? I'm not sure, and 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. Given that there was recent chatter on removing the Linux init scripts altogether, 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. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Greg Smith gsm...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On mån, 2009-08-31 at 12:07 -0500, Kevin Grittner wrote: Is the LSB standard sufficiently widely adopted to omit the older format? I was concerned that there might be Linux versions we wanted to support which wouldn't have a /lib/lsb/init-functions file to source. If that's not an issue, I could submit this as a patch to the existing file. (It'd be a - for almost every non-blank line in the old, and a + for almost every non-blank line in the new, of course.) While the major distributions support LSB, the major distributions also have PostgreSQL packages available and so will likely not need the init script shipped in the source. It will most likely be useful for various do-it-yourself setups on fringe distributions. So I don't know; it might be best to keep both, if they are maintained. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
Peter Eisentraut pete...@gmx.net wrote: While the major distributions support LSB, the major distributions also have PostgreSQL packages available and so will likely not need the init script shipped in the source. My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. It also doesn't enable debug info or integer date times. So we switched to build from source before we actually got as far as loading any data. I'm inclined to recommend the same to others. it might be best to keep both, if they are maintained. Sounds good to me; although, now that there is a full LSB version, I should probably withdraw my meager suggested patch to the existing linux script, eh? (If they're using an LSB conforming implementation, they'll want the linux-lsb script, and if they're not, the suggested patch has no point, I think.) Unless someone thinks otherwise, I'll drop that patch to the linux script from the CF page. Any thoughts on what that script needs, if anything? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Mon, 31 Aug 2009, Kevin Grittner wrote: My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. Given that it's also RPM based, is it possible to get SuSE in sync so that it shares the same init script as RHEL? Devrim is in the middle of a major overhaul of the RHEL/Fedora init script lately, adding better support for multiple postmasters and the like, and I'd think that SuSE users would like to take advantage of that work too. It seems to me that the only popular Linux versions that people use for PostgreSQL work that don't have active init script maintainers are SuSE and Gentoo. If your LSB-based approach could be made to work on both those, that would be a nice step forward. I don't know what the state of the init script that Gentoo ships is though, I'm guessing it may diverge from the standard approach due to its slots implementation. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
I wrote: But before I spend a lot of time fine-tuning it, I wanted to post this as a proof-of-concept draft and see if people think it's on the right track. I chose to take the lack of response as an indication that nobody who cares about this thought there was anything seriously wrong with the draft, so I tidied it up and did more testing. I'm submitting this for the next CommitFest. I'm attaching the file which I propose to include in the contrib/start-scripts subdirectory. If it is preferred that a new file be in patch form, I need a clue from someone how to create that. -Kevin linux-lsb Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 04:41:47PM -0500, Kevin Grittner wrote: I wrote: But before I spend a lot of time fine-tuning it, I wanted to post this as a proof-of-concept draft and see if people think it's on the right track. I chose to take the lack of response as an indication that nobody who cares about this thought there was anything seriously wrong with the draft, so I tidied it up and did more testing. I'm submitting this for the next CommitFest. I'm attaching the file which I propose to include in the contrib/start-scripts subdirectory. If it is preferred that a new file be in patch form, I need a clue from someone how to create that. cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 04:57:24PM -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? Might be easier with git, then :/ Cheers, David (let's move to git!) -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote: On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On fre, 2009-08-28 at 16:57 -0500, Kevin Grittner wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: kgri...@kgrittn-desktop:~/pg/pgsql$ cvs diff -c -N contrib/start-scripts/linux-lsb ../linux-lsb.patch cvs diff: I know nothing about contrib/start-scripts/linux-lsb Same behavior with and without the -N flag. What am I missing? If it's a new file, it's pointless to send a patch anyway. You could also consider putting it in place of the linux file. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
On Fri, Aug 28, 2009 at 11:59 PM, David Fetterda...@fetter.org wrote: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. True. The only workable way to use cvs that i found was to rsync the repository and then check out from that. If you cvs add then then the next rsync will overwrite your cvs add but in the meantime i think you could do cvs diff. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Linux LSB init script
David Fetter wrote: On Fri, Aug 28, 2009 at 11:57:07PM +0100, Greg Stark wrote: On Fri, Aug 28, 2009 at 10:57 PM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: David Fetter da...@fetter.org wrote: cvs diff if you're on CVS. If you're using git, commit to your local repository and git-diff. I tried that. When I just did it at the top level, it ignored the new file. When I specified the file: You have to cvs add the file That only works if you have write permissions to the central repo. I don't. cvsutils IYF. See http://www.red-bean.com/cvsutils/ If you're on Fedora at least yum install cvsutils should be all you need to do. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Linux LSB init script
Here's a first rough cut of Linux script which attempts to launch PostgreSQL as a somewhat LSB conforming application. It's very lightly tested and I haven't gone through to confirm that every corner case is handled exactly right; in fact on my kubuntu workstation (the only place I've tested so far) the status command returns 4 (program or service status is unknown) when I think it should be returning 3 (program is not running), so I've got something to chase down there. And I haven't even tried to deal with the false positive problem yet. But before I spend a lot of time fine-tuning it, I wanted to post this as a proof-of-concept draft and see if people think it's on the right track. Did I do anything which is considered bad technique? Am I using any techniques which aren't sufficiently portable? Is anything just outright *wrong*? Comments welcome. -Kevin linux-lsb Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
