Bug 64689

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  
  
http://lists.samba.org/pipermail/rsync/2002-May/007426.html

 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.
         */
        sigemptyset(&sa.sa_mask);
        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
understanding :)

This is just an additional comment to note some activity.

I submitted this to the rsync mailing list (rsync.org), and one of
the rsync developers, JW Shultz (jw) 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:          jw


Then I asked JW if he intended to pursue a solution to this bug, and here is his
response:

================================================================
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
provided.

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
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.