Mention 2.6.7.pre1.

[rsync-web.git] / issues.html

diff --git a/issues.html b/issues.html
index 7821e1381ca19231b004a6f14abe30c7a86f61aa..7221dced614ac7094b319753615eb6d5d9870cb4 100644 (file)
--- a/issues.html
+++ b/issues.html
@@ -11,7 +11,43 @@
 
 <li><p><b>Q:</b>
 
-Transfers die with something like
+Rsync appears hung -- what should I do?
+
+<p><b>A:</b>
+
+When experiencing a hang or freeze <b>please</b> gather the following
+information 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 on
+solaris, strace on Linux, etc.).
+
+</ul>
+
+<p>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. 
+
+<li><p><b>Q:</b>
+
+Why does my chrooted rsync daemon crash when doing an LDAP lookup for a user or
+group?
+
+<p><b>A:</b>
+
+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.
+
+<li><p><b>Q:</b>
+
+Why does my transfer die with something like the following error?
 
 <pre>rsync: error writing 4 unbuffered bytes - exiting: Broken pipe
 rsync error: error in rsync protocol data stream (code 12) at io.c(463)
@@ -33,7 +69,8 @@ figure out is <b>why</b>, and that can involve some investigative work.
 the daemon's log file to see if it logged an error explaining why it
 aborted the transfer.
 
-<p>Rsync 2.6.3 does a better job of retreiving the error from the remote
+<p>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.
 
@@ -68,7 +105,8 @@ rsync -av --rsync-path=/some/path/rsync-debug SOURCE HOST:DEST
 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.
 
-<p>If you are rsyncing to an rsync daemon, the above script won't have
+<p>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 <i>strace</i>, <i>truss</i>, or
@@ -87,8 +125,8 @@ that and using the above daemon approach to debug what is going on.
 
 <li><p><b>Q:</b>
 
-When connecting to an rsync daemon (using the "::" syntax) the
-connection fails immediately with an error like this:
+Why does my connection to an rsync daemon (using the "::" syntax)
+fail immediately with an error like the following?
 
 <pre>rsync: connection unexpectedly closed (24 bytes read so far)
 rsync error: error in rsync protocol data stream (code 12) at io.c(342)
@@ -107,13 +145,12 @@ get returned to all rsync clients, old or new alike.
 
 <li><p><b>Q:</b>
 
-Using --dry-run (-n) doesn't show all changed directories.
+Why doesn't --dry-run (-n) show all the changed directories?
 
 <p><b>A:</b>
 
-Correct.  Rsync shows most other changes, but some directory changes are
-not currently described in --dry-run mode.  Hopefully a future version
-will fix this.
+This was a bug in versions prior to 2.6.4.  Upgrade both rsync versions (or at
+least the receiving side).
 
 <li><p><b>Q:</b>