Re: killall behaviour
On Friday 05 September 2014 18:22, Harald Becker wrote: Hi Denys ! Unfortunately, there is no commonly agreed definition of program named FOO. ... but standard usage cases should be acted on correct: Think of: ln -s /bin/Busybox ntpd ln -s /bin/Busybox syslogd ln -s /bin/Busybox klogd ntpd ... syslogd ... klogd ... Busybox killall ntpd ... will not only kill ntpd, but also syslogd and klogd ... do you think anyone expect this? No, it won't. Try it. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Denys ! killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. ... but here we start a program by different name, just pointing to same executable, when you do a killall nobody expects to kill other instances of the same executable, when called with a different name. May be this /proc/self/exe is a special case, which shall only trigger the test on /proc/PID/exe when the comm field contains exe, else you highly risk killing the wrong processes. As you can see the comm fields contains the expected values, and would select the right processes here. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
On Fri, Sep 5, 2014 at 1:21 PM, Harald Becker ra...@gmx.de wrote: killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. ... but here we start a program by different name, just pointing to same executable, when you do a killall nobody expects to kill other instances of the same executable, when called with a different name. Unfortunately, there is no commonly agreed definition of program named FOO. If it is the same executable, is it the same program? You can about as easily argue that killing by looking at basename(argv[0]) is wrong, because argv[0] can be anything: execve(/bin/foo, [ha ha you lose, ... ]). You can also easily argue that killing by looking at comm is wrong too, because comm is truncated to 15 chars, and is settable by a prctl. So, the proper solution, which never kills wrong processes, is killall should kill no processes. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Denys ! Unfortunately, there is no commonly agreed definition of program named FOO. ... but standard usage cases should be acted on correct: Think of: ln -s /bin/Busybox ntpd ln -s /bin/Busybox syslogd ln -s /bin/Busybox klogd ntpd ... syslogd ... klogd ... Busybox killall ntpd ... will not only kill ntpd, but also syslogd and klogd ... do you think anyone expect this? So, the proper solution, which never kills wrong processes, is killall should kill no processes. Where is your upstream compatibility here??? ... this is not a corner case problem! -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
On Fri, Aug 29, 2014 at 7:01 PM, Harald Becker ra...@gmx.de wrote: This is suspicious. killall shall not kill both processes ... ./foobar cat /proc/19618/comm foobar cat /proc/19618/cmdline ./foobar cat /proc/19618/status Name: foobar ./hello cat /proc/19669/comm hello cat /proc/19669/cmdline ./hello cat /proc/19669/status Name: hello The names are different, so I can't see why killall foobar shall kill this hello. Looks like we have to investigate this further. killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. See find_pid_by_name.c: /* In Linux we have three ways to determine process name: 1. /proc/PID/stat has ...(name)..., among other things. It's so-called comm field. 2. /proc/PID/cmdline's first NUL-terminated string. It's argv[0] from exec syscall. 3. /proc/PID/exe symlink. Points to the running executable file. kernel threads: comm: thread name cmdline: empty exe: readlink fails executable comm: first 15 chars of base name (if executable is a symlink, then first 15 chars of symlink name are used) cmdline: argv[0] from exec syscall exe: points to executable (resolves symlink, unlike comm) script (an executable with #!/path/to/interpreter): comm: first 15 chars of script's base name (symlinks are not resolved) cmdline: /path/to/interpreter (symlinks are not resolved) (script name is in argv[1], args are pushed into argv[2] etc) exe: points to interpreter's executable (symlinks are resolved) If FEATURE_PREFER_APPLETS=y (and more so if FEATURE_SH_STANDALONE=y), some commands started from busybox shell, xargs or find are started by execXXX(/proc/self/exe, applet_name, params) and therefore comm field contains exe. */ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
killall behaviour
Busybox git. If I do ln -s foobar hello ./foobar ./hello killall foobar also hello is killed Is it a normal behaviour? Thanks in advance. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! ./foobar ./hello killall foobar also hello is killed Did you verify that hello exited due to a signal from killall? When a process exits the shell does not always display the information immediately. Before display of next command prompt all job processes which exited are then displayed. This way it may look a process exited due to killall, but it has in fact exited due to some other reason. Please verify this, before we are looking for a bug. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! ln -s foobar hello I overlooked this. Sorry! ./foobar ./hello This way you indeed start the same application twice. Especially if they are shell scripts or something similar, it is very hard to distinguish with which name they got started. See what ps or top say for those two jobs. In addition try using hard links: ln foobar hello -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
On Fri, Aug 29, 2014 at 05:05 PM, Harald Becker said: Did you verify that hello exited due to a signal from killall? I can replicate the problem here with busybox killall but not with the standard (Gnu?) killall. My busybox killall lives in /live/bin. $ ln -s /bin/sleep hello $ sleep 100 [1] 3934384 $ ./hello 100 [2] 3934423 $ killall sleep [1] - terminated sleep 100 $ pgrep -l hello 3934423 hello $ killall hello [2] + terminated ./hello 100 $ sleep 100 [1] 3934947 $ ./hello 100 [2] 3934960 $ /live/bin/killall sleep [1] - terminated sleep 100 [2] + terminated ./hello 100 HTH. Peace, James ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Il 29/08/2014 17:18, Harald Becker ha scritto: Hi Alfonso ! ln -s foobar hello I overlooked this. Sorry! ./foobar ./hello This way you indeed start the same application twice. Especially if they are shell scripts or something similar, it is very hard to distinguish with which name they got started. See what ps or top say for those two jobs. In addition try using hard links: ln foobar hello -- Harald The question starts from the fact that in the linux box where killall is from psmisc-22.20, if I do (foobar is just a pause() in main) ./foobar ./hello killall foobar hello is not killed ... ./foobar busybox killall foobar hello is killed I just wanted to know if it is a will or just happens in find_pid_by_name. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! See what ps or top say for those two jobs. You did not give the information from my question. busybox killall foobar My Busybox killed foobar, not hello ... just tested! So you indeed need to look for more detail, what is listed for the two active processes. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Il 29/08/2014 17:39, Harald Becker ha scritto:
Hi Alfonso !
See what ps or top say for those two jobs.
You did not give the information from my question.
busybox killall foobar
My Busybox killed foobar, not hello ... just tested!
So you indeed need to look for more detail, what is listed for the two
active processes.
--
Harald
funtoo box amd64: BusyBox v1.21.1 (2014-05-09 11:02:02 CEST)
router mips uClibc: BusyBox v1.23.0.git (2014-08-20 11:24:12 CEST)
foobar.c
#include stdio.h
int main(int argc,char **argv)
{
pause();
return 0;
}
gcc -o foobar foobar.c
ls -s foobar hello
./foobar
./hello
busybox ps | grep [f]oobar
19446 root 0:00 ./foobar
busybox ps | grep [h]ello
19447 root 0:00 ./hello
killall foobar
busybox ps | grep [f]oobar
(nothing)
busybox ps | grep [h]ello
19447 root 0:00 ./hello
./foobar
busybox ps | grep [f]oobar
19474 root 0:00 ./foobar
busybox killall foobar
[5]- Terminato ./hello
[6]+ Terminato ./foobar
(Terminati is killed)
busybox ps | grep [f]oobar
(nothing)
busybox ps | grep [h]ello
(nothing)
The exact sane thing happens on the router.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! I just wanted to know if it is a will or just happens in find_pid_by_name. The manpage says, killall shall send the signal to all processes running the command. In fact is, you run the same command twice, when you do this symlinking. As different kernel versions provide different information about the running processes, it may be hard to dettermine, which job you want to kill. Please don't misunderstand. I do not say, there is no problem with Busybox. The problem is, you need to give full information, to let us look what's possibly going wrong. Your question is incomplete to give a concrete answer. That is: - your Busybox version - your Kernel version - underlying file system you stored the files - exact list what information your kernel provides for the two processes (see under /pro/PID_NUMBER/comm cmdline status) - what is shown for the processes in ps and top -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! I looked in the source for Busybox killall. It compares the value of the comm field to determine which command is running. So give the /proc field values for comm, cmdline and status of your processes, please. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Il 29/08/2014 18:17, Harald Becker ha scritto: Hi Alfonso ! I looked in the source for Busybox killall. It compares the value of the comm field to determine which command is running. So give the /proc field values for comm, cmdline and status of your processes, please. -- Harald On funtoo: ./foobar busybox ps | grep [f]oobar 19618 root 0:00 ./foobar cat /proc/19618/comm foobar cat /proc/19618/cmdline ./foobar cat /proc/19618/status Name: foobar State: S (sleeping) Tgid: 19618 Pid:19618 PPid: 2156 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 11 26 27 VmPeak: 4312 kB VmSize: 4084 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 344 kB VmRSS: 344 kB VmData: 40 kB VmStk: 140 kB VmExe: 4 kB VmLib: 1816 kB VmPTE:28 kB VmSwap:0 kB Threads:1 SigQ: 0/63463 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: 001f CapEff: 001f CapBnd: 001f Seccomp:0 Cpus_allowed: ff Cpus_allowed_list: 0-7 Mems_allowed: ,0001 Mems_allowed_list: 0 voluntary_ctxt_switches:1 nonvoluntary_ctxt_switches: 3 ./hello busybox ps | grep [h]ello 19669 root 0:00 ./hello cat /proc/19669/comm hello cat /proc/19669/cmdline ./hello cat /proc/19669/status Name: hello State: S (sleeping) Tgid: 19669 Pid:19669 PPid: 2156 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 11 26 27 VmPeak: 4312 kB VmSize: 4084 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 344 kB VmRSS: 344 kB VmData: 40 kB VmStk: 140 kB VmExe: 4 kB VmLib: 1816 kB VmPTE:28 kB VmSwap:0 kB Threads:1 SigQ: 0/63463 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: 001f CapEff: 001f CapBnd: 001f Seccomp:0 Cpus_allowed: ff Cpus_allowed_list: 0-7 Mems_allowed: ,0001 Mems_allowed_list: 0 voluntary_ctxt_switches:2 nonvoluntary_ctxt_switches: 2 --- On the mips router: there is no comm entry in /proc/XYZ ps | grep [f]oobar 1835 root 0:00 ./foobar cat /proc/1835/cmdline ./foobar cat /proc/1835/status Name: foobar State: S (sleeping) SleepAVG: 88% Tgid: 1835 Pid:1835 PPid: 1381 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 1300 kB VmSize: 1300 kB VmLck: 0 kB VmHWM: 228 kB VmRSS: 228 kB VmData: 536 kB VmStk:84 kB VmExe: 4 kB VmLib: 652 kB VmPTE:16 kB Threads:1 SigQ: 0/512 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: feff CapEff: feff ps | grep [h]ello 1852 root 0:00 ./hello cat /proc/1852/cmdline ./hello cat /proc/1852/status Name: hello State: S (sleeping) SleepAVG: 88% Tgid: 1852 Pid:1852 PPid: 1381 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 1300 kB VmSize: 1300 kB VmLck: 0 kB VmHWM: 228 kB VmRSS: 228 kB VmData: 536 kB VmStk:84 kB VmExe: 4 kB VmLib: 652 kB VmPTE:16 kB Threads:1 SigQ: 0/512 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: feff CapEff: feff ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Alfonso ! Hi Denys ! This is suspicious. killall shall not kill both processes ... ./foobar cat /proc/19618/comm foobar cat /proc/19618/cmdline ./foobar cat /proc/19618/status Name: foobar ./hello cat /proc/19669/comm hello cat /proc/19669/cmdline ./hello cat /proc/19669/status Name: hello The names are different, so I can't see why killall foobar shall kill this hello. Looks like we have to investigate this further. Alfonso: Can you try this when ... a) ... you do ln foobar hello2 (hardlink) b) ... you do cp -p foobar hello3 (physical copy) Denys: This really looks like a bug (summary of thread): ls -s foobar hello (symlink!) foobar hello busybox killall foobar - kills foobar hello !!! gnu killall kills only foobar values of corresponding name values in /proc see top of mail. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Il 29/08/2014 19:01, Harald Becker ha scritto: Alfonso: Can you try this when ... a) ... you do ln foobar hello2 (hardlink) b) ... you do cp -p foobar hello3 (physical copy) In case of a hard link or a copy, hello is not killed when foobar is killed. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
