1 month into the bug, still there

Tried the mentioned reproducer on fresh F31 with psmisc-23.3-2.fc31.x86_64 and everything behaved correctly.

Can you please try 'killall -v firefox' (verbose) to see the behaviour of your case?
Does this happen always? After restart? After reinstall of psmisc?

Thanks in advance.

Always:

[user@pc ~]$ killall -v firefox
firefox: Kein Prozess gefunden
[user@pc ~]$ ps auf|grep firefox
user     12364  0.0  0.0 112452   840 pts/1    S+   15:21   0:00  \_ grep --color=auto firefox
user      5115  1.4  3.0 3229088 492536 tty2   Sl+  09:27   4:57 /usr/lib64/firefox/firefox https://community.letsencrypt.org/t/unauthorized-invalid-response-from-domain-well-known-acme-challenge-etc/133606
user      5227  0.0  0.9 2573692 162392 tty2   Sl+  09:27   0:15  \_ /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user      5391  0.0  0.8 2715292 141664 tty2   Sl+  09:27   0:14  \_ /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 6412 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user      5434  3.5  0.9 2585316 160604 tty2   Sl+  09:27  12:39  \_ /usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 7405 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user      5553  2.6  1.1 2609632 187724 tty2   Sl+  09:28   9:12  \_ /usr/lib64/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 7405 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user      6510  0.0  0.8 2546440 137908 tty2   Sl+  10:06   0:15  \_ /usr/lib64/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 7782 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user      7268  0.6  1.0 2887232 175728 tty2   Sl+  10:33   1:54  \_ /usr/lib64/firefox/firefox -contentproc -childID 10 -isForBrowser -prefsLen 7782 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
user     11983  0.0  0.4 2488080 77488 tty2    Sl+  15:14   0:00  \_ /usr/lib64/firefox/firefox -contentproc -childID 12 -isForBrowser -prefsLen 7782 -prefMapSize 264266 -parentBuildID 20200825080044 -appdir /usr/lib64/firefox/browser 5115 true tab
[user@pc ~]$ 

Trying to reinstall

....
Reinstalliert:
  psmisc-23.3-2.fc31.x86_64                                                                                                                                                                                                                                                     

Fertig.
[user@pc ~]$ killall -v firefox
firefox: Kein Prozess gefunden

Surprisingly this worked:

$ killall -v /usr/lib64/firefox/firefox
MainThread(5115) mit Signal 15 beendet
Web Content(5227) mit Signal 15 beendet
WebExtensions(5391) mit Signal 15 beendet
Web Content(5434) mit Signal 15 beendet
Web Content(5553) mit Signal 15 beendet
Web Content(6510) mit Signal 15 beendet
Web Content(7268) mit Signal 15 beendet
Web Content(11983) mit Signal 15 beendet
Web Content(12408) mit Signal 15 beendet

1) Is it doing this only in case of firefox?

2) Have you tried it with SELinux on/off?

3) What's the output of the following?
$ ls -la `which firefox`
$ ls -la /usr/lib64/firefox/firefox

4) I'm now just boiling out of water, since I have no reproducer to stick to.

5) Do you happen to have hidepid activated on /proc?

In the meantime you can use 'pkill' instead (if it works and is not hindered by the same issue as killall)

1) "Yes" to the point, that i killall other processes, but not all available have been tested. 

user     48146  5.7  0.3 574148 57060 tty2     Sl+  14:44   0:00  \_ eog /home/user/Sven-Unser Netzwerk geht nicht.jpg
[user@pc ~]$ killall eog
[user@pc ~]$ 

* Worked *  But it's still possible, that the killall fail is limited to firefox.

2) in short: no change

[user@pc ~]$ getenforce 
Enforcing
[user@pc ~]$ sudo setenforce 0
[sudo] Passwort für user: 
[user@pc ~]$ getenforce 
Permissive
[user@pc ~]$ killall -v firefox
firefox: Kein Prozess gefunden
[user@pc ~]$ sudo setenforce 1
[user@pc ~]$ getenforce 
Enforcing
[user@pc ~]$ killall -v firefox
firefox: Kein Prozess gefunden

3)


[user@pc ~]$ ls -la `which firefox`
-rwxr-xr-x. 1 root root 7113 25. Aug 11:50 /usr/bin/firefox
[user@pc ~]$ which firefox
/usr/bin/firefox
[user@pc ~]$ ls -la /usr/lib64/firefox/firefox
-rwxr-xr-x. 1 root root 605312 25. Aug 12:12 /usr/lib64/firefox/firefox
[user@pc ~]$ rpm -qf /usr/bin/firefox /usr/lib64/firefox/firefox
firefox-80.0-1.fc31.x86_64
firefox-80.0-1.fc31.x86_64

4) 

Is there any debug we can add to killall or pkill/pgrep to bring some light to it?  

Besides, the reason for it it, will be the change last year which seems to be improper done. There is a BZ entry about it.


5)  same result.. 

[user@pc ~]$ man pkill
[user@pc ~]$ pkill firefox
[user@pc ~]$ pkill ".*firefox.*"
[user@pc ~]$ 

no noticeable result for the last one. Invoked as "pgrep", it doesn't find it either.

##
## Back to the drawing board 
## 

a) killall does not find "it" by the processname, but it finds it by the full path. 
b) there has been a change in the package last year, which resulted in a lot of similar bugs.


user     19978  2.8  3.4 3652732 564360 tty2   Sl+  09:21   9:17 /usr/lib64/firefox/firefox https://www.linux-bibel-oesterreich.at/2020/09/20/rssfs-newsreader-als-dateisystem/

Conclusion: 

There are two possibilities here: 

a) the procname is no longer the shortname, but now the fullpath in general. 

This can be ruled out by the above eog-testcase. 

b) the way firefox is started, results in the full path+filename to be the processname

this is suggested by the "ps auxf" line above and this one:

user     48359 30.5  0.6 823924 107280 tty2    Sl+  14:55   0:01  \_ eog /home/user/Bilder/Bildschirmfoto vom 2020-09-06 15-02-15.png

but, as you can't reproduce it, this must be specific or a great coincident with some other bug.


Lets rule out more:

Firefox is usually started via a keyboard-shortcut ( SUPER+F ) calling "firefox" ( no arguments ) 

The check for a difference i created a new useraccount and started firefox per desktop icon. NO CHANGE. killall doesn't find it.

Conclusion: the problem is systemrelated and not userrelated. 


Switching system to Surface Pro 4 F31 Kernel 5.8.8: same result: killall doesn't work for firefox. 

process name according to "ps auxf" /usr/lib64/firefox/firefox 


Testing on ACER Laptop: with F30 (fully updated with in F30) 

process name according to "ps auxf" /usr/lib64/firefox/firefox 

### killall finds firefox ###

process name according to "ps auxf" /usr/lib64/firefox/firefox 

Installed: psmisc-23.3.1-fc30.x86_64  & Kernel 5.6.13

Conclusion: Bug in(or across packages with) psmisc-23.3.2 in F31 confirmed. 


If you send me a debug rpm or the koji link to one, i will install and test it.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

As of 22.Nov.2020 .. works now with Fedora 32

"killall firefox"  terminates firefox as it should happen. 

ticket can be closed with "current release"

Just out of curiosity (and for research purposes), what changed so has started to work?

Many thanks.

the switch from F31 to F32

2020-11-22T14:46:52Z SUBDEBUG Upgraded: psmisc-23.3-2.fc31.x86_64 => psmisc-23.3-3.fc32.x86_64


I consider another component to be involved in the case, we both do not have on scope, like a lib of somekind.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days