How-To
Hands-On with WSL: Background Jobs in Windows Subsystem for Linux 1803
Having processes that continue to run after all the WSL terminals are closed is a powerful feature that opens WSL to a wider range of workflows.
One of the more prominent new features included with the Windows Subsystem for Linux (WSL) Windows 10 version 1803 is the ability for jobs to continue running after all the WSL terminals have been closed. This feature is certainly an upgrade -- in previous versions, all processes running under WSL quit after all the WSL terminals are closed. Given the fact that processes such as SSH can now keep running, this feature is quite a powerful one.
After updating my Windows 10 system to 1803, I wanted to test how background processes work under this version. To do so, I first brought up a WSL terminal by entering wsl at the command prompt, and then created a bash script file in my home directory (~) called WSLTest.sh. This script writes the current date to a file called MyDate in my home directory every five seconds. The file contained the following text:
#!/bin/bash
date > ~/MyDate
for I in {1..60}; do date >> ~/MyDate; sleep 5; done
After the file was created, I made it executable and ran it in the background using nohup (which prevents a command from being aborted when you log out or exit the shell) by entering the following commands:
chmod 755 WSLTest.sh
nohup ~/WSLTest.sh &
Then, after verifying that the script was working correctly (Figure 1), I closed the WSL terminal.
[Click on image for larger view.]
Figure 1. The WSLTest script.
After a few minutes, I opened a new WSL terminal and verified that the process was still running by looking at the last three lines of the file. I then compared the last entry of the file to the current date by running these commands:
ps -elf
tail -3 ~/MyDate
date
After examining the output (Figure 2), I was satisfied that the process did continue to run after I had closed the WSL terminal.
[Click on image for larger view.]
Figure 2. The WSLTest script output.
After initially verifying that a process would continue to run after closing the WSL terminal, I wanted to take the testing to the next level to see if a service, such as an SSH server, would also continue to run. After installing the openSSH server (to find out how to do this, read my earlier article), I started the SSH service by entering the following commands (the text after the # are comments):
Sudo service ssh status
Sudo service ssh # See what options are
Sudo service ssh start # Start ssh
Sudo service ssh status # Verify that ssh has started
The results of running these commands can be seen in Figure 3.
[Click on image for larger view.]
Figure 3. Starting the SSH server.
I then verified the ability to connect to the SSH server running on WSL by connecting to it from the WSL terminal; to avoid any conflicts with the SSH server running on the actual Windows system, I used port 2200 for the WSL SSH session (Figure 4). Next, I closed my WSL terminal and connected to the WSL SSH server using PuTTy from the Windows session (Figure 5) without any issues.
[Click on image for larger view.]
Figure 4. The WSL SSH connection.
[Click on image for larger view.]
Figure 5. The PuTTY SSH connection.
After I proved that SSH would continue to work after all the WSL terminals were closed, I locked my Windows 10 session, and went to another system to see if I could still connect to it -- I could (
Figure 6).
[Click on image for larger view.]
Figure 6. SSH from a locked terminal.
For the final test, I logged out of the Windows system to see if the process would continue to run, and it didn't. When I logged back in, I needed to restart WSL and the SSH process before I could use SSH again.
In closing, having processes that continue to run after all the WSL terminals are closed is a powerful feature that opens WSL to a wider range of workflows, and increases its value as a programing tool.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He previously worked as a Technical Marketing Manager for ControlUp. He also previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.