Instance self-terminates prematurely when started with a background process in boot.command

[NotTheDr01ds]

Version

Microsoft Windows [Version 10.0.21354.1]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.102.1

Distro Version

Ubuntu 20.04 (but can repro with any)

Other Software

No response

Repro Steps

In a fresh Ubuntu 20.04 WSL2 instance:

• Add a [boot] section with command = service cron start to /etc/wsl.conf
• Restart WSL (e.g. wsl --shutdown; wsl ~ -d Ubuntu)
• Confirm cron daemon is running with ps axjf
• Exit shell/WSL
• Wait 15+ seconds
• wsl -l -v

Result: Ubuntu will be in STOPPED state, even though it still had running processes (cron)

• Restart the instance: wsl ~ -d Ubuntu
• sudo rm /etc/wsl.conf
• Exit shell/WSL
• wsl --shutdown
• wsl -d Ubuntu -u root -e sh -c "service cron start"
• Wait 30 seconds, 60 seconds, etc.
• wsl -l -v

Result: Ubuntu will (correctly) be in RUNNING state.

Expected Behavior

Starting a background process via boot.command will prevent the instance termination timeout, since it is a process that hasn't exited on its own.

boot.command behavior, at least in regards to process detection and cleanup, should be the same as when started interactively or via wsl --execute.

Actual Behavior

Regardless of the boot.command, the instance is terminated after 15 seconds unless some other process, started interactively (even if backgrounded) is still running.

For instance, with the /etc/wsl.conf in place, you can interactively run nohup sleep 10000 &, exit the WSL instance, and it will continue in the RUNNING state for (presumably) the next 10,000 seconds.

And it's not just cron, of course. Even a command = sleep 10000 will self-terminate after 15 seconds.

I thought this might be due to the lack of a pty for the boot.command, but I haven't been able to reproduce the behavior with something like:

wsl -d Ubuntu -u root -e sh -c "service cron start < /dev/null > /dev/null 2>&1"

That still works -- It never self-terminates.

I honestly thought boot.command worked properly at one point, but I now think I might have been masking the problem since I usually run ssh-agent (via keychain) in my startup config. So there's typically another background process that is preventing the instance from being considered "idle".

Additional notes:

• Reproduced under both Windows 11 GA as well as "Preview" release 0.64.0.
• This is not vmIdleTimeout related (see vmIdleTimeout has no effect #8659)
• This will impact the Example wsl.conf file referenced in the doc. The same problem will happen with command = service docker start.

Diagnostic Logs

No response

[NotTheDr01ds]

I'm closing this, at least for now, because:

• Based on the Systemd behavior, this is "by design"
• I can no longer reproduce the scenario in which I thought this was working (as I thought it should) in Windows 11 22000.