I have also posted this question on unix.com
On Oracle Linux 5, 64 bit
I have a shell script that runs every Sunday, that ftp's a bunch of files from server 'prod' to server 'test'. Files are rman backupsets. Script executes on 'test'. This has been running for YEARS with no problem. Normally the FTP step takes about 1.5 to 2 hours. (pulls a lot of fairly large files). The only actual 'get' command is a single mget with a wild card file spec, so it is never looking for a specific file, just everything in the source directory.
This last weekend we physically relocated the data center. Packed up servers, SAN, etc, trucked it a few miles, and put it all back together. Everything from that seems to be working fine, but it needs to be said in the interest of full disclosure of "what's changed".
So, on Sunday, due to the move I'm watching things a lot closer, and this job is still in the ftp step at 17:30 -- about 2 hours overdue. And the log file it writes (redirecting stdout) has a time stamp of 15:30 - so nothing written to it in 2 hours. At that point I killed the job.
As a diagnostic, and to give real-time visibility to my network admin, I kicked of the job again yesterday afternoon just before leaving for the day. This morning it was still 'running'. It was stuck at the same file as was the original run. This file is neither the first nor last to be transferred. It is neither the first nor the last one created by the job that created it. The creating job reported no issues. Permissions on the file are the same as all the others. I'd think if the file were internally corrupted, ftp wouldn't really know or care, he's just reading whatever is there.
The only thing I've got back from the net admin was pointing out that both runs hung on the same file -- something I had not noticed.
I'm not sure where to turn next and am open for any ideas.