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
