"Corrupt file" error messages
jw at pegasys.ws
Sat May 24 08:25:25 EST 2003
On Thu, May 22, 2003 at 06:16:56PM -0400, April Carvalho wrote:
> Let's try this from scratch:
> I've been having a problem for the past several days with
> a shellscript that has been working without problems
> for the 11 months.
> It's working until the comes up with the following error:
> total: matches=349 tag_hits=4061 false_alarms=1 data=6628073
> ERROR: file corruption in public_html/reports/analog/analog.conf. File
> changed during transfer?
> I've tried deleting some of these files, renaming them, and using the
> --checksum switch (along with verbose, and progress switches) in hopes
> that something else will be said. The ironic thing about these files
> is that they haven't been changed since March 03.
> Here are the specifics of the syncs:
> -Sending server & receiving server is running Debian 3.0 Woody
> (No windows involved)
> -Both servers are running rsync 2.5.6
> -sync is happening over internal network.
> -All the files in question are the same one: analog.conf. It
> is a configuration file for a bot that checks our sites. There's
> about 75 copies of the same name, but only 12 errors are showing.
> I'm assuming everytime I'm getting this error that it is a different
> file and not trying the same file over again.
The basename being the same is irrelevant. Are the files
themselves the same (same path)? The reason for the
question was to see if it might be something specific to the
> Since this first post, the error has increased to 30 error messages--
> all with files for the same name.
Ahh, progressive degeneration. That sounds more and more
like a hardware problem. Rsync stresses systems such that
it is often what uncovers hardware failures. This has the
earmarks of a transient hardware failure such a bad ram or
timing problems. Unfortunately rsync has no way of knowing
which end is faulty.
Here are a few selections from my catalog of what to look
for if hardware may be failing:
Start by checking the system logs. In particular
check for disk related errors and for oops.
While not conclusive running memtest overnight would
be a good idea.
Check the CPU temperature and that all the fans are
working correctly. Also that there isn't much dust
inside the machine.
Reseat your RAM.
You might try underclocking.
If a power supply is over a year old replace it. PC
power supplies are mostly cheap junk and when the PS
starts to go it generates bad power levels that
stress the components. PS failure is responsible
for most systems dying.
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync