Solved pkill kills processes by arguments

[laufdi]

even when called without the -f switch. Same for pgrep. 'pkill firefox' kills all python processes that have firefoxin the argument list as part of a path. Why?

... an effect of python called by a shell script with arguments?
... correction: pgrep does not list it, but pkill kills it.

(Reinstalled from source minutes ago
FreeBSD 15.1-STABLE stable/15-n285467-3d961305e170 GENERIC amd64)

 

[covacat]

i can't replicate it
also pkill and pgrep are the same binary
FreeBSD instance-20260827-1504 15.1-RELEASE-p4 FreeBSD 15.1-RELEASE-p4 releng/15.1-n283627-db6066678b33 GENERIC arm64

 

[laufdi]

It also 'works' for other arguments of that python command ... and for other running python processes, too. And shprocesses.
The args are not exactly handled the same in /usr/src/bin/pkill/pkill.c

 

[covacat]

$ ls -li /bin/pkill /bin/pgrep
120052 -r-xr-xr-x 2 root wheel 18080 Sep 29 01:59 /bin/pgrep
120052 -r-xr-xr-x 2 root wheel 18080 Sep 29 01:59 /bin/pkill
do you have a mismatched version between kernel and userland ?

 

[SirDice]

kills all python processes that have firefoxin the argument list as part of a path. Why?

Is it possible those scripts aren't killed but crash when their connection to firefox is broken because firefox got killed?

 

[laufdi]

What's going on here? /bin/pkill is different from /bin/pkill?

# /bin/pkill -I movi
# pkill -I movi
kill -15 96367]
kill 96367 python3.12? n
# which pkill
/bin/pkill
#  ls -li /bin/pkill /bin/pgrep
561684 -r-xr-xr-x  2 root wheel 17696  1 Okt. 14:41 /bin/pgrep*
561684 -r-xr-xr-x  2 root wheel 17696  1 Okt. 14:41 /bin/pkill*

... it only happens when called from bash, not sh!

 

[covacat]

have a bash alias for pkill ?

 

[laufdi]

Yes just found the stupid alias.

I miss the "Stupid" thread prefix

 

[bob2112]

even when called without the -f switch. Same for pgrep. 'pkill firefox' kills all python processes that have firefoxin the argument list as part of a path. Why?

IIRC pkill/pgrep works with extended regular expressions - you need to anchor the match if you want to avoid a sub-string match on arguments.

 

[Eric A. Borisch]

Can you mark the thread “solved”?

 

[SirDice]

I miss the "Stupid" thread prefix

Besides a "SOLVED", do I need to add PEBKAC or PICNIC?

 

[covacat]

from https://wwwth.mpp.mpg.de/members/hahn/humour/FieldGuideToAdministrators.html

 

[mer]

Interesting that "which pkill" did not the alias.
Maybe it doesn't on other shells, but tcsh tells me if something is aliased.

 

[Eric A. Borisch]

Related, in terms of determining what you are getting with a command in bash:

Checking builtin(1), sh doesn't have a builtin which:

  Command       Standalone    csh(1)    sh(1)
[..]
  which         Yes           Yes       No

Bash also doesn't have a builtin which, so it doesn't know about aliases:

[FreeBSD ~]$ which pkill
/bin/pkill
[FreeBSD ~]$ alias pkill='pkill -f'
[FreeBSD ~]$ which pkill
/bin/pkill

(Spot-checking linux, the which command can get set to a function that feeds in some information from the environment, so it can detect aliases, but it looks like it relies on options which FreeBSD's which doesn't have.)

You can use command -V <cmd> (described in 'SHELL BUILTIN COMMANDS' in bash(1)) to get more useful information:

[FreeBSD ~]$ which which
/usr/bin/which
[FreeBSD ~]$ command -V which
which is hashed (/usr/bin/which)
[FreeBSD ~]$ which pgrep
/bin/pgrep
[FreeBSD ~]$ alias pgrep='pgrep -f'
[FreeBSD ~]$ which pgrep
/bin/pgrep
[FreeBSD ~]$ command -V pgrep
pgrep is aliased to `pgrep -f'