search for: ewhiting

Hi All, I've got a cron-run rsync (2.4.6) hang on both sides (solaris to solaris). The platform is: SunOS 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-80 Sorry if this has been asked before, for I couldn't find a searchable archive for this list on . Regards, Jie

I'd very much like to get a stable 2.5 release out so that people can upgrade their production machines with confidence and so that distributors can freeze it. I know some people are still running 2.4.6 (+backports) for understandable reasons, but it would be good to give them the option to upgrade and avoid the hang bug. After this we can perhaps move on to 2.6 and be a bit more liberal in

Howdy, We occassionally get the following error when running our nightly backups: rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229) This happens more on one or two machines than on any of the others. We've looked high and low to see if we're mistakenly sending these signals, but nothing is that we can find. Does anyone know what this might be from? Is it the server

Rsync version 2.6.1 has been released. It is primarily a performance release that requires less memory to run, makes fewer write calls to the socket (lowering the system CPU time), does less string copying (lowering the user CPU time), and also reduces the amount of data that is transmitted over the wire. There have also been quite a few bug fixes. See the release NEWS for the full details:

Rsync version 2.6.1 has been released. It is primarily a performance release that requires less memory to run, makes fewer write calls to the socket (lowering the system CPU time), does less string copying (lowering the user CPU time), and also reduces the amount of data that is transmitted over the wire. There have also been quite a few bug fixes. See the release NEWS for the full details:

Martin, Just a minor fix. Jie, Try the -r option (or the --recurse) option instead. It looks like the source changed to this: options.c: {"recurse", 'r', POPT_ARG_NONE, &recurse}, But the help is still at: options.c: rprintf(F," -r, --recursive recurse into directories\n"); eric Jie Gao wrote: > > rsync: --recursive:

I'm syncing from a linux box (NAS disk) to a sun (NAS disk). I just found a file on the destination sun with zeros from bytes 8192 to 32767. (the source file had lots of 'good' random bytes). The rest of the file compares properly. Repeatedly running rsync to send the file didn't fix it. I ran a -c transfer (checksum) and it fixed the file. I'm using 2.5.3 on both sides with

I still see 2.5.5 hangs where the destination rsync exits (for whatever reason -- I don't see any errors) and the source waits on something forever. The interesting thing about it is when I strace the child rsync pid on the source side then rsync exits as it should. Strace must introduce a timing delay of some sort that allows one of the processes to properly detect the end of channel. I

Some new data on my rsync hangs: I run about 1500 rsync sessions over ssh daily. In the last 8 days that adds up to about 12k rsync sessions. Of those 12k sessions, 10 are right now sitting in a hung state. The rsync process on the destination has exited, but both rsync processes on the source are still running/waiting/hung. I use a timeout of 3600 (but this doesn't seem to work for this

rsync (2.5.[67]) --delete fails on dirs with the w bit cleared. (example below) Rsync will sync a dir with w bit clear, but will not remove it with --delete. This is not a big problem, but it will create situations where there are 'orphaned' files. Has anyone else had this problem? It looks like a change would be needed in robust_unlink (util.c). This function would have to do a chmod