Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 598032 - /sbin/pidof does some undocumented magic
Summary: /sbin/pidof does some undocumented magic
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: SysVinit
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Bill Nottingham
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-31 09:45 UTC by David Tonhofer
Modified: 2014-03-17 03:23 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-03 16:12:25 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description David Tonhofer 2010-05-31 09:45:18 UTC
Description of problem:


I use /sbin/pidof to check for the presence of JBoss instances, like this:

$ pidof -x '/var/tomcat/jboss_INSTANCE1/jboss_home/bin/run.sh'
$ pidof -x '/var/tomcat/jboss_INSTANCE2/jboss_home/bin/run.sh'

In this case, the partial paths

  /var/tomcat/jboss_INSTANCE2/jboss_home
  /var/tomcat/jboss_INSTANCE1/jboss_home

resolve to symlinks actually pointing to the same directory under which /bin/run.sh can be found.

  /var/tomcat/jboss_INSTANCE2/jboss_home-----+
  /var/tomcat/jboss_INSTANCE1/jboss_home--+  |
                                          V  V
                           /usr/local/jboss_home/bin/run.sh                   

If given as above, pidof correctly detects the running processes.

However, the JBoss init script that comes with JBoss would modify the arguments given to pidof by inserting backslashes, yielding:

$  pidof -x '\/var\/tomcat\/jboss_INSTANCE1\/jboss_home\/bin\/run.sh'
$  pidof -x '\/var\/tomcat\/jboss_INSTANCE2\/jboss_home\/bin\/run.sh'

(The code in the init script is:

   local name=$(echo $1 | sed 's/\//\\\//g')
   local pids=`/sbin/pidof -x "$name"` )

In this case, pidof cannot distinguish between the processes named

  /var/tomcat/jboss_INSTANCE1/jboss_home/bin/run.sh

and 

  /var/tomcat/jboss_INSTANCE2/jboss_home/bin/run.sh


If /var/tomcat/jboss_INSTANCE1/jboss_home/bin/run.sh is running and you ask for 

$ pidof -x '\/var\/tomcat\/jboss_INSTANCE2\/jboss_home\/bin\/run.sh'

you actually get the pid of INSTANCE1


Unsure whether this is expected behaviour, but this is definitely not documented in the man page.


Version-Release number of selected component (if applicable):

SysVinit-2.86-15.el5

How reproducible:

Always

Comment 1 Bill Nottingham 2010-06-01 21:47:48 UTC
That looks like a bug in the script... the escaping, when passed inside single quotes, is being read as an actual path, relative to the current working directory. So it just ends up falling back to looking for run.sh.

Comment 2 David Tonhofer 2010-06-03 13:09:53 UTC
Hi Bill.

So, '\/var\/tomcat\/jboss_INSTANCE2\/jboss_home\/bin\/run.sh'

actually means

"run.sh" 
in directory "\/var\/tomcat\/jboss_INSTANCE2\/jboss_home\/bin\"

I should have thought of that.


Nevertheless, "man pidof()" should probably say something about the "look only at basename" fallback behaviour. On second thoughts, looking at the source, this algorithm is subtle, so maybe not.

http://www.google.com/codesearch/p?hl=en#5KTrgOW2hXs/pub/nslu2/sources/sysvinit-2.86.tar.gz|ltlg2zhkxVY/sysvinit-2.86/src/killall5.c&q=killall5%20lang:c

Guess good to close NOTABUG

The JBoss "pidof" usage is for JBoss 4.2.3:

function procrunning() {
   procid=0
   JBOSSSCRIPT=$(echo $JBOSSSH | awk '{print $1}' | sed 's/\//\\\//g')
   for procid in `/sbin/pidof -x "$JBOSSSCRIPT"`; do
       ps -fp $procid | grep "${JBOSSSH% *}" > /dev/null && pid=$procid
   done
}

In the latest JBoss 6, the "pidof" is no longer used.

Comment 3 Bill Nottingham 2010-06-03 16:12:25 UTC
Closing as notabug.


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