<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY LINK="#0000ff">
Thanks for the reply. No, no chance of running out of space. <BR>
<BR>
Yes, if I could find the original scp invokation, I could save the return code, assuming scp posts a different return when it doesn't succeed. And as you note, I could run a sum or md5sum and send that along. I've got host-ssh equivalence, so I could do some comparison. Although as Jim noted, you can only chase squirrels so hard and so long. <BR>
<BR>
On Mon, 2017-08-07 at 16:48 +0000, Lightner, Jeffrey wrote:
<BLOCKQUOTE TYPE=CITE>
Any chance the filesystem on the backend server has gone temporarily full around the time you do the scp’s that have the issue? You’d see it in /var/log/messages if it happened. <BR>
<BR>
<BR>
<BR>
One thing you could do to avoid finding this later and manually resending is put your scp inside a script and before the scp run md5sum on the file that is being sent then after the scp run md5sum (via ssh) on the backend server and compare the values. If they’re not the same have the script resend and check the md5sum again. You could try it multiple times (e.g. 5 with appropriate pauses between attempts) then have it send email to you on last failed attempt.<BR>
<BR>
<BR>
<BR>
We use sftp/scp fairly heavily here on RHEL5/RHEL6 and I’ll have to say I’ve never run into much trouble with the actual file transfers. Having said that I will say I have a preference for sftp usually and it may have its own built in retransmit of packets like the old ftp did. I’m not sure scp does that.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<B>From:</B> ale-bounces@ale.org [mailto:ale-bounces@ale.org] <B>On Behalf Of </B>Neal Rhodes<BR>
<B>Sent:</B> Monday, August 07, 2017 12:08 PM<BR>
<B>To:</B> Atlanta Linux Enthusiasts<BR>
<B>Subject:</B> [ale] very intermittent weird SCP failure?<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
We have a client running a ----------------------------- application on three linux servers running <BR>
<BR>
Linux HDISATBE3 2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux<BR>
<BR>
The two primary event servers accumulate a file of connection/heartbeat activity, and once a week, a crontab job does an SCP of this file to the backend server, which imports these two files to calculate uptime. The respective user has ssh host equivalence, so this proceeds without password challenge. <BR>
<BR>
This has worked for about 10 years. <BR>
<BR>
Very occasionally, like, once in 3 months, we will find the copied file on the backend server is garbled, to wit: <BR>
<BR>
- total size is correct; matches source<BR>
- the first XXX bytes of the file is NULL characters. <BR>
<BR>
Which hoses up everything. I usually figure out which file is boogered, re-do the scp by hand, and re-do the import. Then all is well. <BR>
<BR>
I am just bumfuzzled as to what would cause this. It's always on the front of the file. <BR>
<BR>
I should check and see exactly how many NULLS, but usually when it happens my hair is on fire. I'm guessing about 512 or 1K. <BR>
<BR>
Neal Rhodes<BR>
MNOP Ltd<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
_______________________________________________
Ale mailing list
<A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
<A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
See JOBS, ANNOUNCE and SCHOOLS lists at
<A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>