Re^4: Net::SFTP::Foreign works intermittently

[JustPerl]

The password is correct as it is the same password which works smoothly for all the successful attempts. Shouldn't it work for a failed attempt too? There is no such other server which is listening on the same address. Also, I am creating these sftp connection objects from a script, which runs as a daemon/background job. And am invoking 10 such jobs or gearman worker threads. These worker threads listen to a webservice call. Whenever, there is a webservice call, one of the available worker threads serves the request, downloads the file from the remote server and does some processing. do you see any issue with spawning such number of worker threads which create the sftp connection objects? Please let me know.

[salva]

Do all the tasks involve connecting to the same server with the same authentication credentials? or are there several servers or credential settings?

How does Gearman Perl workers run at the OS level? are they threads inside some master process or are they different processes?

There could be some race condition on the PTY allocation as performed by IO::Pty. Try the strace thing.

[JustPerl]

Yes, all the tasks are connecting to the same server with the same authentication credentials. And each Gearman worker runs in its own process. Can you tell me on how to run the strace thing? any examples.

[salva]

How many workers are you running in parallel?

OpenSSH server has a configuration directive (MaxStartups) which allows to limit the number of not-yet-authorized connections. The default value is 10.

Regarding strace, as root run:

echo 0 > /proc/sys/kernel/yama/ptrace_scope

Then you can attach strace processes to your workers adding the following code to them:

system "strace -f -o /tmp/strace.$$.out -p $$ &";

That will dump all the OS calls to the file strace.$$.out. There, you should be able to see the Perl process writing the password to the master pty side and the ssh process reading it from the slave side.

[salva]

Could you try to reproduce the problem with some variation of the script here?

[salva]

Setting $IO::Tty::DEBUG = 1 may also show some interesting stuff.