Bug 1216395

What exactly does "/some/folder/X" mean?  I only have /usr/bin/X on Leap or an /usr/bin/Xorg.bin on Tumbleweed around both owned by root means only root can terminate with killall those processes.    And do you use Xwayland ... means no running X process

On the Leap I see

 /suse/werner> pidof X
 1582

On the Tumbleweed I see

 /suse/werner> pidof Xorg.bin
 1591

I used root for the examples, it also wasn't a permission error anyway. One process that reliably is NOT killable is /usr/lib/packagekitd for example, that always gives me "packagekitd: no process found" for: "sudo killall packagekitd"  This happens even though the process is running before and after with same PID, so it doesn't seem to be a case of it just restarting immediately.

(Additional note: and "sudo killall /usr/lib/packagekitd" works just fine, but I've never seen the full path being required like that on any other distribution)

I can not reproduce this ... the only tools which check for the path of a running binary are pidofproc and killproc from package sysvinit-tools and
those behave as by design aka written by my self 20 years back.

The only way to request killall to use the full name is the option -e or
--exact ... but limit to 15 characters (the size of binary name

... please check if killall is really the binary of package psmisc

  ls -l /usr/bin/killall
  rpm -qf /usr/bin/killall
  rpm -qV psmisc

and not an alias

  type -a killall

... also you might use

 killall -v X

Just on a fresh VM of Tumbleweed:

 localhost:~/Desktop # /bin/sleep 10000 &
 [1] 3463
 localhost:~/Desktop # killall sleep
 [1]+  Terminated              /bin/sleep 10000

Just curious .. any news ... maybe an attached strace like

   strace -o killall.trace -s 256 killall X

Killall really seems super broken:

$ ps aux | grep vim
user    20953  0.2  0.0  20160 11264 pts/0    Sl+  16:28   0:02 vim src/game_interpreter_map.cpp
user    21717  0.0  0.0   6544  2176 pts/1    S+   16:44   0:00 grep --color=auto vim
$ killall vim
vim: no process found
$ ps aux | grep vim
user    20953  0.2  0.0  20160 11264 pts/0    Sl+  16:28   0:02 vim src/game_interpreter_map.cpp
user    21723  0.0  0.0   6544  2176 pts/1    S+   16:44   0:00 grep --color=auto vim

I don't know how exactly it's supposed to work in all corner cases, but this just doesn't seem right.

Created attachment 870943 [details]
killall strace output for "killall vim"

Okay, so I tested: /usr/bin/killall --help gives the same output as killall --help in a terminal. I'm using GNOME 3 without changes, so I think it's using Wayland/XWayland. Here is the output of the rpm commands:

$ ls -l /usr/bin/killall
-rwxr-xr-x 1 root root 31904 Oct 24 20:13 /usr/bin/killall
$   rpm -qf /usr/bin/killall
psmisc-23.6-4.1.x86_64
$   rpm -qV psmisc
$ 

I attached the strace you asked for. It seems like it does see vim in the listing but as vim-x11, but the "ps" listing and also the actual launch command clearly was "vim" which it therefore would be expected to match on I think, right? Since it's listed like that. Maybe I just don't understand killall well enough but I assume all other distributions I used had similar name redirections but I never had any issue terminating things there.

Created attachment 870959 [details]
killall.png

First of all the name of the process might or might not be the name of basename of the executable its self.  That is not a bug but a feature.  Newer vim installation provides vim-x11 and vim-nox11.  Beside this every process can rewrite argv** ioncluding argv[0] aka the process name.

Means killall is searching for 'vim' but there is 'vim-x11' or 'vim-nox11'
or killall is searching for 'X' but there is only 'Xwayland' or 'Xorg'.

Now with Leap 15.5 a newer vim also used in Tumbleweed will be installed.

If you want to be sure what process you want to kill you should use its pid
from the process table.

About what distributions you are referring?  Compare the version of vim,
as well as the version of psmisc. With Leap 15.5 we have vim-7.3 and psmisc-23.0.  With this you get vim-nox11 or vim-x11 an a killall which does
not take the first best similar match but exact match.

You might use the regular expression of killall to catch processes like vim-x11 and Xwayland ... but be carefull.  

IMHO this is not a bug but a feature. OK unaccustomed and new but this is how it is.

This is how arguments including process name works:

https://stackoverflow.com/questions/2654960/changing-command-line-arguments

similar can be done with the system call execve(2) e.g. used by the bash
builtin exec with its option -a ... from manual page of the bash:

 If -a is supplied, the shell passes name as the zeroth argument
 to  the  executed  command.

Means names in the process table are not unique.


(In reply to ell1e from comment #8)
> Created attachment 870943 [details]
> killall strace output for "killall vim"


This is found by killall:

read(4, "20953 (vim-nox11) S 20913 20953 20913 34816 20953 4194304 9647 0 8 0 217 42 0 0 20 0 2 0 22351588 20643840 2720 18446744073709551615 94353454247936 94353457460433 140721427708640 0 0 0 0 12288 1837780735 0 0 0 17 1 0 0 0 0 0 94353458058832 94353458336305 9"..., 1024) = 336

> 
> Okay, so I tested: /usr/bin/killall --help gives the same output as killall
> --help in a terminal. I'm using GNOME 3 without changes, so I think it's
> using Wayland/XWayland. Here is the output of the rpm commands:
> 
> $ ls -l /usr/bin/killall
> -rwxr-xr-x 1 root root 31904 Oct 24 20:13 /usr/bin/killall
> $   rpm -qf /usr/bin/killall
> psmisc-23.6-4.1.x86_64
> $   rpm -qV psmisc
> $ 
> 
> I attached the strace you asked for. It seems like it does see vim in the
> listing but as vim-x11, but the "ps" listing and also the actual launch
> command clearly was "vim" which it therefore would be expected to match on I
> think, right? Since it's listed like that. Maybe I just don't understand
> killall well enough but I assume all other distributions I used had similar
> name redirections but I never had any issue terminating things there.

I'd like to close this bug as WORKSFORME

I'd like to propose the problem is with alternatives: it seems like vim is packaged as a symlink, that ultimatively goes through the update-alternatives thing and then to vim-nox11. But somehow, NOT through a symlink doing the final resolution, and this is what breaks killall.

And the thing is, if I just do a symlink myself directly to vim-nox11 then killall works:

$ ln -s /usr/bin/vim-nox11 ./bla
$ ./bla

In other terminal:

$ killall bla
$

Works!

So this is the reason, no other distro somehow launches things in a way that is with such a disconnected different name without using a symlink or some mechanism that doesn't break this chain that keeps the original launch command in the process meta data. (I wouldn't understand the exact details of it.)

Also, I'm still wondering why with packagekitd it also doesn't work. Maybe a similar reason, though.

Please do not touch packagekitd as it is a dbus based system controlled by systemd

Sadly, when trying to use zipper packagekitd will not reliably quit on its own when KDE discover or gnome software is running. Please note I'm only sending a SIGTERM.

Nevertheless, I'm still baffled that "killall packagekitd" for /usr/libexec/packagekitd doesn't work. I've also tested it on wine programs running with usually variant of /a/b/c/test.exe and then killall test.exe doesn't work either, for some reason.

While for vim it seems to be update-alternatives being the culprit, it doesn't look like that's the case for these other instances.