From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.8.1+) Gecko/20010430 Description of problem: We mirror the root partition of a machine onto a partition using the rsync command. The command hangs at the end of the run: [root@xpc1 jss]# rsync -raHxv --delete / /root_backup/ building file list ... done boot/ etc/ [....] var/run/ var/run/utmp var/yp/binding/ var/yp/binding/xxxxxxxx.1 var/yp/binding/xxxxxxxx.2 [hangs here] looking to see what's running.... [root@xpc1 jss]# ps auxw|grep rsync root 10228 1.6 2.4 13512 12576 pts/6 S 12:14 0:04 rsync -raHxv --delete / /root_backup/ root 10229 3.7 6.2 32800 31876 pts/6 S 12:14 0:11 rsync -raHxv --delete / /root_backup/ root 10231 0.0 6.2 32800 31884 pts/6 S 12:16 0:00 rsync -raHxv --delete / /root_backup/ [root@xpc1 jss]# strace -p 10228 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) gettimeofday({990703222, 596410}, NULL) = 0 wait4(10229, 0xbfffdd60, WNOHANG, NULL) = 0 gettimeofday({990703222, 596485}, NULL) = 0 gettimeofday({990703222, 596508}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 20000}) = 0 (Timeout) gettimeofday({990703222, 616448}, NULL) = 0 select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout) gettimeofday({990703222, 626474}, NULL) = 0 wait4(10229, 0xbfffdd60, WNOHANG, NULL) = 0 [lots more....] Stracing PID 10229 fixes the hang!!!! How reproducible: Sometimes Steps to Reproduce: 1. Don't know - now the rsync has completed properly once, it now works every time. 2. 3. Additional info:
Discussion on Linux-kernel, see http://marc.theaimsgroup.com/?t=99235486900004&w=2&r=1 The problem appears rsyncing a kernel tree on a local disk to a local disk. This in _not_ an ssh problem!
This bug appears to be fixed with the following patch: http://www.clari.net/~wayne/rsync-nohang.patch
Added in 2.4.6-3; thanks!
We also try to mirror nearly 63 GBytes from a RAID 5 SCSI system to a local IDE harddisk, the dist is RH 6.2 with 1 GB RAM, so memory or ssh shouldn't be the problem. I also tried rsync 2.6.4 with the ~wayne/rsync-nohang.patch applied, but the process still hangs in an undeterministic way. In the rsync mailing list I read this email http://www.mail-archive.com/rsync@lists.samba.org/msg01494.html which stats that the verbose switch can be responsible for some kind of hangs. Since I left out the -v switch the script with rsync -Ha --delete --stats --timeout=10800 --delete-excluded --exclude-from=$excludefile /export/ /export-backup runs fine. We think that the verbose option brings rsync into a dead lock situation when the filelist will be very big (ours is about half a million files on a very fast raid system. So I think you should this bug be open and not resolved. Andreas
Well, after nearly 4 weeks of testing the 2.4.6 version with the ~wayne/rsync-nohang.patch applied, the hang hasn't appeared again with or without the -verbose option. I would like to ask you to release this rsync version as an official errata for 6.2 and above. Thanx!
I have experienced rsync problems yesterday for the first time in my life. It's not exactly on RedHat Linux but I guess it's related so just let me describe what happend. I modified some file trees on my main ftp server (RH 6.1). What I did exactly was to put some directories from the SAP DB 7.3 distribution CD - which is GPL - on my ftp server containing hundreds of sudirectories and files. I then wanted to rsync the ftp onto my laptop (Mandrake 7.2 on ReiserFS) by mounting the ftp volume and then doing a rsync -av --delete /mnt/nfs/unix/Linux /home/ftp/pub/software. The command was hanging several times. I went home and wanted to rsync over to my server which is SGI XFS RedHat 7.1 with the RH-XFS-2.4.3 kernel and kdb enabled. After syncing some files I was dropped into kdb. I have right now tried the rsync from RH6.1 to MDK7.2 without the -v option and it works!!! I will remove the verbose option from my scripts now.
Does 2.5.0 (http://people.redhat.com/notting/rsync/) work for you?
closing, no response
Sorry - I obviously forgot to reply last year! I've been using the RH 7.3 rsync with no problems for some time now.