Interesting how? You have already called out the problem in that thread.
... there is no any special about besides it probably demonizes improperly. However this could be considered as example of such a "bad" external programs which Capture::Tiny interacts whit by IPC and which make it hangs ... Anyway probably we need to investigate this more ...
In general, we don't need to investigate, it is upon you to provide a SSCCE or distill the bug for upstream report.
- If you anticipate the need to run "bad" external programs, use the necessary precautions and containment.
- If the program fails to properly redirect stderr when daemonizing, use a workaround a la foo -D 2>&-
- Alternatively, look for other, well-behaved software to replace the broken tool.
| [reply]
[d/l] |
Hi, sure ! If it is the issue on sshuttle side, then well, nothing to do here. I am just not 100 % sure. this is why I raised an github issue as well as asking some help here in this thread.
By saying "we" I did not mean a capture::tiny developers or whoever personally, I just meant that the issue needs to be investigated in general, to indentify a real cause of it.
| [reply] |
As evidenced by the sshuttle ... | cat test, the problem is indeed unrelated to perl. The sshuttle is a python program. Why have you chosen to raise the github issue with Capture-Tiny instead of sshuttle?
I've already hinted on three possible workarounds you could use on the perl size, that may or may not work at all. (Ignore SIGTTIN SIGTTOU before exec; Explicit redirect/close(STDERR); Setting up the task as session leader via IO::Pty.) Did you try any of these?
It is unlikely anyone on PerlMonks is going to debug python programs for your benefit or amusement. And we cannot Chuck Norris(*) your code.
| [reply] |
And ... Imho the issue is quite accurate described in github , you may find all the details here ...
| [reply] |