WSL process tree survives a taskkill

[hurricup]

Windows Pro 1703, build 15063.608

Installed WSL and ruby inside it. Generated ruby rails application.

Starting it from the windows with:
bash -c "rails server -b 127.0.0.1 -p 3000 -e development"

Looks like this:

From other bash's htop I see:

If I press Ctrl-C in the bash i've started server - everything works as expected:

But, if I'm using taskkill /pid WIN_BASH_EXE_PID /f /t, bash dies, but process tree does not:

Suddenly, init with pid 1 becames a parent of the process launched with killed bash. If all bash windows are closed, process tree being killed (seems in some bad way, not gracefully)

Attempts to send 3 (Ctrl-C i believe) to the windows bash via stdout not helping.

Is this a bug or exected behavior and i'm doing something wrong?

[sunilmut]

@hurricup - Thanks for your post. What were your expectations when using taskkill to kill the bash.exe? Were you expecting the rails server to also terminate along with it?

If all bash windows are closed, process tree being killed (seems in some bad way, not gracefully)

That is because when the last bash.exe process is closed, WSL terminates all the Linux processes by sending SIGKILL to them, which leads to immediate termination of the process. CTRL^C on the other hand leads to SIGINT, by default, which can be handled gracefully by the application. I would recommend (as of now) terminating all the Linux processes prior to closing the last bash instance.

[therealkenc]

@hurricup

The name bash.exe is unfortunate, and has been renamed to ubuntu.exe of late. It is unrelated to GNU /bin/bash in WSL. In your first screencap, you have a second GNU /bin/bash with no children (WSL PID 55). I suspect (but can't prove because you weren't clear on what you meant by "From other bash's htop I see") you have a second bash command shell that wasn't running anything at the moment you took the screencap.

So it looks like you have one bash.exe in win32 (probably child of cmd.exe) running /bin/bash and htop. You have another bash.exe -c ... which launched /usr/bin/ruby2.3, child of init. And you have a third bash.exe that launched the childless /bin/bash PID 55, which is unrelated to your rails process, and isn't doing anything. It looks like you killed that third bash.exe, not the bash.exe that resulted in init -> ruby2.3.

If you want to kill ruby from the win32 side, kill the ruby2.3 process with taskkill. From your description, it looks like you just killed a bash.exe that launched a /bin/bash with no children.

[sunilmut]

I have been playing around with this and it seems like there is a legitimate bug here in WSL.

@therealkenc - The issue is simple. Here is the repro:

1. bash.exe -c "python -m SimpleHTTPServer"
2. bash.exe
   #ps -ax --> note the python server running
3. Close the first command window that is running the first bash.exe (which should be the same as taskkill).
   #ps -ax --> note that the python server is still running.

One would expect the python server to also die along with the bash/terminal. That's how it also behaves on native Ubuntu.

The problem seems that the SIGHUP is not being sent to the foreground processes.

[therealkenc]

@sunilmut - That isn't the scenario described. There, unrelated PID 55 from the first screencap got killed.

Sending a SIGHUP might make sense. But note on Real Ubuntu™:

ssh localhost "sleep 1000"

ssh sits there running in the foreground. Open another terminal. Run ps, you'll see sleep running as a child of sshd.

ken@zesty:~$ ps ax | grep ssh
29227 pts/1    S+     0:00 ssh localhost sleep 1000
ken@zesty:~$ pstree -p | grep sleep
           |-sshd(1183)---sshd(29228)---sshd(29279)---sleep(29280)

Now, kill ssh.

kill -9  29227

bash.exe (or ubuntu.exe) is same as the ssh client in the scenario above. WSL init is the same as sshd, because WSL's all-dancing init is as close to sshd or getty as we have for now.

On Real Linux, sleep is still running, re-parented to systemd:

ken@zesty:~$ pstree -s -p 29280
systemd(1)───sleep(29280)

Heads up on related #2391.

[hurricup]

@therealkenc no. that's exactly that scenario. That extra bash just an artifact separate bash.

1. Start bash and run htop
2. Start other bash with rails app with bash.exe -c ....
3. Kill second one using taskkill
4. See the first bash with htop and find that rails app still runing, when second bash is not.

[therealkenc]

See the first bash with htop and find that rails app still runing, when second bash is not.

There is no second /bin/bash. Do a pstree -a after step 2 but before the taskkill of bash.exe.

C:\Users\there\source>bash.exe -c  "/home/ken/sleep.rb"

And:

ken@WinDev1612Sys:~/Devel/rails$ pstree -a
init
  ├─bash
  │   └─pstree -a
  └─init
      └─sleep.rb /home/ken/sleep.rb
          └─{ruby-timer-thr}

No WSL processes were harmed in the making of this film.

[hurricup]

@therealkenc clarification: when i saying start bash, i mean start bash.exe
And there are two bash.exe in windows process list 100%
And if one started with -c "rails ..." is killed, rails still active.

[sunilmut]

An update that a PR is out for review (thanks @Brian-Perkins) and should be out to Insiders soon.

[Madder]

will it make it for the fall update?

[benhillis]

@Madder - No, the fall update build was finalized before this change was made.

[benhillis]

Fixed in 1803.