Bugzilla – Bug 719
Should relay SIGHUP when sudo isn't the child of a shell, but doesn't
Last modified: 2015-11-01 15:25:46 MST
xterm -e sudo cmd When xterm closes, cmd won't receive a SIGHUP. The same thing happens if you exec sudo something from an interactive shell, in an xterm or an ssh session. workaround: xterm -e sh -c 'sudo cmd; true' sh exits on SIGHUP, causing the other processes on the tty to receive SIGHUP. This is the semantics that sudo assumes. See http://stackoverflow.com/a/32528498/224132 for a more details, and source for a signal-catching test program.
Forgot to add, this is on Ubuntu 15.04. sudo 1.8.9p5-1ubuntu5 $ sudo --version Sudo version 1.8.9p5 Sudoers policy plugin version 1.8.9p5 Sudoers file grammar version 43 Sudoers I/O plugin version 1.8.9p5
Sudo is assuming that the kernel will send SIGUP to the process group associated with the controlling tty and not just the controlling process. While keyboard-generated signals like SIGINT and SIGQUIT are delivered to all processes in the process group, the same is not true of SIGHUP when the tty is closed.
Created attachment 460 [details] Diff to relay SIGHUP when not running the command in a pty See also https://www.sudo.ws/repos/sudo/rev/b408a792f31a
Fixed in sudo 1.8.15