Bug 84096
| Summary: | starting S85postgresql service ($NAME) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | Jay Berkenbilt <ejb> | ||||||
| Component: | postgresql | Assignee: | Andrew Overholt <overholt> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | beta1 | CC: | ejb, marius.andreiana, mitr, overholt | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2003-07-30 13:01:16 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 79578 | ||||||||
| Attachments: |
|
||||||||
This does not happen with the new 7.3.2 RPMs AFAICT. Resolving. This was never actually resolved, and it's here in SEVERN. I'll post a patch momentarily. The problem is that the init script was checking for the special case of
`basename $0` starting with S90. Well, it starts with S85. Besides, see all my
points above about why it doesn't make sense to use basename $0 as NAME.
Anyway, if someone is afraid of hard coding postgresql, why weren't they afraid
of hardcoding S90? The S90 is much more likely to change.
If people insisted upon keeping NAME based on $0, then I would suggest changing
line 69 (search for S90) to this:
if [ ${NAME:0:1} = "S" -o ${NAME:0:1} = "K" ]
A better fix is to just remove that whole thing and hard code NAME to postgresql
so that all the other things like the files in /etc/sysconfig and /var/lock are
named based on the service rather than based on the particular way in which it
was invoked. If the intention were to allow multiple instances to run under
different names, that would be different, but it doesn't seem that that would
work or be the case.
My preferred fix is attached both as a patch and as a modified postgresql.init
which is one of the SOURCEs in the rpm.
I'm taking the liberty of increasing the priority to "high" since this is both
trivial and important. (The wrong file in /etc/sysconfig gets read as a result
of this bug -- it's not just that the wrong message gets printed during boot.)
Created attachment 93246 [details]
patch to postgresql.init from postgresql-7.3.3-4.src.rpm
Created attachment 93247 [details]
modified postgresql.init for postgresql-7.3.3-4.src.rpm
I believe that the original basename call was there to allow for multiple postmasters (I didn't add it myself). The init script is being completely rewritten and I'm hesitant to make any major changes at this time. I like your second solution best and have incorporated it. It should be in rawhide soon. I'm going to close this for now, but watch for the new initscript soon. Thanks. |
Description of problem: The init.d/postgresql script does a lot of stuff with $NAME which it sets to `basename $0`. This causes, among other things, the message Starting S85postgresql service: [ OK ] message at boot time, which looks pretty out of place. It also means that it creates /var/lock/subsys/S85postgresql and looks for /etc/sysconfig/S85postgresql, both of which seem pretty odd. It also means that running "service postgresql stop" does not cause /var/lock/subsys/S85postgresql to disappear. This seems most unfortunate. Surely none of these things should really depend upon `basename $0`, right? What would happen if it just said NAME=postgresql? I can't figure out why anyone would want to do this the way it is. The only hint in the change log (rpm -qi --changelog) is 12/13/02 Updated initscript to new community version (overholt), but I don't know whether this is related. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. observe boot (with postgres enabled) 2. stop service with service postgresql stop Actual results: Boot message says "Service S85postgresql started" and creates /var/lock/subsys/S85postgresql; shutdown leaves /var/lock/subsys/S85postgresql around. Expected results: Boot message should say "Service postgresql started" and should create /var/lock/subsys/postgresql which should in turn be removed no matter whether the service is shut down by init or by hand. Additional info: