Bug 214214 - killall <path> misbehavior (prelink, etc)
killall <path> misbehavior (prelink, etc)
Product: Fedora
Classification: Fedora
Component: psmisc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Depends On:
  Show dependency treegraph
Reported: 2006-11-06 11:51 EST by Owen Taylor
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-02 07:46:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Owen Taylor 2006-11-06 11:51:39 EST
When you pass a name containing a slash to killall, it interprets it
as a path and the algorithm that it uses is to stat stat <path> then walk 
over the /proc/<pid>/exe and stat those entries and compare device/inode.

That doesn't work if since the process was started, the file at <path> has 
been replaced. This includes the case where prelink has been run
on the file at <path>.

I noticed this on my system because gconftool-2 does 
'killall -q -TERM /usr/libexec/gconfd-2' after installing a new schema
file, but gconfd-2 had been prelinked since the process had been started.

I think it would be better to readlink /proc/<pid>/exe and compare the
result textually to the argument passed in. Or possibly, if hardlinks 
are a concern, to do both a comparison of device/inode and a textual 
Comment 1 David Eisenstein 2007-01-07 06:35:31 EST
I would be curious to know if this is a bug or a feature of killall?  Why
was the code in killall to do this stuff implemented?  Does upstream have
an opinion on this?  :)

Also, would this also affect FC5, if it were determined this was a bug to be

It looks like a related bug (Bug #173869 comment 14) was fixed by removing the
slashes from the killall command.  Is it better to do it that way?
Comment 2 Owen Taylor 2007-01-07 09:32:48 EST
- The principle of least suprise says that this is a bug. 
    Should killall /path/to/executable kill a program if 'executable' has
      been prelinked since the program was restarted?
    Should killall /path/to/executable kill a program if 'executable' has
      been replaced since the program was restarted?
  It would be very surprising to me if the answer for either of those was "no".
And if you added documentation of that to the man page, the man page would end
up essentially saying "Never use killall with an absolute path".  I would not be
surprised if there are multiple places throughout the distribution where this
bug is triggered, causing unexpected unreliability that hasn't been tracked down.

- I haven't checked with upstream and have no contacts there; I don't even know
what upstream is for psmisc. After tracking down this program, I simply wanted
to make sure that it was recorded so it woul d hopefully be fixed, rather than
wasting another hour of my time in a few years. But certainly reporting this bug
upstream is needed at some point.

- My suspicion is that the person who wrote the code thought that doing it via
inodes would be faster and more reliably. Sadly, it doesn't fully work.

- This bug probably also affects FC5 (though I haven't checked), but I doubt it
would be worth backporting a fix to this to FC5.

- You can work around this bug by not passing a full absolute path to killall.
But the only reason that that is "better" is because of this bug.
Comment 3 Karel Zak 2007-03-14 17:18:15 EDT
I've sent info about the problem to upstream maintainer. We'll see..
Comment 4 Karel Zak 2007-03-15 10:53:05 EDT
Feedback from Craig Small (upstream):

  I would say that killalls behaviour is like the way it is because when
  it was written prelink and other things like that were not very common.

  Using something like readlink() would appear to make more sense, after
  all the user is specifying processes by path which is exactly what
  readlink will do.

I'll fix the problem in next weeks.
Comment 5 Karel Zak 2007-04-02 07:42:28 EDT
Fixed. Update to psmisc-22.3-2.fc7.
Comment 6 Fedora Update System 2007-04-02 12:23:35 EDT
psmisc-22.2-5.1 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

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