QProcess::startDetached and bash stdout capture

[Thiago Macieira]

On sábado, 25 de março de 2017 09:03:28 PDT David Faure wrote:
> On samedi 25 mars 2017 16:50:37 CET Thiago Macieira wrote:
> > One problem is because the launched process inherits the pipes to stdout
> > and stderr
> 
> Really, even with startDetached? I assumed that was more "detached" than
> that ;)

Right, nothing in it closes stdout, because people want to see the output. 
When we're connected to the terminal, that's usually useful.

If we're connected to a pipe... not so much.

> > but the shell sees the process group it launched exiting.
> 
> I never understood much about "process group". Is it the issue here? Is the
> helper considered part of the same process group as kdialog?

startDetached does setsid(), so it starts a new session and process group. I 
have to confess not understanding SID and PGID very well either, but I do know 
that each process the shell launches is in its own process group and the shell 
waits for the process group to exit, not just the process it launched.

> > It will probably close the pipe. Normally, this process would exit soon
> > with SIGPIPE, but since a lot of code relating to sockets and pipes turns
> > SIGPIPE off, it's possible that the detached process never receives
> > SIGPIPE and simply remains forever.
> 
> I'm confused as to which one you call the "detached process" here,
> kdialog or the helper.

The helper.

> Are you saying what I need is a call to sigaction to re-enable exiting on
> SIGPIPE, in kdialog, just before returning from main()?

No, that won't help.

> Could it be related to SIGCHLD, rather? I know QProcess[Manager] plays with
> that, and it sounds like what the shell is waiting for from kdialog. But
> surely inhibiting the -receiving- of SIGCHLD in kdialog shouldn't break the
> parent shell receiving SIGCHLD when kdialog terminates?

No, SIGCHLD isn't the case here. SIGCHLD is reset to default state by exec() 
and even if it were ignored in the helper, it wouldn't make a difference.

> > > I tried close(1) like the kde4 kdialog was doing (due to forking,
> > > though),
> > > no change.
> > 
> > There's another problem: you have a race condition between the parent
> > (kdialog) exiting and the grandchild (helper) writing its information
> > before closing stdout.
> 
> No no, kdialog is the one writing to stdout. It's just writing out the dbus
> service name that it knows the helper will use.
> It's much simpler that way, it avoids all the issues you mention.

Hmm... ok, then I don't understand. I need a bit more of information.

1) does the shell read properly from kdialog and get the service address? Is 
it correct?

2) did kdialog exit? Is kialog the process in <zombie> state?

3) is the helper still running? Can you paste the ps j for it? I'd like to see 
the PGID and SID. If you can show the shell, the zombie process and ps itself, 
it would help comparison.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center