> On Fri, 29 May 2020 at 09:21, Frank Heckenbach <f.heckenb...@fh-soft.de> 
> wrote:
> > killall fails to kill processes with names longer than 15
> > characters.
> Actually it does. But the comm length has increased for some kernels.
> 
> If you're asking it to kill something with another name because the
> comm is "killall-bug-wit" not "killall-bug-with-long-names" it used to
> work even though the command is wrong because it just cut the extra
> characters off. This won't work when the comm length is increased.

Don't know what you mean by "the command is wrong" (I gave the full
name), and honestly I don't (and shouldn't have to) care about comm
length etc.

Fact is, it doesn't match the documented behaviour (in its own man
page!). It used to do so before. So it's clearly a regression.

Again, as I quoted, the man page says:

:   -e, --exact
:          Require an exact match for very long names.  If a command
:          name is longer than 15 characters, the full name may be
:          unavailable (i.e.  it is swapped  out). In  this case,
:          killall will kill everything that matches within the first
:          15 characters.  With -e, such entries are skipped.  [...]

So logically, there are two possibilities (without "-e"):

- The full name is available, in which case it should work since I
  gave the full name.

- The full name is not available, in which case it should also work
  since the first 15 characters match.

> $ ps -o comm 1739632
> COMMAND
> killall-bug-wit
> $ killall killall-bug-wit

I know that's a workaround. But as I wrote:

: I think that's at least "serious", because it makes killall by name
: basically unusable, at least in automated contexts, unless you want
: to replace:
:
:   killall "$x"
:
: everywhere with some beast such as (untested):
:
:   killall "$(echo "$x" | cut -c-15)"

The duplicate report you mention below also calls that problematic
"so I don't have to count letters when I'm typing into my shell, and
can write shellscripts that work regardless of what the kernel limit
is."

> However 23.3 has a work-around where if the comm length is exactly 15
> characters then it matches on this too.
> This is a duplicate of bug #912748 and fixed in psmisc 23.3-1

Then please provide a backport for buster (possibly even as a
security fix, as I explained).

Debian developers tend to forget that stable is the
release Debian itself recommends to use (see
https://www.debian.org/releases/index.en.html),
so if you leave such a serious bug unfixed, I guarantee
you'll get more duplicate reports!

Frank

Reply via email to