Bug 883857

Summary: lsb-defined pidofproc function has false positives
Product: Red Hat Enterprise Linux 6 Reporter: Lukáš Nykrýn <lnykryn>
Component: sysvinitAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED ERRATA QA Contact: Tereza Cerna <tcerna>
Severity: medium Docs Contact:
Priority: low    
Version: 6.5CC: dannf, initscripts-maint-list, lnykryn, msekleta, ovasik, psklenar, tcerna, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sysvinit-2.87-6.dsf.el6 Doc Type: Bug Fix
Doc Text:
Cause: Usually initscript has the same name as deamon. Due to this reason when we are looking for the PID of the deamon based on its name from a initscript we have to exclude the initscript itself. But if the initcript have started something in the subprocess this process again have the same name and can be falsely recognized as daemon itself. Consequence: pidofproc will not return the pid of the daemon Fix: Use the new -m option in pidof which excludes other similar processes. Result: Daemon pid should be determined correctly. see https://bugzilla.redhat.com/show_bug.cgi?id=883856
Story Points: ---
Clone Of: 883856 Environment:
Last Closed: 2015-07-22 07:04:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 947782, 1159825, 883856    

Description Lukáš Nykrýn 2012-12-05 12:45:18 UTC
+++ This bug was initially created as a clone of Bug #883856 +++

+++ This bug was initially created as a clone of Bug #573844 +++

Created attachment 400305 [details]
Ignore pids where the path of the running program does not match the known path of the service

Description of problem:
As allowed (but not required) by the LSB, Red Hat implements additional non-pidfile-based methods for determining if a service is running, using pidof. 

When calling pidof, the current implementation takes the precautions of telling pidof to omit the current pid, and the parent of the current pid. This is presumably to prevent a false positive where the name of the initscript matches the name of the daemon. However, I'm running into a case where this is insufficient.

My initscript's stop routine is as follows:

    stop)
        pid=$(pidofproc $DAEMON)
        if [ -z "$pid" ]; then
            log_success_msg "myservice not running"
            exit 0
        fi
        killproc $DAEMON -SIGTERM
	printf "Waiting for myservice[$pid] to terminate"
        while [ -d "/proc/$pid/" ]; do
            printf "."
            sleep 1
            echo $pid
        done
	printf "\n"
        rm -f "$PIDFILE"
	log_success_msg "$DESCRIPTION Terminated"
        ;;

When "pidofproc" runs, the following processes are running:

root     11780 10247  0 15:00 pts/0    00:00:00 /bin/sh /etc/init.d/myservice stop
root     11781 11780  0 15:00 pts/0    00:00:00 /bin/sh /etc/init.d/myservice stop
root     11782 11781  0 15:00 pts/0    00:00:00 /bin/bash /etc/redhat-lsb/lsb_pidofproc /opt/hp/my-service

As you can see, the PID & PPID checks are not sufficient, because lsb_pidofproc is adding an additional process in the chain.

Version-Release number of selected component (if applicable):
redhat-lsb-3.1-12.3.EL
initscripts-8.45.30-2.el5

How reproducible:
Always.

Steps to Reproduce:
1. Create an initscript /etc/init.d/foo for a daemon named foo
2. Make it source /lib/lsb/functions
3. Use the above shutdown code (with s/myservice/foo/ and DAEMON=/path/to/foo)
4. Call stop
  
Actual results:

/etc/init.d/foo stop will think the pid of /etc/init.d/foo is a running daemon and attempt to stop it

Expected results:

/etc/init.d/foo would know /etc/init.d/foo is not the running daemon and not attempt to kill it

Additional info:
I'll attach a suggested fix, implemented in the initscripts layer.

--- Additional comment from Ondrej Vasik on 2012-12-04 15:28:03 CET ---

Adding initscripts maintainer to CC, Lukas, please reassign it to initscripts, if you think this change is reasonable.

--- Additional comment from Lukáš Nykrýn on 2012-12-05 13:41:47 CET ---

Created attachment 658166 [details]
add -m option

We have fixed this in fedora, in newer version of pidof by parameter -m:
When  used  with  -o,  will  also  omit  any processes that have the same argv[0] and argv[1] as any explicitly omitted process ids. This can be used to avoid multiple shell scripts concurrently  calling pidof returning each other's pids.

And then it would be sufficient to just use this in pidofproc.
--- a/rc.d/init.d/functions
+++ b/rc.d/init.d/functions
@@ -204,8 +204,8 @@ __pids_var_run() {
 
 # Output PIDs of matching processes, found using pidof
 __pids_pidof() {
-       pidof -c -o $$ -o $PPID -o %PPID -x "$1" || \
-               pidof -c -o $$ -o $PPID -o %PPID -x "${1##*/}"
+       pidof -c -m -o $$ -o $PPID -o %PPID -x "$1" || \
+               pidof -c -m -o $$ -o $PPID -o %PPID -x "${1##*/}"
 }
 
This patch probably needs some minor modification to be applicable for rhel. 
I don't think it is worth of backporting for rhel5, but we should consider it for rhel6.

Comment 13 Tereza Cerna 2015-03-05 14:12:42 UTC
========================================
Verified in version:
    sysvinit-tools-2.87-6.dsf.el6.x86_64
    initscripts-9.03.40-2.el6.x86_64
PASSED
========================================

# cp /bin/sleep .
# sleep 3600 &
[1] 9264
# sleep 3600 &
[2] 9265
# ./sleep 3600 &
[3] 9266
# ./sleep 3600 &
[4] 9267
# pidof sleep
9267 9266 9265 9264
# pidof sleep -o 9265
9267 9266 9264
# pidof sleep 
9267 9266 9265 9264
# pidof sleep -o 9265 -m
9267 9266
#

========================================
Reproduced in version:
    sysvinit-tools-2.87-5.dsf.el6.x86_64
    initscripts-9.03.40-2.el6.x86_64
FAIL
========================================

# cp /bin/sleep .
# sleep 3600 &
[1] 9164
# sleep 3600 &
[2] 9165
# ./sleep 3600 &
[3] 9166
# ./sleep 3600 &
[4] 9167
# pidof sleep
9167 9166 9165 9164
# pidof -o 9165 sleep
9167 9166 9164
# pidof -o 9165 sleep -m
pidof: invalid options on command line!

#

Comment 14 errata-xmlrpc 2015-07-22 07:04:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1362.html