Bug 883856 - lsb-defined pidofproc function has false positives
Summary: lsb-defined pidofproc function has false positives
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: Jan Ščotka
URL:
Whiteboard:
Depends On: 883857
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-05 12:43 UTC by Lukáš Nykrýn
Modified: 2016-11-25 12:56 UTC (History)
5 users (show)

Fixed In Version: initscripts-9.03.48-1
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.
Clone Of: 573844
: 883857 (view as bug list)
Environment:
Last Closed: 2015-07-22 07:17:48 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1380 normal SHIPPED_LIVE initscripts bug fix update 2015-07-20 17:58:24 UTC

Description Lukáš Nykrýn 2012-12-05 12:43:43 UTC
+++ 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 7 Tereza Cerna 2015-03-09 08:15:45 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-4.dsf.el6.x86_64
    initscripts-9.03.31-2.el6.x86_64
FAIL
========================================

# cp /bin/sleep .
# sleep 3600 &
[1] 6998
# sleep 3600 &
[2] 6999
# ./sleep 3600 &
[3] 7000
# ./sleep 3600 &
[4] 7001
# pidof sleep
7001 7000 6999 6998
# pidof sleep -o 6999
7001 7000 6998
# pidof sleep -o 6999 -m
pidof: invalid options on command line!

#

Comment 9 errata-xmlrpc 2015-07-22 07:17:48 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-1380.html


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