Red Hat Bugzilla – Bug 84096
starting S85postgresql service ($NAME)
Last modified: 2007-03-27 00:00:48 EDT
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:
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.