I *believe* I have created a much simpler method of reproducing the issue without all of my software necessary. It appears as though on AWS Windows 2012 servers, a ENTER keystroke is required on the server part of the setup before the cpanm gets executed. This is not required on my local win2k8R2 servers.

If it runs through without having to hit ENTER on the server.pl cmd window, that's what I see on my local boxes.

To repro:

- copy below code to client.pl and server.pl respectively
- start the server in the background: 
-- perl server.pl bg
- run the client (different cmd window):
-- perl client.pl
[download]

On my local servers, the server returns to the client properly without any interaction. On my AWS systems, it hangs exactly like my original problem. Hitting ENTER in the server cmd window causes things to go through.

NOTE: there's no method in this test code to stop the server.pl background proc. It has to be killed via Task Manager.

client.pl

use warnings;
use strict;

use IO::Socket::INET;
use Storable;

my $mod = 'IO::Socket::INET';

my $sock = new IO::Socket::INET (
    PeerHost => 'localhost',
    PeerPort => 7800,
    Proto => 'tcp',
);
die "can't create socket\n" unless $sock;

$sock->send("cpanm $mod");

my $recv = Storable::fd_retrieve($sock);

print $$recv;
[download]

server.pl

use warnings;
use strict;

use IO::Socket::INET;
use Proc::Background;
use Storable;

if (@ARGV && $ARGV[0] eq 'bg'){
    Proc::Background->new('perl', $0, 'run');
}
if (@ARGV && $ARGV[0] eq 'run'){
    my $sock = new IO::Socket::INET (
        LocalHost => '0.0.0.0',
        LocalPort => 7800,
        Proto => 'tcp',
        Listen => 5,
        Reuse => 1,
    );
    die "cannot create socket $!\n" unless $sock;

    while (1){
        my $conn = $sock->accept;

        my $cmd;
        $conn->recv($cmd, 1024);

        print "executing: $cmd\n";
        my $ret = `$cmd`;
        print "return: $ret\n";
        Storable::nstore_fd(\$ret, $conn);

        shutdown($conn, 1);
    }

    $sock->close;
}
[download]

Thanks for the suggestion BrowserUK, but unfortunately, the effects are the same... with system 1, ..., the tester proc goes into the background, and when accessed, the ensuing perl process that calls cpanm hangs like it does with Proc::Background.

I've never seen system used with the 1 before. Without it (ie. system $perl ...) it works fine, but the process doesn't go into the background (the system call waits). Where is this documented? Unless I'm missing it, I don't see it in system or exec.

Anyway, I'll keep at this issue for a bit longer, then I'll open an AWS ticket to see if they'll actually help me debug this problem. Perhaps they already know about forking issues...

I've never seen system used with the 1 before. Without it (ie. system $perl ...) it works fine, but the process doesn't go into the background (the system call waits). Where is this documented?

Sorry, I'm not sure I've ever seen it documented anywhere. I learned it here 10 o r11 years ago -- probably from Tye -- and used it ever since.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

See "system(1" in perlport#system