Bash not trapping interrupts during rsync/subshell exec statements

Question

Context:

I have a bash script that contains a subshell and a trap for the EXIT pseudosignal, and it's not properly trapping interrupts during an rsync. Here's an example:

#!/bin/bash
logfile=/path/to/file;
directory1=/path/to/dir
directory2=/path/to/dir

cleanup () {
     echo "Cleaning up!"
     #do stuff
     trap - EXIT 
}

trap '{
    (cleanup;) | 2>&1 tee -a $logfile
}' EXIT

(
    #main script logic, including the following lines:
    (exec sleep 10;);        
    (exec rsync --progress -av --delete $directory1 /var/tmp/$directory2;);

)  | 2>&1 tee -a $logfile
trap - EXIT #just in case cleanup isn't called for some reason

The idea of the script is this: most of the important logic runs in a subshell which is piped through tee and to a logfile, so I don't have to tee every single line of the main logic to get it all logged. Whenever the subshell ends, or the script is stopped for any reason (the EXIT pseudosignal should capture all of these cases), the trap will intercept it and run the cleanup() function, and then remove the trap. The rsync and sleep commands (the sleep is just an example) are run through exec to prevent the creation of zombie processes if I kill the parent script while they're running, and each potentially-long-running command is wrapped in its own subshell so that when exec finishes, it won't terminate the whole script.

The problem:

If I interrupt the script (via kill or CTRL+C) during the exec/subshell wrapped sleep command, the trap works properly, and I see "Cleaning up!" echoed and logged. If I interrupt the script during the rsync command, I see rsync end, and write rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(544) [sender=3.0.6] to the screen, and then the script just dies; no cleanup, no trapping. Why doesn't an interrupting/killing of rsync trigger the trap?

I've tried using the --no-detach switch with rsync, but it didn't change anything. I have bash 4.1.2, rsync 3.0.6, centOS 6.2.

This is not the reason for your problem but your logging is not reliable, because you write with two different programs at the same time to the same file. — ceving, Mar 12 '12 at 10:01
your `trap - EXIT` is in a subshell (explicitly), so it won't have an effect after the cleanup function returns — sehe, Mar 16 '12 at 15:56
Running exec in a subshell is the same as just running the command normally - you don't need the extra punctuation. — Alex Dupuy, Apr 01 '14 at 08:46

score 3 · Accepted Answer · answered Jun 04 '12 at 02:14

3

How about just having all the output from point X be redirected to tee without having to repeat it everywhere and mess with all the sub-shells and execs ... (hope I didn't miss something)

#!/bin/bash
logfile=/path/to/file;
directory1=/path/to/dir
directory2=/path/to/dir

exec > >(exec tee -a $logfile) 2>&1

cleanup () {
     echo "Cleaning up!"
     #do stuff
     trap - EXIT 
}
trap cleanup EXIT

sleep 10
rsync --progress -av --delete $directory1 /var/tmp/$directory2

answered Jun 04 '12 at 02:14

nhed

5,774
3
30
44

That was actually my first solution, but some of our environment's can't do the redirection because of a weird version of Bash or something....so I resorted to the "wrap the whole thing in a block and point it all to tee" hack. Good point though. – Zac B Jun 05 '12 at 20:05
@ZacB Can you be more specific about the "weird version of bash" ? In some situations (when run as `/bin/sh`) it runs n Posix compatibility mode ... If this is the case add `set +o posix` prior to `exec` – nhed Jun 08 '12 at 17:05
That was the situation @nhed; it was resolved by switching to `/bin/bash`. – Zac B Nov 25 '16 at 23:13

score 2 · Answer 2 · answered Jun 04 '12 at 01:21

In addition to set -e, I think you want set -E:

If set, any trap on ERR is inherited by shell functions, command substitutions, and commands executed in a sub‐shell environment. The ERR trap is normally not inherited in such cases.

Alternatively, instead of wrapping your commands in subshells use curly braces which will still give you the ability to redirect command outputs but will execute them in the current shell.

score 1 · Answer 3 · answered Mar 16 '12 at 15:27

1

The interupt will be properly caught if you add INT to the trap

trap '{
    (cleanup;) | 2>&1 tee -a $logfile
}' EXIT INT

Bash is trapping interrupts correctly. However, this does not anwer the question, why the script traps on exit if sleep is interupted, nor why it does not trigger on rsync, but makes the script work as it is supposed to. Hope this helps.

answered Mar 16 '12 at 15:27

Jari Laamanen

2,617
1
15
8

This looked right, but I implemented it and it had the opposite of the desired effect. If I add INT to the trap calls, the `sleep` statement no longer triggers the trap, and the `rsync` still doesn't either. When I remove INT (changing nothing else) `sleep` triggers the trap again. – Zac B Mar 22 '12 at 16:26
Remove your last "just in case" trap, and the script should work fine also with the EXIT traps. INT in the trap calling the cleanup should be the correct way to deal with the interrupts, however. Unrelated, but like sehe wrote, the trap in the subshell does nothing. – Jari Laamanen Mar 22 '12 at 20:14

score 0 · Answer 4 · answered Jul 10 '18 at 01:53

It's pretty clear from experimentation that rsync behaves like other tools such as ping and do not inherit signals from the calling Bash parent.

So you have to get a little creative with this and do something like the following:

$ cat rsync.bash
#!/bin/sh

 set -m
 trap '' SIGINT SIGTERM EXIT
 rsync -avz LargeTestFile.500M root@host.mydom.com:/tmp/. &
 wait

 echo FIN

Now when I run it:

$ ./rsync.bash
X11 forwarding request failed
building file list ... done
LargeTestFile.500M
^C^C^C^C^C^C^C^C^C^C
sent 509984 bytes  received 42 bytes  92732.00 bytes/sec
total size is 524288000  speedup is 1027.96
FIN

And we can see the file did fully transfer:

$ ll -h | grep Large
-rw-------. 1  501 games 500M Jul  9 21:44 LargeTestFile.500M

How it works

The trick here is we're telling Bash via set -m to disable job controls on any background jobs within it. We're then backgrounding the rsync and then running a wait command which will wait on the last run command, rsync, until it's complete.

We then guard the entire script with the trap '' SIGINT SIGTERM EXIT.

References

score 0 · Answer 5 · answered Mar 16 '12 at 15:55

Your shell might be configured to exit on error:

bash # enter subshell
set -e
trap "echo woah" EXIT
sleep 4

If you interrupt sleep (^C) then the subshell will exit due to set -e and print woah in the process.

Also, slightly unrelated: your trap - EXIT is in a subshell (explicitly), so it won't have an effect after the cleanup function returns

Bash not trapping interrupts during rsync/subshell exec statements

5 Answers5

How it works

References

Linked