In my project we use sftp with batch mode (password less) script in parallel for 14 sessions which connects to 2 different servers alternatively i.e. 7 connects to one server say server1 and the other 7 connects to say server 2.
Now the problem is that these 14 sessions are run in parallel then only 2 or 3 of them get succeeded while the rest runs for a very long time like 2 hours and then gets timed out. The unix admins told that sftp script is not closing the connection gracefully.
The command which I use in the sftp script is
sftp -b <batch file> user@ftp_address
They told me to check if the connections are closed or not can be checked by command. So I executed the below command even when the sessions were not running.
netstat -an | grep <IP address of the GUI tool which calls the script>
This shows something like below:
tcp 0 0 ::ffff:XXX.XX.XXX.XX:XX ::ffff:YY.YYY.YY.YYY:ZZZZ ESTABLISHED
tcp 0 0 ::ffff:XXX.XX.XXX.XX:XX ::ffff:YY.YYY.YY.YYY:MMMM ESTABLISHED
And seeing the above "ESTABLISHED" o/p they are claiming that my script is not closing the FTP connection!! I'm really confused as to how to close the SFTP connection when using it in batch mode there is no explicit command like "bye" with password-less sftp. Can anybody please help me understand that if the unix admins are right in their claim that really my script doesn't close the connection automatically and if yes then how to close it?
Sorry I couldn't reply earlier. But I really want to thank you as your solution worked and now the 14 parallel sessions accessing the same FTP connection alternatively is working fine. :):)
There's one more thing I wanted to ask you, that is if you can spare some more time, is that after running the scripts with "quit" command in the batchfile now my earlier scripts (w/o "quit") are also working fine!!
Can that be because contention of the connections got solved with the "quit" cmd? And the "parallel thing" will work until the Max Connection limit to FTP site is met?
-dips
P.S. I apologize for the subject of my post being non-descriptive. I'll surely remember that in future.
UNIX servers usually have default network TIMEOUT set to values that were from the times of 10Mb networks... In other words the times when you could unplug and move around cables without taking too much risks of seeing the server crashing (complaining at the most) then came interconnection with WIN.. serversin multi-tier environment and users on PCs with 100Mb/1GB lan interfaces and things changed a bit: admins started to have strange issues where people couldn't connect anymore, application were no more responding... due to no more sockets etc... because e.g for the case of PCs, when no more activity for a little time the PC closed the connection and when activity started again -opened a new one... On the UNIX side though the connection did not get the close request and stayed in a zombiesque state till the server cleared the TIMEOUTs. We were talking of second on one side and minutes on the other...
So your understanding is correct...
It shows that things you write that work may still be buggy... And needs to be tested thoroughly and be sure of the correctness of code (you open an ftp session - you closed it behind...) for even if the code is perfect the usage of it may have side effects:
Now you code is correct. What will happen if you send hundreds of parallel sessions with big transfer? We had one case where all the switches dropped in cascade...
