pidof Stops Searching if Match Found by device/inode Pair.

Bug #200201 reported by Ralph Corderoy on 2008-03-09
Affects Status Importance Assigned to Milestone
sysvinit (Ubuntu)

Bug Description

Binary package hint: sysvutils

Ubuntu 7.10, /bin/pidof from 2.86.ds1-14.1ubuntu31 of sysvutils.

pidof first tries to search by device/inode pair. If that's succesful
it doesn't bother searching by other methods. This can result in it
sometimes listing all PIDs for the named process, regardless of the
user, and other times only listing those for $USER. Compare:

     1 $ ps xauww | grep turnip
     2 peter 30165 0.0 0.0 5028 668 pts/0 S 14:54 0:00 ./turniphead 19999
     3 ralph 30581 0.0 0.0 5036 672 pts/1 S+ 14:59 0:00 /tmp/turniphead 2999
     4 ralph 30611 0.0 0.0 5132 848 pts/0 S+ 14:59 0:00 grep turnip
     5 $ pidof turniphead
     6 30581 30165
     7 $ pidof /tmp/turniphead
     8 30581
     9 $ ls -l /proc/{30581,30165}/exe
    10 ls: cannot read symbolic link /proc/30165/exe: Permission denied
    11 lrwxrwxrwx 1 peter peter 0 2008-03-09 14:59 /proc/30165/exe
    12 lrwxrwxrwx 1 ralph ralph 0 2008-03-09 14:59 /proc/30581/exe -> /tmp/turniphead

#6 is the result of searching by name in /proc/$pid/stat. However,
pidof(1) suggests invoking pidof "with a full pathname to the program"
is better but that only gives #8 because PID 30165 is owned by a
different user so /proc/30165/exe is unreadable.

Either pidof needs to search in multiple ways to come up with all
answers, or the man page should detail the search strategy and pitfalls,
or command line options should allow the "all" method of searching.
Having #6 and #8 differ when #5 and #7 are both specifying the same
executable is not obvious.

Shimi Chen (shimi-chen) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 200201 and any other logs that are relevant for this particular issue.

Changed in sysvinit (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for sysvinit (Ubuntu) because there has been no activity for 60 days.]

Changed in sysvinit (Ubuntu):
status: Incomplete → Expired

I've checked sysvinit_2.88dsf-13.10ubuntu4 from 11.10 and it looks to me as if the code hasn't changed and the documentation hasn't improved so the problem remains. 12.04 has the same package version.

Changed in sysvinit (Ubuntu):
status: Expired → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers