On Thu, Apr 10, 2014 at 05:03:33PM -0300, Amadeus Folego wrote:
> I probably discovered why this happens.
>
> The WM_DELETE_WINDOW command is being received with success, I tested
> it.
>
> The issue is that the command xmonad uses to spawn st double-forks the
> process, making the SIGHUP signal not being sent to the correct pid. See
> [1].
>
> So the question remains if we should cover this case or not, since
> xmonad's approach is probably nonsense. I never experienced this with
> other applications though.
>
> [1]: http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Core.html#spawn
>
How would the way in which st was started interfere with its ability to
kill the process it spawned?
No, you have to take a step back: What is the problem here? mutt is not
being killed. mutt, however, runs inside the shell that runs inside st.
And you quit st. So, what happened?
st reacted to the DELETE_WINDOW message by killing the shell with
SIGHUP. Now, your shell may ignore SIGHUP, since it is waiting for mutt
to finish. Or it may die. If it died and sent mutt the SIGHUP, too, that
would be great, however, some shells don't send SIGHUP on exit by
default, and some users don't want that.
However, I don't understand why mutt doesn't just die of "end of file".
I mean, its in- and output are the pseudo terminal slave, right? st is
the only process having the corresponding master open, and when it
exits, it closes that master implicitly. Shouldn't the PTY react just
like a pipe in that case? Read on broken pipe means EOF, immediately.
But maybe mutt isn't written to take EOF into account when reading.
In short: st doesn't care for its PPID. And neither should it.
Or maybe I misunderstood you, and you mean you have a double forking
shell command (i.e. st forks a shell command, which in turn forks and
then exits). That would cause st to exit as soon as the shell command
does (single-forked shell exits -> SIGCHLD to st -> waitpid() ->
exit()). Or you have a needlessly convoluted shell which double forks
and keeps the single-forked process running, waiting for the parent
process. Maybe even catching or ignoring SIGHUP in the process. But that
would just be broken on purpose.
Ciao,
Markus
Received on Tue Apr 15 2014 - 18:44:29 CEST