systemd user session (user@1000.service) randomly SIGKILLed, killing all user processes (vscode-server, terminals) #41873
Description
Environment
Windows: Windows 11 Home, version 26H2 Build: 10.0.26300.9550
WSL version: 3.0.1.0
Kernel: 6.18.40.1-1
Distro: Debian 13 (trixie)
.wslconfig: systemd=true, memory=10GB, swap=8GB
Vs Code 1.141.0 with WSL extension 0.104.3
Also reproduces on WSL 2.7.14.0 / kernel 6.18.33.2-2, so this is not new in 3.x.
What happens
While actively working in VS Code Remote-WSL, the connection drops without warning. The journal shows why: the boot login session that mini_init spawns for the default user closes, systemd-logind removes sessions c1 and c2, then user@1000.service is SIGKILLed and the whole user slice goes down with it. vscode-server lives in that session scope, so the remote connection dies instantly and every terminal dies too. System-level services keep running the entire time, so the VM itself is alive: it is specifically the user session tree getting torn down.
Today it fired 7 times: 04:02, 05:53, 07:55, 08:37, 10:37, 11:01 and 11:57. Gaps ranged from 24 minutes to almost 3 hours. I was actively working through VS Code every single time, terminals open, so an idle timeout does not explain it.
Journal excerpt (10:37 occurrence, unfiltered)
Oct 11 10:37:28 <host> login[687]: pam_unix(login:session): session closed for user <user>
Oct 11 10:37:28 <host> systemd[1]: session-c2.scope: Deactivated successfully.
Oct 11 10:37:28 <host> systemd-logind[376]: Session c2 logged out. Waiting for processes to exit.
Oct 11 10:37:28 <host> systemd-logind[376]: Removed session c2.
Oct 11 10:37:28 <host> systemd-logind[376]: Removed session c1.
Oct 11 10:37:28 <host> systemd[1]: user@1000.service: Main process exited, code=killed, status=9/KILL
Oct 11 10:37:28 <host> systemd[1]: user@1000.service: Killing process 23855 (python) with signal SIGKILL.
Oct 11 10:37:28 <host> systemd[1]: user@1000.service: Failed with result 'signal'.
At 11:57:59 the kill had no "session closed" line before it at all. The user manager was SIGKILLed cold, with no logind session event in front of it. So there may be two paths into the same teardown, or the ordering in the earlier events is misleading.
What I ruled out
- OOM. PSI flat, several GB available at every occurrence, zero kernel OOM lines. Same behavior with memory=8GB and memory=10GB in .wslconfig.
- Host-side events. Windows System, NetworkProfile and power logs are silent in a 2 minute window around every drop, and the machine never slept.
- Linger. loginctl enable-linger is set for my user, and user@1000 still gets SIGKILLed, which I did not expect.
Workaround in place
A drop-in on user@.service (Restart=on-failure, RestartSec=1) brings the user manager back in about a second and restarts my user units with it. That part works. Everything living in the session scope is still dead on the floor though: vscode-server, terminals, all of it. The VS Code window needs a reload every single time.
Related
#10205 (closed), #13188 (closed), #13826 (open). Happy to provide more logs, tracing or repro details.
Activity
github-actions commentedon Oct 11, 2026
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.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use
.\collect-wsl-logs.ps1 -LogProfile networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce completed please upload the output files to this GitHub issue.
See Collect WSL logs (recommended method).
If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.