Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL terminates systemd service docker containers when last terminal is closed #9667

Open
1 of 2 tasks
Newbrict opened this issue Feb 21, 2023 · 11 comments
Open
1 of 2 tasks
Labels

Comments

@Newbrict
Copy link

Version

Microsoft Windows [Version 10.0.22621.1265]

WSL Version

  • WSL 2
  • WSL 1

Kernel Version

5.15.79.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

docker with systemd option enabled on wsl2

Repro Steps

sudo apt install docker.io docker-compose

start any docker container (a simple one is an nginx container)

close all terminal windows connected to the wsl instance/ Ubuntu 22.04

wait 10-20 seconds

open a new terminal window to the Ubuntu 22.04

run docker ps and notice that everything was restarted (indicated by the uptime being only since you opened the new terminal window)

Expected Behavior

I expected the systemd services, like docker, to continue running even when I close my terminals.

Actual Behavior

The services shut down when the terminals are closed.

Diagnostic Logs

No response

@benhillis
Copy link
Member

This is by design. The VM hosting WSL will idle-terminate when:

  1. There are no open terminal windows and
  2. No backgroud processes were launched by the user explicitly (things launched by systemd don't count)

We do have an undocumented config option that disables this behavior, let me chat with the team a bit to see if that's something we should officially support.

@Tristan971
Copy link

We do have an undocumented config option that disables this behavior, let me chat with the team a bit to see if that's something we should officially support.

Oh please, that would be truly amazing

@Newbrict
Copy link
Author

This is by design. The VM hosting WSL will idle-terminate when:

  1. There are no open terminal windows and
  2. No backgroud processes were launched by the user explicitly (things launched by systemd don't count)

We do have an undocumented config option that disables this behavior, let me chat with the team a bit to see if that's something we should officially support.

That would be perfect.

Can you share how to do that, unofficially -- just between the two of us here, on this GitHub issue 😅

@MorphBonehunter
Copy link

Mhhh...maybe this hidden feature is something which would also solve #6782 😄

@Tristan971
Copy link

I mean the unstoppable idle termination is probably amazing for battery-powered devices, but on a desktop where the power use variation is so small in the grand scheme of things, it doesn't really have any upside...

@DanSheps
Copy link

DanSheps commented Feb 28, 2024

@benhillis Do you happen to have an update on this (specifically, the undocumented config option)?

@iannacone
Copy link

since i do not want to install systemd or anything else just as a workaround for this stupid issue, i prefer to run a single line on every work day start.
here mine 1 line preferred solutionS (try 1 at the time in this order) which requires no new sofware to be installed:

from windows host

wsl screen

from windows host

wsl tmux new -s backgroundsession

from wsl

nohup sleep 1d

WARNING: this is set to run for 1 day!

source1 source2

in case you want to terminate, or rollback without restart wsl, you can run htop and kill the relative process (screen, tmux, sleep)

@MartinEmrich
Copy link

Just experienced the same.

  • Windows Terminal displayed "powershell.exe" as a tab title. that annoyed me, so I detached my tmux session to restart Terminal.
  • Restarted Terminal, attached my tmux session. Within a second or so, the window disappeared.
  • After starting Terminal a second time, I see some text flying by, it closes again.
  • Third time, it says "WSL beendet ein Update..." (WSL is finishing an update), before running Bash, and my tmux session (including my work within) is gone.

To be clear: This behaviour causes data loss for users!

My tmux session was not a systemd process, but a normal backgrounded process by me, which got ignored by this.

IMHO the lifecycle of the WSL process tree (VM,...) should not be tied to a frontend application interacting with it (Terminal), at least not with the default configuration.

@p10tyr
Copy link

p10tyr commented Apr 24, 2024

This is by design. The VM hosting WSL will idle-terminate when:

  1. There are no open terminal windows and
  2. No backgroud processes were launched by the user explicitly (things launched by systemd don't count)

We do have an undocumented config option that disables this behavior, let me chat with the team a bit to see if that's something we should officially support.

You forgot to ask the users when designing this 🤣
Can you PLEASE 🙏 surface this option so that we can have docker running natively in wsl2 .. without having to have a shell open the whole time?

and no. not everyone wants to pay for Docker Desktop - actually - now it makes me think how they manage to do that now on their hidden vm??

@p10tyr
Copy link

p10tyr commented Apr 24, 2024

This must be the best work around.

#8854 (comment)

I made a ps1 file that runs with Windows Task Scheduler,

  • Trigger: On user logon
  • start program PowerShell.exe
  • Arguments c:/path/to/wsl-keepalive.ps1

It flashes a terminal briefly but I find that to be a very acceptable "solution"

wsl-keepalive.ps1

$commandToExecute = "wsl -e screen -d"

# wsl -e Execute the specified command without using the default Linux shell.
#  screen A linux virtual terminal that lets you create mulitple virtual terminal sessions in your system
#  -d Detach screen immediately

Invoke-Expression $commandToExecute

@codefaux
Copy link

Is anyone willing to spill the beans on this secret setting? It's kind of shocking that it's partway through 2024 and this fairly basic feature is completely hidden to the user/system admin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants