Sorry to waste your time - I will stop using rsync
tm at well.com
Mon Sep 9 01:55:01 EST 2002
At 09:36 PM 9/8/2002 -0400, you wrote:
>I agree often if the kernel crashes, though the kernel should be well
>protected enough to only crash the application process, and not damage
>itself, often the kernel flaw is stimulated by an errant or out of range
>value in it's input which woudl cause the user process to crash if the
>kernel did not.
>That said, to clarify to them. Did the whole server machine crash ie: the
>kernel, or just the rsync process or login process it was invoked from?
I had 2 SSH threads running to the machine (on eth0 192.168.1.0/24), they
were being used to issue commands, look at logs and review progress. I was
usually not logged in at console.
When rsync/kernel/hardware crashed I would find that my remote SSH consoles
would go dead and all online http tasks would not respond either (on eth1).
The main console was still at the login: prompt, and if I entered a name
and hit return, it would echo the name and return, but never get to the
What was interesting is that as I incrementally rebooted, fsck'd and did
succesive snapshots, I eventually ended up with a complete 2gig copy of my
root filesystem, and rsync exited normally from that run. But the next run
it crashed on a 680 megabyte logfile, which I renamed so it was no longer
going to be open. Next run it gave me the reported error message on a
smaller, but also presumably open, logfile.
Here is the command from my scipt:
-va --delete \
/. $SNAPSHOT/daily-0 ;
Lets see, oh... /proc/version
"Linux version 2.4.10-4GB (root at Pentium.suse.de) (gcc version 2.95.3
20010315 (SuSE)) #1"
More information about the rsync