+++ This bug was initially created as a clone of Bug #325511 +++ .qa.[root@amd64-4as tps]# service tog-pegasus start Starting up CIM server: [ OK ] .qa.[root@amd64-4as tps]# service tog-pegasus stop Shutting down CIM server: [ OK ] .qa.[root@amd64-4as tps]# service tog-pegasus stop Shutting down CIM server: [FAILED] .qa.[root@amd64-4as tps]# echo $? 1 ^^ This return code is wrong. It should either be 7 (according to http://intranet.corp.redhat.com/ic/intranet/InitscriptsSpec.html) .qa.[root@amd64-4as tps]# rpm -q tog-pegasus tog-pegasus-2.5.1-5.EL4.x86_64 -- Additional comment from dkovalsk on 2007-10-09 16:18 EST -- Setting 4.7 flag to ? and putting 4.6 back to the original bug. -- Additional comment from dkovalsk on 2007-10-10 08:30 EST -- Also the return code of the status command is wrong when the pid file exists: # Make sure tog-pegasus service is started and # set the immutable attribute so that the pid file does not get removed # or you just create the pid file while the service is stopped .qa.[root@ppcp-4as-bos ~]# service tog-pegasus start Starting up CIM server: [ OK ] .qa.[root@ppcp-4as-bos ~]# chattr +i /var/run/tog-pegasus/cimserver.pid .qa.[root@ppcp-4as-bos ~]# service tog-pegasus stop rm: cannot remove `/var/run/tog-pegasus/cimserver.pid': Operation not permitted [ OK ] # Check the status .qa.[root@ppcp-4as-bos ~]# service tog-pegasus status CIM server is not running .qa.[root@ppcp-4as-bos ~]# echo $? 3 According to http://intranet.corp.redhat.com/ic/intranet/InitscriptsSpec.html this should be 1 - program is dead and /var/run pid file exists Very similar with the lock file, where the return value should be 2. -- Additional comment from dkovalsk on 2007-10-10 08:43 EST -- Another thing to think about is the return code of `service tog-pegasus stop' which is 0 even if lock/run file is not removed. IMO this shouldn't be zero as the shutdown wasn't 100% successful. Note that this isn't an artifical situation - this can simply happen when the filesystem with /var is remounted read-only.
.qa.[root@x86_64-5server tps]# rpm -q tog-pegasus tog-pegasus-2.6.1-2.el5.x86_64 tog-pegasus-2.6.1-2.el5.i386
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Please note this: Pid file and lock file cases are fixed. The first case (when trying stop on already stopped service) will return 0, not 7 as you propose. Zero is right return value here, see: https://bugzilla.redhat.com/show_bug.cgi?id=443010
In case that lock file exists still returns 3 (expected is 2). Repro steps: [root@i386-5s-m1 tps]# service tog-pegasus start [root@i386-5s-m1 tps]# chattr +i /var/run/tog-pegasus/cimserver_start.lock [root@i386-5s-m1 tps]# service tog-pegasus stop rm: cannot remove `/var/run/tog-pegasus/cimserver_start.lock': Operation not permitted [ OK ] .live.[root@i386-5s-m1 tps]# service tog-pegasus status CIM server is not running .live.[root@i386-5s-m1 tps]# echo $? 3 ^^^ (In reply to comment #5) > Please note this: > > Pid file and lock file cases are fixed. The first case (when trying stop on > already stopped service) will return 0, not 7 as you propose. Zero is right > return value here, see: > > https://bugzilla.redhat.com/show_bug.cgi?id=443010
Hm, I checked these files (taken from init script): LOCKFILE=/var/lock/subsys/tog-pegasus PIDFILE=/var/run/tog-pegasus/cimserver.pid
After discussion with David, the script should check both lock files. (In reply to comment #8) > Hm, I checked these files (taken from init script): > > LOCKFILE=/var/lock/subsys/tog-pegasus > PIDFILE=/var/run/tog-pegasus/cimserver.pid
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0250.html