Simply try the same invocation sshuttle -D ... 2>&- | cat (with the redirect) and see how it behaves.

However, there seems to be a fundamental misconception about the workings of process environment. A shell command line does not contain or isolate the task. This is how a daemon can work in the first place: it detaches from shell and terminal and starts running on its own. You have indicated that the exit status of the command is of interest to you. But this may be largely irrelevant to the working of your service. The daemon will have forked at least once; the process writing to your pipe/stdout is the child not the $pid you forked.

Hi! Thanks for explanation. Not sure If I understood all you told here. But what I already tried and here the results:

sshuttle -D ... 2>&- - hangs, when gets run by Perl script:

$ cat test.bash
/usr/sbin/sshuttle -v -D -r vagrant@127.0.0.1 192.168.0.0/24 2>&-
echo OK

$ cat capture-tiny.pl

use Capture::Tiny qw{tee};
tee {
  system('bash test.bash');
};

vagrant@Debian-jessie-amd64-netboot:~/my/IPC-sshutle-issue$ perl capture-tiny.pl
vagrant@127.0.0.1's password:
Connected.
OK
# hangs here

The same result (hangs) with sshutle -D ... 2>&- | cat

$ cat test.bash
/usr/sbin/sshuttle -v -D -r vagrant@127.0.0.1 192.168.0.0/24 2>&- | cat
echo OK

And the same result (hangs) with #$SIG{'TSTP'} = 'IGNORE';

$ cat capture-tiny.pl

$SIG{'TSTP'} = 'IGNORE';
use Capture::Tiny qw{tee};
tee {
  system('bash test.bash');
};

Probably I do something wrong?

PS. I have not succeed with IO:Pty script example yet, as it seems a bit complicated for me.

Well, reconsidering the ps output you've shown earlier, I think what may be happening here is the service daemonizes too late (after launching its logger process). If so, the output pipe is inherited by logger and never closed on the writer(s) side.

Whatever the actual cause, I'd suggest filing a ticket with the sshuttle software vendor.