Re^2: Net::SFTP::Foreign Connection STDERR

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi.

I realize this is a very old chain but I figured I would take a chance and post a follow-on question. Identical, I think to the problem mentioned above.

I have a parent process that looks for delivery jobs to be handled and dispatches child processes to do those deliveries. The SFTP child process uses Net::SFTP::Foreign and uses STDERR redirect suggested above. The relevant piece of code looks like:

    my $host = $delivery->{HOST};
    my $ssherr = File::Temp->new or die "File::Temp->new failed";

    my %sftp_params = (
        'user'      =>  $delivery->{LOGIN},
        'password'  =>  $delivery->{PASSWORD},
        'more'      =>  ['-v'], 
        'stderr_fh' =>  $ssherr,        
    );
    if($delivery->{PORT}) {
        $sftp_params{'port'} = $delivery->{PORT};
    }

    &logPrint("connecting to host '$host' via SFTP");
    
    $sftp = Net::SFTP::Foreign->new($host, %sftp_params);
    if ($sftp->error) {
        &logFatal("unable to connect to host '$host': " . $sftp->error
+);
        seek($ssherr, 0, 0);
        while (<$ssherr>) {
            &logFatal("captured stderr: $_\n");
        }       
        return undef;
    }
[download]

My problem is that if there is a problem (remote host is incorrect, remote host has blocked access) the child process still doesn't seem to be aware of that. Output looks like:

2017/03/15 15:36:59 UnsiloManager        doing deliver 
2017/03/15 15:36:59 Deliver::SFTP        getting delivery specs...
2017/03/15 15:36:59 Deliver::SFTP        Connecting to: 'ftp.unsilo.co
+m' via SFTP
[download]

Meanwhile the parent/dispatcher process is never aware of the fact that the child/SFTP process had a problem and sits around and waits:

2017/03/15 15:36:59 main                trying to spawn child for job 
+nature_v9_n222_xml_unsilo_20170315150444.deliver
2017/03/15 15:36:59 main                spawning new child process '18
+385' 
2017/03/15 15:36:59 main                1 jobs currently running 
2017/03/15 15:37:59 main        DEBUG   child process '18385' still ru
+nning 
2017/03/15 15:37:59 main                1 jobs currently running 
2017/03/15 15:38:59 main        DEBUG   child process '18385' still ru
+nning 
2017/03/15 15:38:59 main                1 jobs currently running
[download]

So clearly there's still something wrong with the way I've coded the SFTP child process. Is there anything that someone might be able to suggest?

Comment on Re^2: Net::SFTP::Foreign Connection STDERR Select or Download Code

Replies are listed 'Best First'.
Re^3: Net::SFTP::Foreign Connection STDERR by salva (Canon) on Mar 16, 2017 at 07:45 UTC
Does disabling the redirection fix the issue? Anyway, enable debugging in Net::SFTP::Foreign as follows: `$Net::SFTP::Foreign::debug = -1;` [download] Also, disable the STDERR redirection, so that we can see the debug output from `ssh` and pass `more => '-vvv'` into the constructor to get more detailed information.	[reply] [d/l] [select]
Re^4: Net::SFTP::Foreign Connection STDERR by Anonymous Monk on Mar 17, 2017 at 13:38 UTC
Hi. Thank you for replying so quickly. As I've continued to look at this I think the basic problem is nothing more than the fact that this is an incredibly out of date machine. It was supposed to have been decommissioned last year but they keep using it. Disabling the STDERR redirect gives me behavior more like what I saw before I looked at this thread. The child/delivery process fails to connect to the remote host but doesn't know it. The SSH error message shows up in the parent/dispatcher log. Parent sees only that the child is still running. But the parent log, on top of showing that the name/service isn't known, probably tells me everything I need to know about why this problem persists: `OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ssh: ftp.unsioloX.com: Name or service not known 2017/03/17 09:21:22 main DEBUG child process '19075' still ru +nning 2017/03/17 09:21:22 main 1 jobs currently running 2017/03/17 09:22:22 main DEBUG child process '19075' still ru +nning 2017/03/17 09:22:22 main 1 jobs currently running` [download] Probably just another reason for them to abandon this thing. D	[reply] [d/l]