December 6, 2004 at 6:27 am
One of our jobs using FTP to transfer data files has recently began failing. If we try and execute the same job on the other node of our active/active cluster the transfer completes correctly from the unix server. The error we are recieving is 'Connection closed by remote host.' during the login process.
If you have any ideas please speak up....We need to get this process back in production.
Thank you :: MATT
December 6, 2004 at 10:39 pm
Up to now has the failing node always been the one from which the transfer has been initiated?
What access do you have to the unix box? Can you check logs on it?
Can you log on to the separate nodes (with SQL Agent's credentials) and try the ftp manually from the command line?
Cheers,
- Mark
December 7, 2004 at 6:01 am
Yes up to now the failing node has always carried out the ftp and then the import of the transferred data. The errors are intermittent; I can not pinpoint what is causing the inconsistencies.
The user we are logging on to the UNIX box with has more than enough permissions and has not changed since the process started failing.
I can log into the other node and transfer the files with out error every time I try.
December 7, 2004 at 10:12 am
Not clear, can you log into both nodes manually and execute the job? Curious if it works manually and fails when schedules or always fails.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
December 8, 2004 at 7:16 am
The job will fail if it is run by the schedule or if the job is started manually. If I ftp in to the server from the command prompt I can recieve the files everytime from either server.
Do you think it could be a SQL Setting? OS Setting?
December 8, 2004 at 7:56 am
Sounds like the FTP is setup to only except connecions from the address of the working node. And any other location that attempts to connect is automatically rejected. Check with the FTP admin to see if that is the case. I feel 100% it is because bot manual and automatic fail the same.
December 8, 2004 at 8:04 am
I don't think that is correct, If I log in to either node I can manually FTP the files from the UNIX box. If it were an IP/address issue I wouldn't be able to connect at all from the failing node, automated or manually.
December 8, 2004 at 9:50 am
Sorry misread you previous comment.
December 8, 2004 at 10:12 am
When you log into the FTP server do a test thru command prompt are you using the same account as defined in the ftp connection of your scheduled process?
December 8, 2004 at 11:06 am
Yes, I am following the same procedure with the same login and password.
Any ideas?
December 8, 2004 at 5:53 pm
Ok going back to your first post you stated was dropped with 'Connection closed by remote host.'. If your FTP team logs there connections like they should be then see if they can pull the log for the time frame in question or manually run the process again the same way as when fails to see if the logs shine any light on it. Also check your Windows event logs to see if maybe there is an error alert with more details that might be related.
December 9, 2004 at 5:13 am
Thanks Antares, I'll try and get a hold of the guys that take care of the UNIX box we are connecting to today and see if they can check the logs and watch me logging in. I'll let you know how I make out.
:: Matt
December 14, 2004 at 8:56 am
Still no luck...seems like the ftp fails when it reaches the larger files of the job.
HELP!
December 14, 2004 at 2:16 pm
To the top.
December 14, 2004 at 2:38 pm
Although you've tried command prompt ftp from both servers, try it again on medium and larger files. A possibility is different static routes on the boxes causing slow ftp'ing in one of them and thus a timeout.
Cheers,
- Mark
Viewing 15 posts - 1 through 15 (of 44 total)
You must be logged in to reply to this topic. Login to reply