What is the `-KILL` option in `pkill` command
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I have found a way to logout any user by using the command line. By executing the command pkill -KILL -u <username>, I can now log myself out from the session I have entered.
My question is that why there is no description about -KILL switch or option available neither in man pkill nor in pkill --help.
I am using Ubuntu Mate 16.04. Thanck you very much in advance.
man pkill
asked Jan 31 at 16:08
Tower
1441115
add a comment |Â
up vote
0
down vote
favorite
I have found a way to logout any user by using the command line. By executing the command pkill -KILL -u <username>, I can now log myself out from the session I have entered.
My question is that why there is no description about -KILL switch or option available neither in man pkill nor in pkill --help.
I am using Ubuntu Mate 16.04. Thanck you very much in advance.
man pkill
asked Jan 31 at 16:08
Tower
1441115
2
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have found a way to logout any user by using the command line. By executing the command pkill -KILL -u <username>, I can now log myself out from the session I have entered.
My question is that why there is no description about -KILL switch or option available neither in man pkill nor in pkill --help.
I am using Ubuntu Mate 16.04. Thanck you very much in advance.
man pkill
asked Jan 31 at 16:08
Tower
1441115
I have found a way to logout any user by using the command line. By executing the command pkill -KILL -u <username>, I can now log myself out from the session I have entered.
My question is that why there is no description about -KILL switch or option available neither in man pkill nor in pkill --help.
I am using Ubuntu Mate 16.04. Thanck you very much in advance.
man pkill
asked Jan 31 at 16:08
Tower
1441115
asked Jan 31 at 16:08
Tower
1441115
asked Jan 31 at 16:08
Tower
1441115
asked Jan 31 at 16:08
Tower
1441115
1441115
2
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47
add a comment |Â
2
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47
2
2
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
The -KILL argument is telling pkill which signal to send to all of the processes identified by the other arguments. So you are sending SIGKILL which is a very very unclean way do do what you appear to be trying to do. You probably want to send SIGHUP (with -HUP) or SIGTERM (with -TERM or omitting it, as SIGTERM is the default signal for kill/pkill).
To simplify, when a process receives SIGTERM from the kernel, it is being told "you need to go away now. Clean up after yourself and self-terminate". Most well-designed programs will upon receiving this signal promptly and sanely close themselves.
When a process reveives SIGHUP, it is being told "Hey, whoever you were talking to just hung up". While this was historically used for serial connections which were prone to unexpected disconnections, this is often used as a signal to have a shell's job control to spin down all pending processes (or ofttimes for a daemon to reinitialize itself or re-parse its configuration file).
When a process receives SIGKILL, the kernel (metaphorically) walks up behind it and shoots it in the back of the head. On one hand: no fuss, no muss. On the other hand: there may be a huge mess to clean up.
A KILLed process has no chance to clean up any open temporary files; any unflushed cached data are likely to be lost, and so forth. Don't send SIGKILL unless you really have to.
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems seeps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))'for a list of processes that do have a handler on SIGTERM.
– Stéphane Chazelas
Jan 31 at 16:31
notekillandpkillwill sendSIGTERMby default. trypkill foobefore sendingpkill -KILL foo.
– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
If the goal is logging out users, then really aSIGHUPshould be sent before sending either of those.
– JdeBP
Jan 31 at 17:40
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
The -KILL argument is telling pkill which signal to send to all of the processes identified by the other arguments. So you are sending SIGKILL which is a very very unclean way do do what you appear to be trying to do. You probably want to send SIGHUP (with -HUP) or SIGTERM (with -TERM or omitting it, as SIGTERM is the default signal for kill/pkill).
To simplify, when a process receives SIGTERM from the kernel, it is being told "you need to go away now. Clean up after yourself and self-terminate". Most well-designed programs will upon receiving this signal promptly and sanely close themselves.
When a process reveives SIGHUP, it is being told "Hey, whoever you were talking to just hung up". While this was historically used for serial connections which were prone to unexpected disconnections, this is often used as a signal to have a shell's job control to spin down all pending processes (or ofttimes for a daemon to reinitialize itself or re-parse its configuration file).
When a process receives SIGKILL, the kernel (metaphorically) walks up behind it and shoots it in the back of the head. On one hand: no fuss, no muss. On the other hand: there may be a huge mess to clean up.
A KILLed process has no chance to clean up any open temporary files; any unflushed cached data are likely to be lost, and so forth. Don't send SIGKILL unless you really have to.
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems seeps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))'for a list of processes that do have a handler on SIGTERM.
– Stéphane Chazelas
Jan 31 at 16:31
notekillandpkillwill sendSIGTERMby default. trypkill foobefore sendingpkill -KILL foo.
– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
If the goal is logging out users, then really aSIGHUPshould be sent before sending either of those.
– JdeBP
Jan 31 at 17:40
add a comment |Â
up vote
4
down vote
accepted
The -KILL argument is telling pkill which signal to send to all of the processes identified by the other arguments. So you are sending SIGKILL which is a very very unclean way do do what you appear to be trying to do. You probably want to send SIGHUP (with -HUP) or SIGTERM (with -TERM or omitting it, as SIGTERM is the default signal for kill/pkill).
To simplify, when a process receives SIGTERM from the kernel, it is being told "you need to go away now. Clean up after yourself and self-terminate". Most well-designed programs will upon receiving this signal promptly and sanely close themselves.
When a process reveives SIGHUP, it is being told "Hey, whoever you were talking to just hung up". While this was historically used for serial connections which were prone to unexpected disconnections, this is often used as a signal to have a shell's job control to spin down all pending processes (or ofttimes for a daemon to reinitialize itself or re-parse its configuration file).
When a process receives SIGKILL, the kernel (metaphorically) walks up behind it and shoots it in the back of the head. On one hand: no fuss, no muss. On the other hand: there may be a huge mess to clean up.
A KILLed process has no chance to clean up any open temporary files; any unflushed cached data are likely to be lost, and so forth. Don't send SIGKILL unless you really have to.
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems seeps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))'for a list of processes that do have a handler on SIGTERM.
– Stéphane Chazelas
Jan 31 at 16:31
notekillandpkillwill sendSIGTERMby default. trypkill foobefore sendingpkill -KILL foo.
– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
If the goal is logging out users, then really aSIGHUPshould be sent before sending either of those.
– JdeBP
Jan 31 at 17:40
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
The -KILL argument is telling pkill which signal to send to all of the processes identified by the other arguments. So you are sending SIGKILL which is a very very unclean way do do what you appear to be trying to do. You probably want to send SIGHUP (with -HUP) or SIGTERM (with -TERM or omitting it, as SIGTERM is the default signal for kill/pkill).
To simplify, when a process receives SIGTERM from the kernel, it is being told "you need to go away now. Clean up after yourself and self-terminate". Most well-designed programs will upon receiving this signal promptly and sanely close themselves.
When a process reveives SIGHUP, it is being told "Hey, whoever you were talking to just hung up". While this was historically used for serial connections which were prone to unexpected disconnections, this is often used as a signal to have a shell's job control to spin down all pending processes (or ofttimes for a daemon to reinitialize itself or re-parse its configuration file).
When a process receives SIGKILL, the kernel (metaphorically) walks up behind it and shoots it in the back of the head. On one hand: no fuss, no muss. On the other hand: there may be a huge mess to clean up.
A KILLed process has no chance to clean up any open temporary files; any unflushed cached data are likely to be lost, and so forth. Don't send SIGKILL unless you really have to.
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
The -KILL argument is telling pkill which signal to send to all of the processes identified by the other arguments. So you are sending SIGKILL which is a very very unclean way do do what you appear to be trying to do. You probably want to send SIGHUP (with -HUP) or SIGTERM (with -TERM or omitting it, as SIGTERM is the default signal for kill/pkill).
To simplify, when a process receives SIGTERM from the kernel, it is being told "you need to go away now. Clean up after yourself and self-terminate". Most well-designed programs will upon receiving this signal promptly and sanely close themselves.
When a process reveives SIGHUP, it is being told "Hey, whoever you were talking to just hung up". While this was historically used for serial connections which were prone to unexpected disconnections, this is often used as a signal to have a shell's job control to spin down all pending processes (or ofttimes for a daemon to reinitialize itself or re-parse its configuration file).
When a process receives SIGKILL, the kernel (metaphorically) walks up behind it and shoots it in the back of the head. On one hand: no fuss, no muss. On the other hand: there may be a huge mess to clean up.
A KILLed process has no chance to clean up any open temporary files; any unflushed cached data are likely to be lost, and so forth. Don't send SIGKILL unless you really have to.
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
edited Jan 31 at 18:37
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
answered Jan 31 at 16:13
DopeGhoti
40.4k54879
40.4k54879
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems seeps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))'for a list of processes that do have a handler on SIGTERM.
– Stéphane Chazelas
Jan 31 at 16:31
notekillandpkillwill sendSIGTERMby default. trypkill foobefore sendingpkill -KILL foo.
– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
If the goal is logging out users, then really aSIGHUPshould be sent before sending either of those.
– JdeBP
Jan 31 at 17:40
add a comment |Â
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems seeps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))'for a list of processes that do have a handler on SIGTERM.
– Stéphane Chazelas
Jan 31 at 16:31
notekillandpkillwill sendSIGTERMby default. trypkill foobefore sendingpkill -KILL foo.
– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
If the goal is logging out users, then really aSIGHUPshould be sent before sending either of those.
– JdeBP
Jan 31 at 17:40
2
2
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems see
ps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))' for a list of processes that do have a handler on SIGTERM.– Stéphane Chazelas
Jan 31 at 16:31
Note that SIGTERM is not handled by commands by default. The stdio buffers for instance are not flushed by default upon SIGTERM. The commands will have to actively install a handler on SIGTERM for that. On GNU/Linux systems see
ps -eo caught,pid,args | gawk -v t="$(kill -l TERM)" 'and(strtonum("0x"$1), 2**(t-1))' for a list of processes that do have a handler on SIGTERM.– Stéphane Chazelas
Jan 31 at 16:31
note
kill and pkill will send SIGTERM by default. try pkill foo before sending pkill -KILL foo.– quixotic
Jan 31 at 16:51
note
kill and pkill will send SIGTERM by default. try pkill foo before sending pkill -KILL foo.– quixotic
Jan 31 at 16:51
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
While it is true that SIGTERM is the default, I prefer to explicitly state which signal I wish to send when using KILL as a self-imposed sanity check. It also makes editing the command line / script to send non-TERM signals easier on later iterations if needed.
– DopeGhoti
Jan 31 at 17:15
1
1
If the goal is logging out users, then really a
SIGHUP should be sent before sending either of those.– JdeBP
Jan 31 at 17:40
If the goal is logging out users, then really a
SIGHUP should be sent before sending either of those.– JdeBP
Jan 31 at 17:40
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%2f421003%2fwhat-is-the-kill-option-in-pkill-command%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
2
That's an extraordinarily bad way to log out. See e.g. unix.stackexchange.com/questions/281439/…
– Kusalananda
Jan 31 at 16:47