Bug 11679 - rsync should kill() itself when it receives a signal from the user
rsync should kill() itself when it receives a signal from the user
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.2
All All
: P5 trivial
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-18 01:22 UTC by Delan Azabani
Modified: 2016-01-18 01:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Delan Azabani 2016-01-18 01:22:34 UTC
If rsync receives a signal that would cause it to exit with RERR_SIGNAL, I think that it should kill() itself with that signal instead of calling exit(RERR_SIGNAL).

With the current behaviour, for example, if rsync is invoked from a shell script and the user sends ^C, the shell script will not terminate unless it has additional machinery to check the exit status of every rsync invocation. This is not a reliable workaround, because depending on where in the rsync process the signal was received, rsync may not ultimately exit with RERR_SIGNAL.

To interrupt a shell loop that invokes rsync, the shell loop would currently require an additional indication that it should be broken, such as touching a file, or a sleep(1) command after the rsync command together with multiple signals, such as holding down ^C.