GNOME Bugzilla – Bug 748520
Doesn't send SIGQUIT if started up in certain ways
Last modified: 2015-04-28 21:08:11 UTC
Start up gnome-terminal using Unity's default keyboard binding Ctrl+Alt+T => Ctrl+\ sends SIGQUIT to applications as expected. Start up gnome-terminal using the "gnome-terminal" command from xterm, or from Unity's left-hand Launcher, or Unity's Alt+F2 (Search) menu => Ctrl+\ does not send SIGQUIT. It locally prints ^\, but neither any signal, nor any character is sent to the application. "stty -a" reports the same in both cases. The behavior is not bound to Ctrl+\ specifically, you can redefine to "stty quit q" and then the letter 'q' will behave this way. xterm, konsole, pterm, st, terminology, urxvt all work correctly in both cases, even if launched via Unity's Launcher. Standalone vteapp seems to inherit the behavior from the terminal from which you start it. Could it be that vte forgets to initialize something which the desktop environment sometimes (but not always) happens to initialize for it?? Bugreport found here: http://askubuntu.com/questions/614779/ctrl-doesnt-work-in-ubuntu-14-04. I also had a feeling for a long time that Ctrl+\ often didn't work when I expected to, but I thought it was a problem with the apps and didn't care to investigate, my bad.
I think the behavioural difference between the launch methods should be gone with newer gnome-terminal, since the server is now always launched by dbus-demon. Does adding SIGQUIT to the list of signals reset in pty.cc:_vte_pty_reset_signal_handlers() fix the problem?
I just had to take a short break to realize that indeed the problem was the non-default SIG_IGN handler for SIGQUIT. And then I could hardly wait for almost an hour to get online again and note it here :) Indeed your proposed 1-liner is the correct fix.
Fixed; backported all the way down to 0-36.