GNOME Bugzilla – Bug 732120
Kills background process without confirmation
Last modified: 2015-03-23 10:05:12 UTC
Start gnome-terminal, start 'emacs &' Close the gnome-terminal window/tab with the X button. There's no confirmation dialog (as opposed to when 'emacs' is running as a foreground process), yet emacs is killed. Expected behavior: emacs should be killed, because that's what happens if you run 'emacs &' from an xterm. But a confirmation dialog should first pop up.
Konsole gets it wrong, too. There are at least three states in which emacs can be: 1. It's the foreground job of the terminal (started without '&', or started with '&' and later brought foreground with 'fg'). G-t is able to tell this and asks for confirmation. 2. It's not the foreground job, but somehow still belongs to the terminal (started with '&', or started without '&' but suspended with '^Z' and probably sent to background with 'bg'). This is the problematic case. I don't even know if g-t sends the signal directly to emacs (or to a process group of which emacs is a member of) or bash sends it to emacs. It's to be studied what happens exactly, and if we can tell if there is such a process at all. 3. Emacs has nothing to do with the terminal, e.g. after a 'disown' or started from elsewhere, it obviously won't get killed. Currently we can differentiate '1' from {either '2' or '3'}. Instead, we'd need to differentiate {either '1' or '2'} from '3'. I can't tell at this point if it'll be possible at all.
Looks like a duplicate of bug 168320 chpe specifically kept it open for the background process case.
*** This bug has been marked as a duplicate of bug 168320 ***