Data loss may occur when closing Bash, since Windows then closes all WSL background processes. Here are three suggested ways of fixing the problem.

[unforgettableid]

I'm using Windows 10.0.15063.

TL;DR

When you close Bash, Windows closes all Linux background processes. This might make users lose long draft emails, text files, and/or other important data.

First, I'll tell you more about the problem.

Then, I'll describe three possible solutions:

• A) The confirmation dialog.
• B) Reducing priorities instead of closing programs.
• C) Suspending programs instead of closing them.

OK. Let's begin.

The problem

If you close Bash, and if no other Bash windows are still open, the Windows Linux Subsystem automatically closes all background programs which you started from Bash. This includes detached tmux processes, text editors, email clients, and other software.

The subsystem does this for performance reasons. (Source.)

Depending what you were running in the background, this can lead to data loss. If you spent half an hour researching and writing an email draft before it disappeared, the data loss is significant.

If your chosen performance optimization (e.g. the one I just mentioned) leads to data loss, it might be better to choose a different performance optimization instead.

Here are some possible alternative solutions.

Possible solution 1: the confirmation dialog

I suggest that, if background processes are running, Windows could show you a dialog box like this:

3 Linux programs still need to close:

    ● tmux
    ● draft email for: bill.gates@msft.intranet — mutt
    ● last_will_and_testament.txt — vim

You may force these programs to quit without saving,
or you may resume your Bash session.

[ Quit &without Saving ]   [ &Resume session ]

If you choose "Resume Session":

• Windows won't close any of the background processes which the previous Bash session started.
• Windows will also start a new copy of Bash to replace the one that you closed.

Possible solution 2: reducing priorities

Renice the Linux programs to the lowest CPU priority ("Idle"). Also, ionice them to the lowest I/O priority ("Very low"). But keep them running until the Windows user closes their Windows session by clicking "Sign out" or "Shut down" or "Restart".

(The Linux subsystem is mostly used by skilled Windows users. If a skilled Windows user feels that their machine is slow, they'll probably click "Shut down" or "Restart" to fix the problem. But I doubt that programs running at "Idle" priority are likely to cause significant performance problems.)

Possible solution 3: suspending programs

You could suspend the programs until the next time the user starts Bash again.

I'm not sure what would be the best way to suspend the programs. You can almost surely send them SIGSTOP. I think this would be ideal.

Or maybe you can use SuspendThread on each thread, or use NtSuspendProcess, or use DebugActiveProcess. (Source.)

When the user starts Bash again, you can resume all the programs.

Conclusion

Thanks for your time!

Any thoughts?

[therealkenc]

TL;DR Windows could show you a dialog box

gnome-terminal on Real Ubuntu does prompt if you've got a tmux session on the go. Lesser terminals like xterm don't. It's a reasonable enough ask, but the mechanism to do something like that is less straightforward than it sounds. Anything is technically doable with enough demand though. This would be a tag [console] thing.

suspending programs

For actual background tasks see #2083, #2066, #1263, #612 etc etc, with user voice here. A detached tmux is just like any another daemon-ish process (running processes without an active tty/pty). More info here; stuff of which you might already be familiar.

The good news is this is on MSFT's backlog, with hints of progress being made all the time. It is really what you are looking for here.

The subsystem does this for performance reasons. (Source.)

...To ensure that a Bash shell doesn’t end up running in the background consuming considerable resources, we shut down the Bash/WSL instance once the last console session ends.

... 🙄

[rodrymbo]

I get around this by launching at least one WSL window hidden, usually with VBscript. If it is there and running, but hidden, I'm not likely to close it.

I usually run cron from the hidden window, so I have cron running too.

One con for this is that if you start your hidden window early in the boot process, then mount another drive or three, no WSL process will be able to see the new drive (or at least that used to be the behavior, haven't checked in a while).

Just a workaround for now, but it works.

[leojbgiusti]

You can use mount to access newly mapped or plugged in windows drives as per https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-improvements-to-the-windows-subsystem-for-linux/

[Brian-Perkins]

Windows Insider Build 17046 allows programs to execute without an active terminal.