Red Hat Bugzilla – Bug 214214
killall <path> misbehavior (prelink, etc)
Last modified: 2007-11-30 17:11:47 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 comparison.
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 fixed? 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?
- 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.
I've sent info about the problem to upstream maintainer. We'll see..
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.
Fixed. Update to psmisc-22.3-2.fc7.
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.