Why does kill not work from script, but does work from terminal?
up vote
4
down vote
favorite
I have the following contrived script to illustrate my issue:
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill $spid
wait $!
This will print
$ ./test.sh
+ spid=21931
+ sleep 1
+ sudo sleep 120
+ sudo kill 21931
+ wait 21931
and then hang on wait until the sleep 120 times out. However, when I run sudo kill 21931 from another terminal the sleep process is killed immediately. I expected the sudo kill $spid line in the script to also kill the sleep process immediately. Why doesn't this work and how do I make this work?
(Might be relevant: I see this behaviour bash 4.3.42 and dash 0.5.7 on Ubuntu 15.10.)
bash ubuntu kill dash
edited Nov 23 at 22:55
Kusalananda
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
add a comment |
up vote
4
down vote
favorite
I have the following contrived script to illustrate my issue:
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill $spid
wait $!
This will print
$ ./test.sh
+ spid=21931
+ sleep 1
+ sudo sleep 120
+ sudo kill 21931
+ wait 21931
and then hang on wait until the sleep 120 times out. However, when I run sudo kill 21931 from another terminal the sleep process is killed immediately. I expected the sudo kill $spid line in the script to also kill the sleep process immediately. Why doesn't this work and how do I make this work?
(Might be relevant: I see this behaviour bash 4.3.42 and dash 0.5.7 on Ubuntu 15.10.)
bash ubuntu kill dash
edited Nov 23 at 22:55
Kusalananda
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
1
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just a comment: Thespidvariable will hold the PID of thesudoprocess, not the PID ofsleep.
– Kusalananda
Jan 10 at 11:06
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I have the following contrived script to illustrate my issue:
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill $spid
wait $!
This will print
$ ./test.sh
+ spid=21931
+ sleep 1
+ sudo sleep 120
+ sudo kill 21931
+ wait 21931
and then hang on wait until the sleep 120 times out. However, when I run sudo kill 21931 from another terminal the sleep process is killed immediately. I expected the sudo kill $spid line in the script to also kill the sleep process immediately. Why doesn't this work and how do I make this work?
(Might be relevant: I see this behaviour bash 4.3.42 and dash 0.5.7 on Ubuntu 15.10.)
bash ubuntu kill dash
edited Nov 23 at 22:55
Kusalananda
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
I have the following contrived script to illustrate my issue:
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill $spid
wait $!
This will print
$ ./test.sh
+ spid=21931
+ sleep 1
+ sudo sleep 120
+ sudo kill 21931
+ wait 21931
and then hang on wait until the sleep 120 times out. However, when I run sudo kill 21931 from another terminal the sleep process is killed immediately. I expected the sudo kill $spid line in the script to also kill the sleep process immediately. Why doesn't this work and how do I make this work?
(Might be relevant: I see this behaviour bash 4.3.42 and dash 0.5.7 on Ubuntu 15.10.)
bash ubuntu kill dash
bash ubuntu kill dash
edited Nov 23 at 22:55
Kusalananda
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
edited Nov 23 at 22:55
Kusalananda
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
edited Nov 23 at 22:55
Kusalananda
118k16222360
edited Nov 23 at 22:55
Kusalananda
118k16222360
edited Nov 23 at 22:55
Kusalananda
118k16222360
118k16222360
asked Nov 11 '15 at 22:20
Steffan Karger
1914
asked Nov 11 '15 at 22:20
Steffan Karger
1914
asked Nov 11 '15 at 22:20
Steffan Karger
1914
1914
1
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just a comment: Thespidvariable will hold the PID of thesudoprocess, not the PID ofsleep.
– Kusalananda
Jan 10 at 11:06
add a comment |
1
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just a comment: Thespidvariable will hold the PID of thesudoprocess, not the PID ofsleep.
– Kusalananda
Jan 10 at 11:06
1
1
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just a comment: The
spid variable will hold the PID of the sudo process, not the PID of sleep.– Kusalananda
Jan 10 at 11:06
Just a comment: The
spid variable will hold the PID of the sudo process, not the PID of sleep.– Kusalananda
Jan 10 at 11:06
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
I confirm this strange behaviour occurs as well on Ubuntu 17.10 bash 4.4.12(1)-release (x86_64-pc-linux-gnu).
I wasn't able to track down the real reason but it seems it has something to do with process signals. By default, kill sends out signal 15 – TERM which stands for a soft kill. However, if I use a hard 9 – KILL, the sleep process gets immediately killed.
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill -9 $spid
wait $!
prints out
$ ./test.sh
+ spid=4342
+ sleep 1
+ sudo sleep 120
+ sudo kill -9 4342
./test.sh: line 6: 4342 Killed sudo sleep 120
+ wait 4342
answered Jan 10 at 10:40
Edvard Rejthar
113
It's thesudothat gets killed, not thesleep.sudoought to relay theTERMsignal tosleepthough.
– Kusalananda
Jan 10 at 11:09
add a comment |
up vote
-1
down vote
The difference could be in the /etc/sudoers file. Maybe your user is allowed to run kill with nopasswd on one machine, but not on the other.
answered Nov 11 '15 at 23:06
user142756
612
Interesting thought, but the only difference between the sudoers files was that in one I hadDefaults !tty_tickets(the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)
– Steffan Karger
Nov 12 '15 at 20:14
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
I confirm this strange behaviour occurs as well on Ubuntu 17.10 bash 4.4.12(1)-release (x86_64-pc-linux-gnu).
I wasn't able to track down the real reason but it seems it has something to do with process signals. By default, kill sends out signal 15 – TERM which stands for a soft kill. However, if I use a hard 9 – KILL, the sleep process gets immediately killed.
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill -9 $spid
wait $!
prints out
$ ./test.sh
+ spid=4342
+ sleep 1
+ sudo sleep 120
+ sudo kill -9 4342
./test.sh: line 6: 4342 Killed sudo sleep 120
+ wait 4342
answered Jan 10 at 10:40
Edvard Rejthar
113
It's thesudothat gets killed, not thesleep.sudoought to relay theTERMsignal tosleepthough.
– Kusalananda
Jan 10 at 11:09
add a comment |
up vote
0
down vote
I confirm this strange behaviour occurs as well on Ubuntu 17.10 bash 4.4.12(1)-release (x86_64-pc-linux-gnu).
I wasn't able to track down the real reason but it seems it has something to do with process signals. By default, kill sends out signal 15 – TERM which stands for a soft kill. However, if I use a hard 9 – KILL, the sleep process gets immediately killed.
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill -9 $spid
wait $!
prints out
$ ./test.sh
+ spid=4342
+ sleep 1
+ sudo sleep 120
+ sudo kill -9 4342
./test.sh: line 6: 4342 Killed sudo sleep 120
+ wait 4342
answered Jan 10 at 10:40
Edvard Rejthar
113
It's thesudothat gets killed, not thesleep.sudoought to relay theTERMsignal tosleepthough.
– Kusalananda
Jan 10 at 11:09
add a comment |
up vote
0
down vote
up vote
0
down vote
I confirm this strange behaviour occurs as well on Ubuntu 17.10 bash 4.4.12(1)-release (x86_64-pc-linux-gnu).
I wasn't able to track down the real reason but it seems it has something to do with process signals. By default, kill sends out signal 15 – TERM which stands for a soft kill. However, if I use a hard 9 – KILL, the sleep process gets immediately killed.
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill -9 $spid
wait $!
prints out
$ ./test.sh
+ spid=4342
+ sleep 1
+ sudo sleep 120
+ sudo kill -9 4342
./test.sh: line 6: 4342 Killed sudo sleep 120
+ wait 4342
answered Jan 10 at 10:40
Edvard Rejthar
113
I confirm this strange behaviour occurs as well on Ubuntu 17.10 bash 4.4.12(1)-release (x86_64-pc-linux-gnu).
I wasn't able to track down the real reason but it seems it has something to do with process signals. By default, kill sends out signal 15 – TERM which stands for a soft kill. However, if I use a hard 9 – KILL, the sleep process gets immediately killed.
#!/bin/bash
set -eux
sudo sleep 120 &
spid=$!
sleep 1
sudo kill -9 $spid
wait $!
prints out
$ ./test.sh
+ spid=4342
+ sleep 1
+ sudo sleep 120
+ sudo kill -9 4342
./test.sh: line 6: 4342 Killed sudo sleep 120
+ wait 4342
answered Jan 10 at 10:40
Edvard Rejthar
113
answered Jan 10 at 10:40
Edvard Rejthar
113
answered Jan 10 at 10:40
Edvard Rejthar
113
answered Jan 10 at 10:40
Edvard Rejthar
113
113
It's thesudothat gets killed, not thesleep.sudoought to relay theTERMsignal tosleepthough.
– Kusalananda
Jan 10 at 11:09
add a comment |
It's thesudothat gets killed, not thesleep.sudoought to relay theTERMsignal tosleepthough.
– Kusalananda
Jan 10 at 11:09
It's the
sudo that gets killed, not the sleep. sudo ought to relay the TERM signal to sleep though.– Kusalananda
Jan 10 at 11:09
It's the
sudo that gets killed, not the sleep. sudo ought to relay the TERM signal to sleep though.– Kusalananda
Jan 10 at 11:09
add a comment |
up vote
-1
down vote
The difference could be in the /etc/sudoers file. Maybe your user is allowed to run kill with nopasswd on one machine, but not on the other.
answered Nov 11 '15 at 23:06
user142756
612
Interesting thought, but the only difference between the sudoers files was that in one I hadDefaults !tty_tickets(the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)
– Steffan Karger
Nov 12 '15 at 20:14
add a comment |
up vote
-1
down vote
The difference could be in the /etc/sudoers file. Maybe your user is allowed to run kill with nopasswd on one machine, but not on the other.
answered Nov 11 '15 at 23:06
user142756
612
Interesting thought, but the only difference between the sudoers files was that in one I hadDefaults !tty_tickets(the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)
– Steffan Karger
Nov 12 '15 at 20:14
add a comment |
up vote
-1
down vote
up vote
-1
down vote
The difference could be in the /etc/sudoers file. Maybe your user is allowed to run kill with nopasswd on one machine, but not on the other.
answered Nov 11 '15 at 23:06
user142756
612
The difference could be in the /etc/sudoers file. Maybe your user is allowed to run kill with nopasswd on one machine, but not on the other.
answered Nov 11 '15 at 23:06
user142756
612
answered Nov 11 '15 at 23:06
user142756
612
answered Nov 11 '15 at 23:06
user142756
612
answered Nov 11 '15 at 23:06
user142756
612
612
Interesting thought, but the only difference between the sudoers files was that in one I hadDefaults !tty_tickets(the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)
– Steffan Karger
Nov 12 '15 at 20:14
add a comment |
Interesting thought, but the only difference between the sudoers files was that in one I hadDefaults !tty_tickets(the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)
– Steffan Karger
Nov 12 '15 at 20:14
Interesting thought, but the only difference between the sudoers files was that in one I had
Defaults !tty_tickets (the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)– Steffan Karger
Nov 12 '15 at 20:14
Interesting thought, but the only difference between the sudoers files was that in one I had
Defaults !tty_tickets (the 'hanging' 15.10 machine). But after removing the line, the machine still hangs on wait. (There were no files in /etc/sudoers.d/ on both machines.)– Steffan Karger
Nov 12 '15 at 20:14
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f242444%2fwhy-does-kill-not-work-from-script-but-does-work-from-terminal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Just tried the same on an Ubuntu 14.04 machine (bash 4.3.11 / dash 0.5.7), and that gives me the behaviour I would expect: the sudo kill command from the script immediately kills the sleep 120 and the script ends. So, what could be different on Ubuntu 15.10 (or this machine)?
– Steffan Karger
Nov 11 '15 at 22:26
Just a comment: The
spidvariable will hold the PID of thesudoprocess, not the PID ofsleep.– Kusalananda
Jan 10 at 11:06