4

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.)

  • 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
  • 1
    Just a comment: The spid variable will hold the PID of the sudo process, not the PID of sleep. – Kusalananda Jan 10 '18 at 11:06
  • The same with Centos 7.5. The command from the script does not work, but it works from command line. There are 2 pids, sudo sleep and sleep. $! returns the pid of sudo sleep. Killing this pid from the script does nothing, killing this exact same pid from command line does kill the command (both sudo sleep and sleep processes are killed). – Jérôme Sep 18 '19 at 15:53
  • The problem exists in Centos 7.5, and not in Centos 7.6. Just like Ubuntu 15 VS Ubuntu 18. – Jérôme Sep 19 '19 at 8:04
1

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.

| improve this answer | |
  • 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
0

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
| improve this answer | |
  • 1
    It's the sudo that gets killed, not the sleep. sudo ought to relay the TERM signal to sleep though. – Kusalananda Jan 10 '18 at 11:09
0

I had a similar problem and landed here. The other answers didn't help. My script was piping IDs into kill along the lines of:

echo $some_output | awk '{print $1}' | xargs kill -9

This worked from the terminal but not from a script. After finding this answer that said kill doesn't read PIDs from stdin, I changed the script to this and it fixed the problem:

pids=`echo $some_output | awk '{print $1}'`

for p in $pids; do
    echo "Killing $p"
    kill -9 $p
done

Hopefully, that helps someone who landed here like I did!

| improve this answer | |
New contributor
gMale is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • on a related note: pkill <name> and pidof <name> were two very helpful commands that I found after writing my script that simplified things a lot. – gMale Oct 18 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.