[sudo-users] SIGHUP not reaching child process when closing the terminal window

[R. Diez]

>> However, if I close the terminal window with the mouse, the 'openvpn' server
>> process stays running invisibly in the background.
> 
> When a terminal goes away, the kernel sends SIGHUP to the foreground
> process group associated with that terminal.  If openvpn is in the
> foreground process group (as it appears to be), I would expect it
> to receive SIGHUP from the kernel too.

First of all, thanks for your help.

This is an interesting problem. I am using Ubuntu MATE 20.04.4, and I have been testing a number of combinations with MATE Terminal and xterm.

I have read somewhere too that the kernel will deliver SIGHUP when the terminal is closed, but I am not certain whether that would go to the process "leader" or to the whole process group. The documentation is hard to find and often not really clear.

I am looking at this page now:

https://www.x.org/archive/X11R6.8.1/doc/xterm.1.html

"quit()  This action sends a SIGHUP to the subprogram and exits. It is also invoked by the quit entry in mainMenu."

If closing the terminal would automatically send SIGHUP, why would xterm bother doing that itself? It certainly is not going to work if child processes are using sudo.


> [...]
> Things get more complicated when sudo is running commands in its
> own pty, such as when log_input, log_output or use_pty are enabled
> in the sudoers file.

That is not the case on my system.


> A keyboard-generated signal (^C for SIGINT, ^\ for SIGQUIT) is also
> sent by the kernel, which is why it works even for commands run as
> different user.  The fact that pressing ^C stops the process leads
> me to believe that this is not a sudo problem.

You are right, it does not look like a sudo problem. Just like another kind of interesting problem. 8-)


> The openvpn docs state that openvpn does a hard reset on SIGHUP,
> perhaps it is successfully reconfiguring instead of failing and
> exiting.

You are right, but OpenVPN is configured to drop privileges after connecting. Therefore, it is not going to succeed at reconnecting, so SIGHUP ends up terminating the connection and the openvpn process too.


> Could there be a race condition between openvpn and the
> cleanup you are doing in exit_cleanup()?  If openvpn is able to
> reconfigure before your script removes the TAP device it may just
> keep running.

The calling script is still waiting. I think that Bash does not process signals until the child process has terminated (unless the child is running as a background job, but that is not the case).


> To debug this further, I would try replacing the calls to openvpn
> with something like "sleep 300" and see if the sleep is still running
> after you close the terminal window.

I have done some more testing, like redirecting stdout and stderr to a file, and the 'sleep' replacement does not get SIGHUP when closing the terminal. No wonder openvpn does not either.


> [...]
> You can also try sending SIGHUP to the script's process
> group (not just the script process) via sudo to try to emulate the
> terminal window being closed.

Maybe I should start xterm itself with sudo. It may not be the most secure way, but then SIGHUP will probably work.

Regards,
   rdiez