5

On Lubuntu 18.04, I open pcmanfm

$ pcmanfm . 

and after looking at the thumbnails of the image files under the current directory in pcmanfm, I closed the window of pcmanfm by Alt-F4, but it is still hanging on the foreground in the terminal emulator.

I move it to background by Ctrl-Z and bg 2, and kill it, but doesn't work.

$ jobs -l 
[2]+ 31124 Running                 pcmanfm . &
$ kill %2
$ jobs -l
[2]+ 31124 Running                 pcmanfm . &
$ sudo kill 31124
$ jobs -l
[2]+ 31124 Running                 pcmanfm . &

Its state is Sl, S means "interruptible sleep (waiting for an event to complete)" and l means "is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)". So I wonder why I can't kill the process? How would you kill it? Thanks.

$ ps aux | grep [3]1124
t        31124  0.8  0.7 693952 57064 pts/9    Sl   06:34   0:47 pcmanfm 

.

Tim
  • 101,790
  • 13
    You don't need sudo. sudo is not your friend. When you can't cut the bread, because it is in the bread box, don't use a chain-saw, instead take it out of the box. – ctrl-alt-delor Nov 05 '18 at 13:09
  • 2
    I was wondering why "don't need sudo", and what you mean by "take it out of the box"? – Tim Nov 05 '18 at 13:10
  • 1
    If the process is started by you, then you have permission to kill it. If bread is in bread-box (a place to store bread (not often used with today's modern bread substitute)), then you can not cut it with knife. – ctrl-alt-delor Nov 05 '18 at 13:13
  • On a vanilla Lubuntu 18.04, I see pcmanfm --desktop --profile lubuntu with Sl and this is without actually launching pcmanfm. Don't you see something like that immediately after you log in? – DK Bose Nov 05 '18 at 14:01

2 Answers2

18

By default, kill only sends a TERM signal, for some reason pcmanfm is ignoring this signal. If you pass option -KILL to kill, then it will send the signal to the scheduler, and the process will be removed with no chance to clean-up, or appeal.

You do not need extra privileges (sudo), to kill processes that you own. sudo can be dangerous, don't just use out of frustration.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
  • 6
    However, I can strongly recommend using -KILL out of frustration. It feels surprisingly good when a stupid process finally dies after no longer responding to input. – pipe Nov 05 '18 at 16:36
  • 5
    SIGKILL isn't actually handled any differently than any other signal. The difference is that processes can't change the default handling of the signal, which is to kill the process. Notably that this means that operating system still does its own clean up of the process (eg. closing open files) and the process will be scheduled normally while this happens. In rare cases this can take a while, or even hang, leaving the process unkillable: https://unix.stackexchange.com/questions/81285/how-to-kill-a-process-which-cant-be-killed-without-rebooting – Ross Ridge Nov 05 '18 at 18:15
  • @RossRidge yes a process can not change the signal handler for sigkill, it must allways be the TERM handler. This handler is done by the OS kernel. And yes the OS kernel always does garbage collection (of most resources, (not all locks, not all temp files, …)) when a process exits. And no the process is not scheduled once resources are being released (that would be real bad). – ctrl-alt-delor Nov 05 '18 at 21:50
  • 3
    @ctrl-alt-delor If I am not mistaken the process has to be scheduled in order to release the resources. It won't be executing user code at that point though, the process will be running in kernel mode to release resources. Once it is done releasing resources it becomes a zombie and then it will never be scheduled again. – kasperd Nov 05 '18 at 22:12
4

kill by default sends SIGTERM. This gets handled by the signal handler of the process and the process can:

  • install a signal handler that simply does nothing
  • have a signal ignored
  • mask the signal (and have it delivered once it's unmasked)

I guess that pcmanfm does something like that. You can find the latter two by looking at /proc/PID/status, at SigBlk and SigIgn

SIGKILL (9) on the other hand is not handled by the process itself and cannot have its signal handler changed, be ignored, or be masked.

Try running this python3 program against the pid of pcmanfn to see what exactly it ignores or blocks (needs python 3.5):

#!/usr/bin/python3

import os
import sys
import time
import signal

def show(label, value):
    ivalue = int(value, 16)
    print("%s: %s:"% (label, value.strip()), end=' ')
    cnt=1
    while ivalue:
        if ivalue & 1:
            print("%s(%s)" % (signal.Signals(cnt).name, cnt), end=' ')
        ivalue>>=1
        cnt+=1
    print()

if len(sys.argv)==1:
    pid=os.getpid()
else:
    pid=int(sys.argv[1])

status=open('/proc/%d/status' % (pid,)).readlines()
print("Pid: %d" % (pid,))
for line in status:
    what, value = line.split(':', 1)
    if what=='SigBlk':
        show('Blocked', value)
    elif what=='SigIgn':
        show('Ignored', value)

You should be able to see if SIGTERM is in there.

V13
  • 4,749
  • or you could simply look at pcmanfm's source code and see that it does nothing of the sort, but installs a signal handler that writes a byte into a pipe, the reading end of which ia wired to gtk's event loop, in which handlers are set for a clean exit in that case. Why that doesn't work as it should (if it really doesn't work and it's not just some confusion) is a different problem. –  Nov 06 '18 at 13:57
  • @mosvy, indeed, but that assumes that you're looking at the source of the same version they are running, although I don't see any relevant changes. – V13 Nov 07 '18 at 02:54