Why can't I kill a `Sl` process?











up vote
5
down vote

favorite
1












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


.










share|improve this question




















  • 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 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















up vote
5
down vote

favorite
1












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


.










share|improve this question




















  • 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 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













up vote
5
down vote

favorite
1









up vote
5
down vote

favorite
1






1





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


.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 5 at 13:15

























asked Nov 5 at 13:05









Tim

24.7k70239433




24.7k70239433








  • 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 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














  • 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 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








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










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.






share|improve this answer



















  • 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


















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.






share|improve this answer























  • 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











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















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
































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.






share|improve this answer



















  • 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















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.






share|improve this answer



















  • 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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














  • 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












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.






share|improve this answer























  • 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















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.






share|improve this answer























  • 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













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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














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




















































































這個網誌中的熱門文章

Hercules Kyvelos

Tangent Lines Diagram Along Smooth Curve

Yusuf al-Mu'taman ibn Hud