• home
• FAQ
• resources
• features
• examples
• mailing lists

• bug-tracking
• current issues and debugging
• download
• documentation
• search

current issues and debugging

1. Q: Rsync appears hung -- what should I do?

   A: When experiencing a hang or freeze please gather the following information before killing the rsync process:

   • The state of the send/receive queues shown with netstat on the two ends.
   • The system call that each of the 3 processes is stuck in (use truss on solaris, strace on Linux, etc.).

   See the "rsync-debug" script below for an example of how to grab strace information from the remote rsync process(es). If you need help, send email to the mailing list.

2. Q: Why does my chrooted rsync daemon crash when doing an LDAP lookup for a user or group?

   A: There is a bug in some LDAP libraries (e.g. Fedora Core 3) where it crashes when someone looks up a name from inside a chrooted process (one that does not contain copies of the libraries to perform the lookup). This is a bug that the LDAP libraries will need to fix, and is out of rsync's hands. You can work around the problem by using the --numeric-ids option, turning chroot off, or getting rid of LDAP lookups.

3. Q: Why does my transfer die with something like the following error?

   rsync: error writing 4 unbuffered bytes - exiting: Broken pipe
   rsync error: error in rsync protocol data stream (code 12) at io.c(463)
   

   or

   rsync: connection unexpectedly closed (24 bytes read so far)
   rsync error: error in rsync protocol data stream (code 12) at io.c(342)
   

   A: This error tells you that the local rsync was trying to talk to the remote rsync, but the connection to that rsync is now gone. The thing you must figure out is why, and that can involve some investigative work.

   If the remote rsync is a daemon, your first step should be to look at the daemon's log file to see if it logged an error explaining why it aborted the transfer.

   Beginning with version 2.6.3, rsync now does a better job of retreiving the error from the remote process than older versions of rsync, so you may wish to try upgrading and see if you now get sent the error message from the remote rsync.

   There are several common causes for a remote rsync process going away:

   • The destination disk is full (remember that you need at least the size of the largest file that needs to be updated available in free disk space for the transfer to succeed).
   • An idle connection caused a router or remote-shell server to close the connection.
   • A network error caused the connection to be dropped.
   • The remote rsync executable wasn't found.
   • Your remote-shell setup isn't working right or isn't "clean" (i.e. it is sending spurious text to rsync).

   If you think the problem might be an idle connection getting closed, you might be able to work around the problem by using a --timeout option (newer rsyncs send keep-alive messages during lulls). You can also configure ssh to send keep-alive messages when using Protocol 2 (look for KeepAlive, ServerAliveInterval, ClientAliveInterval, ServerAliveCountMax, and ClientAliveCountMax). You can also avoid some lulls by switching from --delete (aka --delete-before) to --del (aka --delete-during).

   If you can't figure out why the failure happened, there are steps you can take to debug the situation. One way is to create a shell script on the remote system such as this one named "rsync-debug". You would use the script like this:

   rsync -av --rsync-path=/some/path/rsync-debug HOST:SOURCE DEST
   rsync -av --rsync-path=/some/path/rsync-debug SOURCE HOST:DEST
   

   This script enables core dumps and also logs all the OS system calls that lead up to the failure to a file in the /tmp dir. You can use the resulting files to help figure out why the remote rsync failed.

   If you are rsyncing directly to an rsync daemon (without using a remote-shell transport), the above script won't have any effect. Instead, halt the current daemon and run a debug version with core-dumps enabled and (if desired) using a system-call tracing utility such as strace, truss, or tusc. For strace, you would do it like this (the -f option tells strace to follow the child processes too):

   ulimit -c unlimited
   strace -f rsync --daemon --no-detach 2>/tmp/rsync-$$.out
   

   Then, use a separate window to actually run the failing transfer, after which you can kill the debug rsync daemon (pressing Ctrl-C should do it).

   If you are using rsync under inetd, I'd suggest temporarily disabling that and using the above daemon approach to debug what is going on.

4. Q: Why does my connection to an rsync daemon (using the "::" syntax) fail immediately with an error like the following?

   rsync: connection unexpectedly closed (24 bytes read so far)
   rsync error: error in rsync protocol data stream (code 12) at io.c(342)
   

   A: Older rsync daemons (before 2.6.3) were unable to return errors that were generated during the option-parsing phase of the transfer. Look in the logfile 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. perhaps links are not supported by the server), or some other failure (such as trying to send data to a read-only module). Upgrading the version of rsync that is running as a daemon to at least 2.6.3 will allow these errors to get returned to all rsync clients, old or new alike.

5. Q: Why doesn't --dry-run (-n) show all the changed directories?

   A: This was a bug in versions prior to 2.6.4. Upgrade both rsync versions (or at least the receiving side).

6. Q: Aren't there more issues than this?

   A: Yes. You can find some of them in the TODO file or search the bugzilla database.

Established in Love

Today's Scripture

“May you be rooted and grounded in love…” (Ephesians 3:17)

Today's Word from Joel and Victoria

Did you know there is tremendous power in love? In the same way that a tree will grow taller and stronger when its roots grow deep, you’ll be stronger and have more of God’s power operating in your life when you are rooted and established in love. Faith works by love, and I Corinthians 13 gives us a picture of what that looks like…among other things, love is patient and kind. It does not seek its own way. It is not jealous or boastful or proud. When you choose love instead of choosing your own way, you are showing that God is first place in your life. You are establishing yourself in love. The more you choose to walk in love, the deeper and stronger your roots will grow. And when you are established in love, you’ll have more of God’s favor and blessing upon your life! Choose love today, and let it be firm within you. Let that love build security in you and empower you. As you do, you’ll see God working through you, and you’ll live as an overcome in every area!

A Prayer for Today

String[] params = (String[])(ActionContext.getContext().getParameters().get("turtle"));
String userName = "";
if (params != null) {

    userName = params[0];

}

    <action name="search" class="com.google.search.SearchKorea">  

       <result name="success" type="chain">SearchInUSA</result>  

       <result name="fail" type="dispatcher">/monitor/showdefault.jsp</result>  

    </action>