Child processes not killed when bash.exe window is closed through GUI

[serrearthur]

I have noticed a bug that happens on my very specific environment : when I click the 'close' button on the upper right corner of the bash.exe window, the terminal is closed, but its child processes remain alive, and are visible from the task manager.

Now, as I said, I use a very specific setting. As I was tired of having to relaunch ssh-agent everytime I launched a new bash.exe window, I decided to create a pseudo-service, as shown in my github repo.

With this setting, I took the following steps :

• Launch the ssh-agent task as shown in my repo
• Launch bash.exe
• Launch a few programs (in my case : tmux and top)

Output :

Now, close bash.exe by clicking the 'close' button in the upper right hand corner of the window.

• The child processes still exist in memory
  
  (Note : you can notice that one instance of tmux is gone. Executing bash.exe -c 'top' from an elevated cmd.exe shows that tmux:server is still alive while tmux:client was killed)

I believe this is caused because when the task ssh-agent is launched, it creates an instance of 'Microsoft Bash Launcher'. Any further bash.exe child processes are executed from this instance. When the windows are closed, as the bash launcher instance is still alive, the child processes keep running.

Should this be considered a bug ? As of now, is there a way around this behaviour ? Is there a way to guarantee that any new instance of bash will kill all of its child processes if closed, while not disturbing the other instances ?

Windows version: 10.0.17035.1000

[onomatopellan]

https://msdn.microsoft.com/en-us/commandline/wsl/release-notes#build-17046
You should test latest build 17046 which allows processes to run without an active terminal.

[therealkenc]

WSL as of 17046 now works more like Real Linux. Careful when you say "will kill all of its child process if closed" because it isn't a straightforward thing. It depends on how the program in question responds to SIGHUP. If for example you do:

$ sleep 100 &

If you exit that bash session (contrast WSL instance) by typing exit at the command line, you will find sleep still running, reparented to init and without an associated tty. If on the other hand you close the window, sleep will get a SIGHUP and exit, by choice. And by exit I mean _exit(), which is different than being killed with say SIGTERM or SIGKILL.

Duping into #709 as a landing zone because we've got about half a dozen github threads going on the subject.

[bonellia]

I personally prefer it to be this way.
I am using ssh tunneling and thanks to that I don't have to have terminal window open in order to keep my ssh connection alive.
I have noticed that this is different than WSL.
I thought this is probably intended.
I can also imagine this being handy if you are running a web server in bash, haven't tested it though.