<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><TITLE>rsync current issues</TITLE><style>code {  font-family: monospace;  font-weight: bold;  white-space: pre;}pre code {  display: block;  font-weight: normal;}blockquote pre code {  background: #f1f1f1;}</style></HEAD><!--#include virtual="header.html" --> <H2 align="center">current issues and debugging</H2> <ol> <li><p><b>Q:</b> Rsync appears hung -- what should I do? <p><b>A:</b> When experiencing a hang or freeze <b>please</b> gather the followinginformation before killing the rsync process: <ul> <li> The state of the send/receive queues shown with netstat on the two ends. <li> The system call that each of the 3 processes is stuck in (use truss onsolaris, strace on Linux, etc.). </ul> <p>Try telling rsync on both sides of the connection to send messages tostderr, which might make the failure message visible.  i.e., use: <blockquote<pre><code>--msgs2stderr -M--msgs2stderr</code></pre></blockquote> <p>That alone might get rsync to stop hanging.  Also, if you're using more thanone <code>--verbose</code> (<code>-v</code>) option then I have 2 simple wordsfor you: stop it.  If you need more info on what rsync is changing, using the<code>--itemize-changes</code> option (<code>-i</code>) and repeat it if youneed to see unchanged files. This is a much better way to go that doesn't fillup the communication pipeline with a large quanity of debug messages. <p>See the "rsync-debug" script below for an example of how to grab straceinformation from the remote rsync process(es).  If you need help, send email tothe mailing list.  <li><p><b>Q:</b> Why does my chrooted rsync daemon crash when doing an LDAP lookup for a user orgroup? <p><b>A:</b> There is a bug in some LDAP libraries (e.g. Fedora Core 3) where it crasheswhen someone looks up a name from inside a chrooted process (one that does notcontain copies of the libraries to perform the lookup).  This is a bug that theLDAP libraries will need to fix, and is out of rsync's hands.  You can workaround the problem by using the <code>--numeric-ids</code> option, turningchroot off, or getting rid of LDAP lookups. <li><p><b>Q:</b> Why does my transfer die with something like the following error? <blockquote><pre><code>rsync: error writing 4 unbuffered bytes - exiting: Broken pipersync error: error in rsync protocol data stream (code 12) at io.c(463)</code></pre></blockquote> <p>or <blockquote><pre><code>rsync: connection unexpectedly closed (24 bytes read so far)rsync error: error in rsync protocol data stream (code 12) at io.c(342)</code></pre></blockquote> <p><b>A:</b> This error tells you that the local rsync was trying to talk to the remotersync, but the connection to that rsync is now gone.  The thing you mustfigure out is <b>why</b>, and that can involve some investigative work. <p>It is a good idea use the <code>--msgs2stderr</code> options mentioned atthe top of this page to get rsync to output any errors it encounters to stderrinstead of trying to write them down the failing pipeline. <p>If the connection is via ssh (or other remote-shell command) then you shouldrun some tests to make sure that you can actually run the remote rsync and thatyour shell isn't injecting extraneous output into the rsync stream.  For instance,try running these two commands using whatever HOST (and user) options you need: <blockquote><pre><code>echo hi | ssh HOST catssh HOST rsync --version</code></pre></blockquote> <p>The first command should output just the string "hi" and nothing else. Thesecond command should successfully start the remote rsync and report its version. <p>If the remote rsync is a daemon, your first step should be to look at thedaemon's log file to see if it logged an error explaining why it aborted thetransfer.  Also double-check to ensure that the log file is setup right, as awrong "log file" setting in your rsyncd.conf file can also cause this problem.You could also halt the daemon and run it interactively using the<code>--no-detach</code> and <code>--msgs2stderr</code> options and look forerrors while someone tries the rsync copy in another window. <p>As for the cause of the remote rsync going away, there are severalcommon issues that people run into: <ul> <li>The destination disk is full (remember that you need at least thesize of the largest file that needs to be updated available in freedisk space for the transfer to succeed). <li>An idle connection caused a router or remote-shell server to closethe connection. <li>A network error caused the connection to be dropped. <li>The remote rsync executable wasn't found. <li>Your remote-shell setup isn't working right or isn't "clean"(i.e. it is sending spurious text to rsync). </ul> <p>If you think the problem might be an idle connection getting closed, youmight be able to work around the problem by using a <code>--timeout</code>option (newer rsyncs send keep-alive messages during lulls).  You can alsoconfigure ssh to send keep-alive messages when using Protocol 2 (look forKeepAlive, ServerAliveInterval, ClientAliveInterval, ServerAliveCountMax, andClientAliveCountMax).  You can also avoid some lulls by switching from<code>--delete</code> (aka <code>--delete-before</code>) to <code>--del</code>(aka <code>--delete-during</code>). <p>If you can't figure out why the failure happened, there are stepsyou can take to debug the situation.  One way is to create a shellscript on the remote system such as<a href="rsync-debug">this one named "rsync-debug"</a>.You would use the script like this: <blockquote><pre><code>rsync -av --rsync-path=/some/path/rsync-debug HOST:SOURCE DESTrsync -av --rsync-path=/some/path/rsync-debug SOURCE HOST:DEST</code></pre></blockquote> <p>This script enables core dumps and also logs all the OS system callsthat lead up to the failure to a file in the /tmp dir.  You can use theresulting files to help figure out why the remote rsync failed. <p>If you are rsyncing directly to an rsync daemon (without using aremote-shell transport), the above script won't haveany effect.  Instead, halt the current daemon and run a debug versionwith core-dumps enabled and (if desired) using asystem-call tracing utility such as <i>strace</i>, <i>truss</i>, or<i>tusc</i>.  For strace, you would do it like this (the -f optiontells strace to follow the child processes too): <blockquote><pre><code>ulimit -c unlimitedstrace -f -t -s 1024 -o /tmp/rsync-$$.out rsync --daemon --no-detach</code></pre></blockquote> <p>Then, use a separate window to actually run the failing transfer, afterwhich you can kill the debug rsync daemon (pressing Ctrl-C should do it). <p>If you are using rsync under inetd, I'd suggest temporarily disablingthat and using the above daemon approach to debug what is going on. <li><p><b>Q:</b> Why does my connection to an rsync daemon (using the "::" syntax)fail immediately with an error like the following? <blockquote><pre><code>rsync: connection unexpectedly closed (24 bytes read so far)rsync error: error in rsync protocol data stream (code 12) at io.c(342)</code></pre></blockquote> <p><b>A:</b> Older rsync daemons (before 2.6.3) were unable to return errors that weregenerated during the option-parsing phase of the transfer.  Look in thelogfile on the server to see if an error was reported, such as a "refused"option, an option that the server rsync doesn't support (e.g.  perhapslinks are not supported by the server), or some other failure (such astrying to send data to a read-only module).  Upgrading the version of rsyncthat is running as a daemon to at least 2.6.3 will allow these errors toget returned to all rsync clients, old or new alike. </ol> <!--#include virtual="footer.html" -->