Bug 625 - procps_scan() incorrect behaviour
Summary: procps_scan() incorrect behaviour
Status: RESOLVED FIXED
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.15.x
Hardware: Other Linux
: P1 major
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-22 18:27 UTC by Leonid
Modified: 2009-10-08 00:11 UTC (History)
1 user (show)

See Also:
Host:
Target: linux-mips
Build: 1.15.1

Attachments
This patch solves problem for me (834 bytes, patch)
2009-09-22 18:27 UTC, Leonid 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Leonid 2009-09-22 18:27:11 UTC 
Created attachment 667 [details]
This patch solves problem for me

In case of call procps_scan() function with mask PSSCAN_PID|PSSCAN_COMM|PSSCAN_ARGVN|PSSCAN_EXE as in find_pid_by_name() and some process has empty /proc/<pid>/cmdline (kernel daemon for example), it leaves previous results for sp->exe!
As result, find_pid_by_name() used in killall applet can give us wrong additional pids!

Sample part of real ps output:
...
   68 nobody     800 S    dnsmasq
   69 admin        0 SW   [khubd]
   83 admin      964 S    l2tpd
...

killall -1 dnsmasq tries to send SIGHUP to both 68 & 69 pids !

Patch attached, solves problem for me.
Comment 1 Denys Vlasenko 2009-09-22 21:03:17 UTC 
Reproduced.

Try this patch:

http://busybox.net/downloads/fixes-1.15.1/busybox-1.15.1-pidof_killall.patch
Comment 2 Leonid 2009-09-23 15:57:59 UTC 
Your variant of fix works well too, thanks.