Why can't I kill a `Sl` process?
up vote
5
down vote
favorite
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
.
linux process kill
add a comment |
up vote
5
down vote
favorite
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
.
linux process kill
13
You don't needsudo
.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 5 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 5 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 5 at 13:13
On a vanilla Lubuntu 18.04, I seepcmanfm --desktop --profile lubuntu
withSl
and this is without actually launching pcmanfm. Don't you see something like that immediately after you log in?
– DK Bose
Nov 5 at 14:01
add a comment |
up vote
5
down vote
favorite
up vote
5
down vote
favorite
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
.
linux process kill
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
.
linux process kill
linux process kill
edited Nov 5 at 13:15
asked Nov 5 at 13:05
Tim
24.7k70239433
24.7k70239433
13
You don't needsudo
.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 5 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 5 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 5 at 13:13
On a vanilla Lubuntu 18.04, I seepcmanfm --desktop --profile lubuntu
withSl
and this is without actually launching pcmanfm. Don't you see something like that immediately after you log in?
– DK Bose
Nov 5 at 14:01
add a comment |
13
You don't needsudo
.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 5 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 5 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 5 at 13:13
On a vanilla Lubuntu 18.04, I seepcmanfm --desktop --profile lubuntu
withSl
and this is without actually launching pcmanfm. Don't you see something like that immediately after you log in?
– DK Bose
Nov 5 at 14:01
13
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 5 at 13:09
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 5 at 13:09
2
2
I was wondering why "don't need sudo", and what you mean by "take it out of the box"?
– Tim
Nov 5 at 13:10
I was wondering why "don't need sudo", and what you mean by "take it out of the box"?
– Tim
Nov 5 at 13:10
1
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 5 at 13:13
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 5 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 5 at 14:01
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 5 at 14:01
add a comment |
2 Answers
2
active
oldest
votes
up vote
17
down vote
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.
5
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 5 at 16:36
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
2
@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 5 at 22:12
add a comment |
up vote
4
down vote
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.
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.
– mosvy
Nov 6 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 7 at 2:54
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
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.
5
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 5 at 16:36
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
2
@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 5 at 22:12
add a comment |
up vote
17
down vote
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.
5
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 5 at 16:36
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
2
@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 5 at 22:12
add a comment |
up vote
17
down vote
up vote
17
down vote
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.
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.
edited Nov 6 at 11:42
Jeff Schaller
35.7k952119
35.7k952119
answered Nov 5 at 13:11
ctrl-alt-delor
9,69431952
9,69431952
5
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 5 at 16:36
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
2
@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 5 at 22:12
add a comment |
5
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 5 at 16:36
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
2
@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 5 at 22:12
5
5
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 5 at 16:36
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 5 at 16:36
4
4
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 at 18:15
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: unix.stackexchange.com/questions/81285/…
– Ross Ridge
Nov 5 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 5 at 21:50
@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 5 at 21:50
2
2
@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 5 at 22:12
@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 5 at 22:12
add a comment |
up vote
4
down vote
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.
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.
– mosvy
Nov 6 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 7 at 2:54
add a comment |
up vote
4
down vote
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.
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.
– mosvy
Nov 6 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 7 at 2:54
add a comment |
up vote
4
down vote
up vote
4
down vote
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.
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.
edited Nov 6 at 1:31
answered Nov 6 at 1:05
V13
2,646613
2,646613
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.
– mosvy
Nov 6 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 7 at 2:54
add a comment |
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.
– mosvy
Nov 6 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 7 at 2:54
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.
– mosvy
Nov 6 at 13:57
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.
– mosvy
Nov 6 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 7 at 2:54
@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 7 at 2:54
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f479900%2fwhy-cant-i-kill-a-sl-process%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 5 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 5 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 5 at 13:13
On a vanilla Lubuntu 18.04, I see
pcmanfm --desktop --profile lubuntu
withSl
and this is without actually launching pcmanfm. Don't you see something like that immediately after you log in?– DK Bose
Nov 5 at 14:01