Bug 84096 - starting S85postgresql service ($NAME)
starting S85postgresql service ($NAME)
Status: CLOSED RAWHIDE
Product: Red Hat Linux Beta
Classification: Retired
Component: postgresql (Show other bugs)
beta1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Andrew Overholt
David Lawrence
:
Depends On:
Blocks: 79578
  Show dependency treegraph
 
Reported: 2003-02-11 23:15 EST by Jay Berkenbilt
Modified: 2007-03-27 00:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-30 09:01:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to postgresql.init from postgresql-7.3.3-4.src.rpm (498 bytes, patch)
2003-07-29 20:27 EDT, Jay Berkenbilt
no flags Details | Diff
modified postgresql.init for postgresql-7.3.3-4.src.rpm (6.35 KB, text/plain)
2003-07-29 20:28 EDT, Jay Berkenbilt
no flags Details

  None (edit)
Description Jay Berkenbilt 2003-02-11 23:15:10 EST
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@redhat.com), 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:
Comment 1 Andrew Overholt 2003-02-12 16:37:55 EST
This does not happen with the new 7.3.2 RPMs AFAICT.  Resolving.
Comment 2 Jay Berkenbilt 2003-07-29 20:06:37 EDT
This was never actually resolved, and it's here in SEVERN.  I'll post a patch
momentarily.
Comment 3 Jay Berkenbilt 2003-07-29 20:26:08 EDT
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.)
Comment 4 Jay Berkenbilt 2003-07-29 20:27:50 EDT
Created attachment 93246 [details]
patch to postgresql.init from postgresql-7.3.3-4.src.rpm
Comment 5 Jay Berkenbilt 2003-07-29 20:28:44 EDT
Created attachment 93247 [details]
modified postgresql.init for postgresql-7.3.3-4.src.rpm
Comment 6 Andrew Overholt 2003-07-30 09:01:16 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.