Re^4: Handling STDERR when using Net::OpenSSH

I mean I have an apache application, using CGI::Fast (which uses FCGI). This application is working happily.

Now I'm trying to add a request handler that upon receiving a request via apache, it will attempt to use Net::OpenSSH to connect to a remote host

The issue is FCGI / CGI::Fast have captured and redirected the STDIN/STDOUT/STDERR filehandles and Net::OpenSSH dies when I try to create a new Net::OpenSSH object

Abbreviated code below

use CGI::Fast;
while (my $r = CGI::Fast->new) {
        open my $stderr_fh, '>', 'some_file';
        open my $stdin_fh, '<', '/dev/null';
        open my $stdout_fh, '>', 'some_other_file';

        my %options = (
                batch_mode => 1,
                timeout => 10,
                kill_ssh_on_timeout => 1,
                default_stdout_discard => 1,
                default_stderr_discard => 1,
                master_stderr_fh => $stderr_fh,
                master_stdout_fh => $stdout_fh,
        );

        my $ssh = Net::OpenSSH->new('test@192.168.0.123', %options);
}
[download]

The errors invariably occur inside the Net::OpenSSH->new() call

Comment on Re^4: Handling STDERR when using Net::OpenSSH Download Code

Replies are listed 'Best First'.
Re^5: Handling STDERR when using Net::OpenSSH by salva (Canon) on May 22, 2018 at 08:58 UTC
Try with `default_stdin_fh => $stdin_fh`. Also, enable debugging in order to see what is happening: `$Net::OpenSSH::debug=127;`.	[reply] [d/l] [select]
Re^6: Handling STDERR when using Net::OpenSSH by Anonymous Monk on Jun 01, 2018 at 00:44 UTC
Even with default_stdin_fh set, I still get the error Operation 'OPEN' not supported on FCGI::Stream handle at \/usr\/share\/perl5\/Net\/OpenSSH.pm line 761. STDERR output from debug doesn't show anything obviously informative to me? open_ex: ['ssh','-V'], referer: http://127.0.0.1/test_ssh.pl io3 mloop, cin: 0, cout: 1, cerr: 0, referer: http://127.0.0.1/test_s +sh.pl io3 fast, cin: 0, cout: 1, cerr: 0, referer: http://127.0.0.1/test_ss +h.pl stdout, bytes read: 60 at offset 0, referer: http://127.0.0.1/test_ss +h.pl io3 fast, cin: 0, cout: 1, cerr: 0, referer: http://127.0.0.1/test_ss +h.pl stdout, bytes read: 0 at offset 60, referer: http://127.0.0.1/test_ss +h.pl leaving _io3(), referer: http://127.0.0.1/test_ssh.pl waiting for slave, timeout: 10, remaining: 10, sleep: 1, referer: htt +p://127.0.0.1/test_ssh.pl _waitpid(27399) => pid: 27399, rc: 0, err: Interrupted system call, r +eferer: http://127.0.0.1/test_ssh.pl OpenSSH version is 7.2p2, referer: http://127.0.0.1/test_ssh.pl ctl_path: /tmp/.net_ssh/monitor-192.168.0.12-27394-236253, ctl_dir: / +tmp/.net_ssh/, referer: http://127.0.0.1/test_ssh.pl set_error(0 - 0), referer: http://127.0.0.1/test_ssh.pl call args: ['ssh','-o','ConnectTimeout=10','-o','ServerAliveInterval= +10','-o','ServerAliveInterval=30','-o','ControlPersist=no','-2MNx','- +o','BatchMode=yes','-i','/tmp/.5SFO0niU.27394.key','-o','PreferredAut +hentications=publickey','-S','/tmp/.net_ssh/monitor-192.168.0.12-2739 +4-236253','-l','monitor','192.168.0.123','--'], referer: http://127.0 +.0.1/test_ssh.pl master state jumping from _STATE_START to _STATE_AWAITING_MUX, refere +r: http://127.0.0.1/test_ssh.pl file object not yet found at /tmp/.net_ssh/monitor-192.168.0.12-27394 +-236253, state:_STATE_AWAITING_MUX, referer: http://127.0.0.1/test_ss +h.pl DESTROY(Net::OpenSSH=HASH(0x5db2ac0), pid: <undef>), referer: http:// +127.0.0.1/test_ssh.pl set_error(1 - aborted), referer: http://127.0.0.1/test_ssh.pl master state jumping from _STATE_START to _STATE_GONE, referer: http: +//127.0.0.1/test_ssh.pl [download]	[reply] [d/l]
Re^7: Handling STDERR when using Net::OpenSSH by salva (Canon) on Jun 01, 2018 at 08:34 UTC
Ok, I see what is going on here: FastCGI passes as STDERR a tied file handle and when `Net::OpenSSH` tries to reopen it, the operation fails, probably because the file handle class is missing some method. I have created a new issue on the module bug tracker: https://github.com/salva/p5-Net-OpenSSH/issues/24. I would try to fix it over the next weeks.	[reply] [d/l]