Red Hat Bugzilla – Bug 64689
rsync -e ssh doesn't handle interrupt nicely
Last modified: 2014-08-31 19:24:09 EDT
jmm@jmm /tmp> rsync -a -e ssh root@db01:data .
root@db01's password: rsync error: received SIGUSR1 or SIGINT (code 20) at
very simple - if you ssh foo@bar and control-C at the password prompt, you get
your bash/shell prompt back and everything's fine. If rsync -e ssh gets the
same interrupt, it doesn't have the code-path to fixup the terminal settings
from their password-prompt mode and you've lost the shell (well, until you
type in "stty sane" or whatever)
I also noted this. Probably this should be submitted to the rsync developers.
ok - confirmed that the bug (leaving the terminal in noecho mode) was also
present in the 2.4.6 rpm build and 2.5.5 source at
http://rsync.samba.org/ftp/rsync/binaries/redhat/ and reported the problem to
the rsync lists - rsync's web site says their jitterbug is dead, so it's my
only available course of action
jmm@jmm /tmp/rsync-2.5.5> ./rsync -v -v -v -v -v -v -v -e
/tmp/openssh-3.2.3p1/ssh /tmp/foo root@angus:/tmp
cmd=/tmp/openssh-3.2.3p1/ssh machine=angus user=root path=/tmp
cmd=/tmp/openssh-3.2.3p1/ssh -l root angus rsync --server -vvvvvvv . /tmp
opening connection using /tmp/openssh-3.2.3p1/ssh -l root angus rsync --server
-vvvvvvv . /tmp
root@angus's password: _exit_cleanup(code=20, file=rsync.c, line=229): entered
rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229)
_exit_cleanup(code=20, file=rsync.c, line=229): about to call exit(20)
now I'm not so sure who's at fault -
openssh-3.2.3p1/openbsd-compat/readpassphrase.c made me think perhaps they
weren't watching for USR1 correctly since killing children with USR1 is what
rsync's _exit_cleanup does
* Catch signals that would otherwise cause the user to end
* up with echo turned off in the shell. Don't worry about
* things like SIGALRM and SIGPIPE for now.
sa.sa_flags = 0; /* don't restart system calls */
sa.sa_handler = handler;
(void)sigaction(SIGINT, &sa, &saveint);
(void)sigaction(SIGHUP, &sa, &savehup);
(void)sigaction(SIGQUIT, &sa, &savequit);
(void)sigaction(SIGTERM, &sa, &saveterm);
(void)sigaction(SIGTSTP, &sa, &savetstp);
(void)sigaction(SIGTTIN, &sa, &savettin);
(void)sigaction(SIGTTOU, &sa, &savettou);
but when I run ssh (rpm version or 3.2.3p1 built from source) manually and send
it a signal (USR1 or USR2, actually I tested all signals up to 20/SIGTSTP) I get
the terminal back with echo turned on just fine.
I don't see rsync turning echo off on its own, so I'm not sure it's rsync's
problem to fix, although since I don't see rsync installing its own handler for
SIGINT (afaict), then maybe it should so it can propogate a known-good signal
down to the ssh, since what might be happening is the SIGINT's interrupting
rsync, it doesn't propogate nicely, so SIGPIPE (maybe?) is ending up at ssh
which is doesn't handle it nicely.
Anyone more familiar with the code or interaction feel free to clarify my muddy
This is just an additional comment to note some activity.
I submitted this to the rsync mailing list (email@example.com), and one of
the rsync developers, JW Shultz (firstname.lastname@example.org) responded with this:
Sorry. Don't blame ssh. Rsync is messing things up.
I've attached a cleaned up strace output.
What is happening is that both rsync and ssh get the SIGINT.
Unfortunately, before ssh has had a sufficient chance to
process the SIGINT rsync sends it a SIGUSR1 as part of
cleanup. ssh doesn't catch SIGUSR1 so it just exits.
This is the first i've looked at this part of rsync so i'd
be cautious about changing any of the timings. However, it
does seem to me that a more correct behavior on receiving a
SIGINT would be to forward that to the children and give
them a chance to clean up before sending any more signals.
J.W. Schultz Pegasystems Technologies
email address: email@example.com
Then I asked JW if he intended to pursue a solution to this bug, and here is his
I don't know. I don't consider it worth my time. Perhaps
someone else will. What i don't want to see is things
destablized fixing such a insignificant bug.
Perhaps the reason i consider this such an insignificant bug
is that i've experienced this sort of terminal-mode error so
many times over the years due to things like editors crashing
and other stuff. There are several ways to work around
this. I usually just type "<CR>stty sane<CR>".
Frankly, ssh could still be considered to be faulty. If it
gets any catchable signal while in -echo mode it should
reset the terminal prior to exiting.
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.
If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.
Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
Closing as CANTFIX.