Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Instance self-terminates prematurely when started with a background process in boot.command (#8661), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

from wsl.

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Instance self-terminates prematurely when started with a background process in boot.command (#8661), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

from wsl.

Detected appx version: 2.2.4.0

from wsl.

The relevant log excerpts have already been included. Happy to provide additional information if necessary.

Maybe it's worth mentioning that setting vmIdleTimeout to -1 or a sufficient large value has no effect.

from wsl.

WslLogs-2024-05-20_22-18-51.zip

from wsl.

Thank you @thielj.

Based on the symptoms, I wonder if the issue is that the ubuntu distribution installer simply shuts down the WSL distribution after creating the user.

Do you see the same symptoms with let's say debian ?

from wsl.

@OneBlue Hi. Please note that the shutdown is initiated by the '10000ms watchdog' before user credentials are entered (21:46:49). It's not automatically restarting after this.

Only when you provide the default user name and hit enter the instance/distro is brought up again (21:47:00). Just wait long enough (e.g. 30 seconds) when prompted to enter the default username and you will see. The default user is created after this, and the instance/distro is then shutdown a second time before the default user is logged in.

I naturally tried Debian but it comes without cloud-init. I haven't investigated how to roll my own cloud-init enabled WSL distro but would think that with the observed '10000ms watchdog' this would be a waste of time. Even the standard 'apt upgrade' module wouldn't be safe to run.

from wsl.

@OneBlue Maybe this helps to determine if cloud-init is still running?

https://cloudinit.readthedocs.io/en/latest/howto/status.html

from wsl.

@thielj: I wonder if what you're experiencing is the normal VM idle time out if there's no activity. Let's try something: Can you put:

[wsl2]
vmIdleTimeout=-1

in .wslconfig and see if that the solves the issue for you ?

from wsl.

from wsl.

Ok interesting. Could you capture logs with that .wslconfig value set ?

/logs

from wsl.

@OneBlue It was mentioned here: #11602 (comment)

Neither -1 or a much longer timeout made any difference at all. Neither did anything else that looked even remotely related in .wslconfig. It's also readily reproduceable on my laptop (with a 900000 timeout). I would be surprised to hear from anyone who can't reproduce this.

And it seems I just discovered a workaround: If I log into the distro from another terminal window, during the installation, as soon as this is possible, WaitForBootProcess still chimes in, the typical root login happens -- but the shutdown does not and cloud-init completes as expected. Just having an interactive shell open seems to prevent it.

Maybe the following is related. The actual shutdown in my case also happens almost exactly 15s after WaitForBootProcess comes in. #8659

The first timer is how long a WSL instance is idle before it is terminated. Think of this as a wsl --terminate that occurs when there are no more running processes in it other than init. This is non-configurable, but #6782 is a feature request for the ability to configure it. As far as I can tell, this is hard-coded at about 15 seconds.

Have you looked what is triggering your WaitForBootProcess code? It is clearly setup with a fixed 10000ms timeout and then logs in as root. I don't see this error in the logs after the first/--install start.

If it's supposed to detect a running cloud-init: maybe it would be worth looking into that bit? And if not, my guess is that a service like cloud-init doesn't count as 'running process other than init'. A simple command -v cloud-init && cloud-init status --wait before initiating the shutdown would allow cloud-init to complete and solve the issue.

from wsl.

@OneBlue And another update regarding that workaround: Looking at the debug console for cloud-init output or counting to 15 and then starting wsl ~ cloud-init status --wait in another terminal does indeed work. Once you try to do something more than just sleeping, there's another problem though: /etc/resolv.conf disappears, roughly around the time cloud-init is running apt upgrade. It's probably triggered by your 10000ms watchdog. So sometimes the upgrade runs through, sometimes it fails. Additional packages installed after that always fail (unable to resolve archive.ubuntu.com). It's definitely no problem with my network and is also independent of networkingMode or dnsTunneling.

I can workaround this by replacing the symlink with an immutable copy of /mnt/wsl/resolv.conf very early in the boot process, like so:

#cloud-config

bootcmd: 
  - chattr -i /etc/resolv.conf
  - rm -f /etc/resolv.conf
  - cp /mnt/wsl/resolv.conf /etc/resolv.conf
  - chattr +i /etc/resolv.conf

package_update: true
package_upgrade: true
packages: [ btop ]

Your ConfigCreateResolvConfSymlink isn't happy about that, which makes me think it might also be involved with its disappearance:

[   25.822086] WSL (2) ERROR: WaitForBootProcess:3342: /sbin/init failed to start within 10000
[   25.823081] WSL (2) ERROR: ConfigCreateResolvConfSymlink:1741: symlink(/mnt/wsl/resolv.conf
[   25.833860] WSL (2) ERROR: ConfigCreateResolvConfSymlink:1741: symlink(/mnt/wsl/resolv.conf

I tried generateResolvConf=false to no avail. The symlink would still disappear. I suppose /etc/wsl.conf is read before the distro is launched?

from wsl.