Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

FTP run by cron can't move large files

Status
Not open for further replies.

SERF

Technical User
Mar 20, 2003
3
US
Two identical UNIXWARE 7.1.1 servers with current patches and Maintenance Sets; both set for large files and ulimit at 4194303. The root cron calls script to ftp and 'get' data from production server and move it to the backup server. This works until it tries a file that is 1.86 GB in size, then it quits. It only copies over 1.07 GB. HOWEVER, I can do this manually (as user root) and it works every time! I modified the .proto file, hoping to make the system ulimit work for this cron job but this time it didn't even copy this large file. What do I do and/or did I make a mistake in editing this file:
#ident "@(#)adm:common/cmd/.adm/.proto 1.2.3.1"
#ident "$Header: /sms/sinixV5.4es/rcs/s19-full/usr/src/cmd/.adm/.proto,v 1.1 91/
02/28 15:51:58 ccs Exp $"
cd $d
if [$l -eq 4194304]
then
ulimit unlimited
else
ulimit $l fi
umask $m
$<

Thanks in advance!!
 
How are you ftp'ing the file over? Is this being called from a shell or expect script? If you can ftp the file over manually when logged in as root, then you should be able to get the file via a script without any problems. Have you enabled an audit trail to see what is happening when the script fails?
 
I had a similar problem when using rdist. I just had to change the default value so that it did not time out. Your problem may be the same. Have you thought about using rdist?
 
To PMCMICHA: We have the root cron calling a script that performs the actual ftp. How can I enable an Audit trail?

To JENNIGSRA: I had not thought about rdist; I will look into it.
 
From your crontab entry:

0 8 * * * /DIR/SCRIPT_NAME > /tmp/SCRIPT_NAME_LOG 2>&1

or

#!/usr/bin/ksh -p

exec 1> /tmp/SCRIPT_NAME_LOG
exec 2> /tmp/SCRIPT_NAME_LOG

THE REST OF YOUR SCRIPT. If you are already doing something like this, then you may need to enable &quot;set -xv&quot; in your script which can help track down the exact failure point, but I don't think you will need to for this problem.
 
Thanks people! I will have to wait to test this since the backup server just died so hard...it will be replaced. I'll close this thread and, if the issue returns, I'll try your suggestions. If I need more help, I'll be back
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top