This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Thank you for report. I have tried to reproduces this with this:
 
#!/bin/bash
yum -y remove squid
yum -y localinstall squid-3.1.4-1.el6.x86_64.rpm
yum -y localinstall squid-3.1.10-1.el6.x86_64.rpm
/etc/init.d/squid start
/sbin/pidof /usr/sbin/squid
/etc/cron.daily/prelink
/sbin/pidof /usr/sbin/squid

but pidof showed me two pids in both calling.


You wrote, that you don't have this problem in rhel-5. Can you please try if this also occurs with rhel5 version of pidof in rhel6? There is a possibility, that it can be caused by some regression in sysvinit.

Lukáš,

Thanks for trying it.

I just made a new RHEL6.2 instance on Amazon EC2 and found out that squid is no longer a good example package, because its binaries have been made to be "not prelinkable".  If I run 'prelink -p' after /etc/cron.daily/prelink, that's what it says about /usr/sbin/squid.  I haven't found exactly why or when that change happened, but it appears it was probably made into a Position Independent Executable, most likely for security reasons.

Unfortunately, offhand I don't know another example application to demonstrate this problem, one that has a second process where arg0 is changed.  I can tell you how to simulate what prelink does to executables that are prelinkable, however.  You could do these steps as root:

yum install squid
/etc/init.d/squid start
/sbin/pidof /usr/sbin/squid  # prints 2 process ids
cp /usr/sbin/squid /usr/sbin/squid.copy
rm -f /usr/sbin/squid
mv /usr/sbin/squid.copy /usr/sbin/squid
/sbin/pidof /usr/sbin/squid  # doesn't print any process ids

I know that there was a regression in sysvinit, because when I compiled the current sysvinit on RHEL5, it exhibited the same problem until my patch was applied.  I tried copying a RHEL5 pidof binary to RHEL6 and it didn't work at all; it probably would need to be recompiled but I'm not yet convinced that it's worth the time to try that.

- Dave

In this example is the behavior of pidof same in rhel5 and rhel6. I am starting thinking, that this is not a bug but a feature, when I call pidof to concrete binary I want to know its pids and not for any other binary, even if it had the same name and was in the same path. 

Other question is calling pidof only with name of program ("pidof squid"), it seems that this in all cases return only one pid and it is not the one in .pid file.

I was surprised to find you're right that my test case in comment #5 causes the same behavior of pidof on rhel5 & rhel6.  pidof after prelink on rhel5, however, does still work even though it changes the inode & size of the binary.  The test case I gave you was bad.  Change it instead to eliminate the "rm -f /usr/sbin/squid" step.  Then on rhel5 it does the expected thing and prints both process ids.  The mv step then prompts to overwrite; just answer "y" or use mv -f to avoid the prompt.

I don't think the behavior I observed for pidof on rhel6 is a feature, it is a bug.  A big use for the pidof command is for /etc/init.d scripts to find out whether or not a copy of the same program is already running, and they need to know any process running with the the same path, not just the same binary file.

This exercise has now shown me what the real difference is between rhel5 and rhel6.  It isn't that pidof has regressed, it is just that it hasn't kept up with changes to the kernel.  With rhel6, doing a copy of a running binary and then overwriting the binary with mv -f causes the /proc/NNNN/exe symlink to have a "(deleted)" appended to the name of the destination.  That doesn't happen on rhel5 unless you do a rm -f of the running binary in between.  Pidof, without my patch, can't cope with that difference.

With this modification I can reproduce the difference, but I have tried this with more simple binary and result was same on rhel5 and 6:

[root@rhel5 x]# cat a.c 
#include <unistd.h>
int main()
{while (1) sleep(3600);}
[root@rhel5 x]# gcc a.c -o a
[root@rhel5 x]# ./a &
[1] 12159
[root@rhel5 x]# cp a b
[root@rhel5 x]# mv -f b a
[root@rhel5 x]# readlink /proc/12159/exe
/root/x/a (deleted)

I think that there is probably bug in rhel5 kernel and it's causing that the symlink stays same. I will discuss it with the kernel team.

About the usage of pidof in initscripts, you can use pidofproc from /etc/init.d/functions.

With your simple binary, the difference of whether or not the " (deleted)" shows up on rhel5 appears to be whether or not the filename you copy to has a single character.  I tried "b", "c", "A" which all showed " (deleted)" but "a.copy" or "a2" did not show " (deleted)".

- Dave

A patch for this has now been put into the HEAD of the upstream source, and I tested it on RHEL6.2 and it works.

https://savannah.nongnu.org/bugs/index.php?34992#comment7

Bug is still there, and clvmd process is affected.

Proposed patch:
--- a/src/killall5.c    2013-07-12 07:05:25.000000000 +0000
+++ b/src/killall5.c    2013-07-12 07:13:05.342450210 +0000
@@ -328,7 +328,12 @@
                if (readlink(path, p->pathname, PATH_MAX) == -1) {
                        p->pathname = NULL;
                } else {
+                       char *ptr = NULL;
                        p->pathname[PATH_MAX-1] = '\0';
+                       ptr = strstr(p->pathname, " (deleted)");
+                       if (ptr) {
+                               *ptr = '\0';
+                       }
                }
 
                /* Link it into the list. */

Vladislav,

In what version is the bug, and what version is your patch for?  It does not appear to match the current upstream HEAD at http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/killall5.c?root=sysvinit&view=log.

Dave

Dave,

That is for EL6's sysvinit-2.87.

======================================
Verified in version:
    sysvinit-tools-2.87-6.dsf.el6.i686
PASSED
======================================

# /root/aaa 3600 &
[4] 28006
# cp /root/aaa /root/bbb
# rm /root/aaa
rm: smazat běžný soubor „/root/aaa“? y
# mv /root/bbb /root/aaa
# pidof /root/aaa      # --->> there are pids ---> OK
28006 27829 27566
# rpm -Uvh sysvinit-tools-2.87-6.dsf.el6.i686.rpm 
Připravuji...              ########################################### [100%]
	balíček sysvinit-tools-2.87-6.dsf.el6.i686 je již nainstalován
# pidof /root/aaa      # --->> there are pids ---> OK    
28006 27829 27566
#

======================================
Reproduced in version:
    sysvinit-tools-2.87-5.dsf.el6.i686
FAIL
======================================

# /root/aaa 3600 &
[3] 27829
# cp /root/aaa /root/bbb
# rm /root/aaa
rm: smazat běžný soubor „/root/aaa“? y
# mv /root/bbb /root/aaa
# pidof /root/aaa      # --->> there are no pids ---> BAD
# rpm -Uvh /root/sysvinit-tools-2.87-5.dsf.el6.i686.rpm 
Připravuji...              ########################################### [100%]
	balíček sysvinit-tools-2.87-5.dsf.el6.i686 je již nainstalován
# pidof /root/aaa      # --->> there are no pids ---> BAD
#

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