Unable to start WSL via Task Scheduler

Version

22000.978

WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version

5.15.57.1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

Create a powershell script with the following:

# start SSH server and other applications in Ubuntu
wsl -d Ubuntu-22.04 -u root service ssh start
Start-Sleep -s 5

# add port forwarding rule (from WSL to host) for port 4242
$wsl_ip = (wsl hostname -I).trim()
Write-Host "WSL Machine IP: ""$wsl_ip"""
netsh interface portproxy add v4tov4 listenport=4242 connectport=4242 connectaddress=$wsl_ip

Create a Task Scheduler task to run the powershell script on boot.

Run whether use is logged in or not
Run with highest privileges
Trigger: at startup (30 second delay)
Action: start a program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Action: Add arguments: -ExecutionPolicy Bypass -File C:\Scripts\startwsl.ps1
Settings: Allow task to be run on demand

Restart the machine, or manually run the task.

Expected Behavior

Upon reboot or manually running the task, the WSL instance should start and the ssh daemon should be running. This worked in previous versions of WSL (on Windows 10).

Actual Behavior

Either on reboot or on manually executing the task, WSL does not start.

C:\Windows\system32>wsl --list --running
There are no running distributions.

If I manually run the following command via the command prompt, WSL and the ssh daemon start properly.

C:\Windows\system32>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\startwsl.ps1
 * Starting OpenBSD Secure Shell server sshd                                                                                                                      [ OK ]
Starting seafile daemon ...
Started: seafile daemon ...
WSL Machine IP: "172.21.82.221"

C:\Windows\system32>wsl --list --running
Windows Subsystem for Linux Distributions:
Ubuntu-22.04 (Default)

In summary, running the same powershell script to launch WSL works from the command prompt but does not work from the task scheduler.

Diagnostic Logs

No response

Thanks @astuomi.

I tried this several times but whenever I manually ran the task like this:

The status would change to "Running" but it didn't seem to be doing anything at all.

It wasn't until I went back into Properties and used the "Browse" button to pick wsl.exe that it actually worked:

Copy-and-pasting "C:\Program Files\WSL\wsl.exe" does not work, despite the path being exactly the same.

Actually, Task Scheduler doesn't show the job as finished. My script seems to have finished because I can see the last line has finished executing, but Task Scheduler thinks it's still running. So it's still a bit sketchy but... we'll see if it works.

Edit: Seems to be working.

@aGrimRepoMan

I see same issue with WSL1 on Windows 10 when running Windows Task Scheduler task with program set to "C:\WINDOWS\System32\wsl.exe" and arguments set to "-d Debian-BackupPC -u root service ssh start", i.e. without invoking intermediate powershell or batch command file. Windows Task Scheduler previously returned success code 0, but for several months now is returning 2147942401.

Try if these steps help:

remove admin rights from the user running that scheduled task

define the scheduled task program as:
C:\Windows\System32\cmd.exe /k start "" /wait C:\Windows\System32\wsl.exe -d Ubuntu-20.04 -u WSL_username
Edit: You might have to add "Log on as a batch job" permissions for the user running the task in:

secpol.msc: Security Settings/Local Policies/User Rights Assignment/Log on as a batch job

Edit 2: Log on as a batch job

When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the Log on as a batch job user right.

I'm using Windows Server 2022 I used this approach by creating a task directly on Task Scheduler application by using:

where, as test, in Add arguments I typed:

/k start "" /wait C:\Windows\System32\wsl.exe -d Ubuntu -u myuser sh -c "touch $HOME/test"

It keeps open due to /k. If I replace it by /c it turns to Ready state after running but the WSL distro is not started... I also tried by using a .cmd script called by the scheduled task containg cmd /k start "" /wait C:\Windows\System32\wsl.exe -d Ubuntu or cmd /c start "" /wait C:\Windows\System32\wsl.exe -d Ubuntu but WSL does not start (I check it by wsl -l --running.

I read through this thread and almost gave up but I watched this tutorial and it just took a quick fix to get wsl command working for my scheduled task: https://www.youtube.com/watch?v=knA6JXOoJkE&ab_channel=BonGuides

Actually two problems seem to have come together at my side:

Half of the solution was @cheng-chi
- This started WSL2 before login
- However SystemD stopped WSL after a few seconds again
The other half was the piece from @hammadrauf
- By keeping the ugly terminal window open this way, WSL continues to run
- This window shows up after login
- If the window is closed, WSL2 shuts down a few seconds later
- I do not know how to hide this window (because I do not care)

My settings are:

General
- Change User or Group Administrators
  (With my German Windows it is Administratoren)
  (this is @cheng-chi)
- Run with highest privileges
- Note that the options to run on logon etc. are greyed out, so it runs when the machine boots up
Triggers
- Run at system start
- Delayed 30 seconds
- Active
Actions
- Start a program
- Program: C:\Windows\System32\wsl.exe
- Arguments: read
  (this is @hammadrauf)
Conditions
- Everything unchecked except "run on power"
  ("Aufgabe nur starten, falls Computer im Netzbetrieb ausgeführt wird" in German Windows)
  (I only need WSL as a bridge when I am at home and the Laptop is docked)
Settings
- Except for the first option everything else unchecked
  ("Ausführung der Aufgabe bei Bedarf zulassen" in German Windows)

With the settings above, WSL starts after boot right before login, and allows me to fully control the Laptop (including login to Windows) from remote, even that I am paranoied and hence no incoming connections are allowed at all.

wsl --version

WSL-Version: 2.0.9.0
Kernelversion: 5.15.133.1-1
WSLg-Version: 1.0.59
MSRDC-Version: 1.2.4677
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows-Version: 10.0.22631.3155

systeminfo

(excerpt)

Betriebssystemname:                            Microsoft Windows 11 Pro
Betriebssystemversion:                         10.0.22631 Nicht zutreffend Build 22631
Betriebssystemhersteller:                      Microsoft Corporation
Betriebssystemkonfiguration:                   Eigenständige Arbeitsstation
Betriebssystem-Buildtyp:                       Multiprocessor Free
Ursprüngliches Installationsdatum:             11.10.2022, 12:51:07
Systemstartzeit:                               27.02.2024, 13:05:32
Systemtyp:                                     x64-based PC

/etc/wsl.conf

(excerpt)

[network]
generateHosts = false

[boot]
command = /etc/init.d/cron start

crontab -l

@reboot bin/autostart.sh >/dev/null
* * * * * bin/autostart.sh >/dev/null

(autostart.sh is my way of autostarting things. It only needs cron and thus is completely agnostic to init. It happend to work under WSL out of the box, too. Of course you can use your own favorite way to start and keep things running, too.)

This is an example how it looks after a login into WSL via ssh:

debian:~$ pstree
init(Debian)─┬─SessionLeader───Relay(12)───bash
             ├─cron
             ├─init───{init}
             ├─ptybuffer───ssh
             ├─sshd─┬─sshd───sshd───bash───pstree
             │      └─sshd───sshd
             └─{init(Debian)}

The bash behind the Relay(12) is the ugly window.
ptybuffer is from my autostart.sh which was started by cron
The ssh is from the autostart script which initiates an outgoing ssh connect to allow to tunnel to the sshd
the sshd incoming connection without anything is from Remmina connecting to the VNC running under Windows

The only problem left is, that a logout on Windows closes the ugly window and hence WSL stops. However I think this can be corrected with Task Scheduler if I really need it.

Actually two problems seem to have come together at my side:实际上，我身边似乎有两个问题同时出现：

Half of the solution was 解决方案的一半是@cheng-chi

This started WSL2 before login这在登录之前启动了 WSL2

However SystemD stopped WSL after a few seconds again然而 SystemD 在几秒钟后再次停止了 WSL

The other half was the piece from 另一半是来自@hammadrauf

By keeping the ugly terminal window open this way, WSL continues to run通过以这种方式保持丑陋的终端窗口打开，WSL 可以继续运行

This window shows up after login登录后出现此窗口

If the window is closed, WSL2 shuts down a few seconds later如果窗口关闭，WSL2 会在几秒后关闭

I do not know how to hide this window (because I do not care)我不知道如何隐藏这个窗口（因为我不在乎）

My settings are: 我的设置是：

General 一般的

Change User or Group Administrators更改用户或组 Administrators (With my German Windows it is Administratoren) （对于我的德语 Windows，它是 Administratoren ） (this is @cheng-chi) （这是）

Run with highest privileges以最高权限运行

Note that the options to run on logon etc. are greyed out,请注意，登录时运行的选项等呈灰色显示， so it runs when the machine boots up 所以它会在机器启动时运行

Triggers 触发器

Run at system start在系统启动时运行

Delayed 30 seconds 延迟30秒

Active 积极的

Actions 行动

Start a program

Program: C:\Windows\System32\wsl.exe 程序： C:\Windows\System32\wsl.exe

Arguments: read 参数： read (this is @hammadrauf) （这是）

Conditions 状况

Everything unchecked except "run on power"除了“依靠电源运行”之外，一切都未经检查 ("Aufgabe nur starten, falls Computer im Netzbetrieb ausgeführt wird" in German Windows)（德语 Windows 中“仅当计算机在网络模式下运行时才启动任务”） (I only need WSL as a bridge when I am at home and the Laptop is docked)（当我在家并且笔记本电脑已连接时，我只需要 WSL 作为桥梁）

Settings 设置

Except for the first option everything else unchecked除了第一个选项外，其他所有选项均未选中 ("Ausführung der Aufgabe bei Bedarf zulassen" in German Windows)（德语 Windows 中“允许任务按需运行”）

With the settings above, WSL starts after boot right before login,通过上述设置，WSL 在启动后、登录前启动， and allows me to fully control the Laptop (including login to Windows) from remote,并允许我从远程完全控制笔记本电脑（包括登录 Windows）， even that I am paranoied and hence no incoming connections are allowed at all. 即使我很偏执，因此根本不允许传入连接。
wsl --version
WSL-Version: 2.0.9.0
Kernelversion: 5.15.133.1-1
WSLg-Version: 1.0.59
MSRDC-Version: 1.2.4677
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows-Version: 10.0.22631.3155
systeminfo
(excerpt) （摘抄）
Betriebssystemname:                            Microsoft Windows 11 Pro
Betriebssystemversion:                         10.0.22631 Nicht zutreffend Build 22631
Betriebssystemhersteller:                      Microsoft Corporation
Betriebssystemkonfiguration:                   Eigenständige Arbeitsstation
Betriebssystem-Buildtyp:                       Multiprocessor Free
Ursprüngliches Installationsdatum:             11.10.2022, 12:51:07
Systemstartzeit:                               27.02.2024, 13:05:32
Systemtyp:                                     x64-based PC
/etc/wsl.conf 
(excerpt) （摘抄）
[network]
generateHosts = false

[boot]
command = /etc/init.d/cron start
crontab -l
@reboot   bin/autostart.sh >/dev/null
* * * * * bin/autostart.sh >/dev/null
(autostart.sh is my way of autostarting things. It only needs cron and thus is completely agnostic to init.（ autostart.sh 是我自动启动的方式。它只需要 cron ，因此与 init 完全无关。 It happend to work under WSL out of the box, too. Of course you can use your own favorite way它也恰好可以在 WSL 下开箱即用。当然你可以用你自己喜欢的方式 to start and keep things running, too.) 也可以启动并保持运行。）

This is an example how it looks after a login into WSL via ssh:这是通过 ssh 登录 WSL 后的外观示例：
debian:~$ pstree
init(Debian)─┬─SessionLeader───Relay(12)───bash
             ├─cron
             ├─init───{init}
             ├─ptybuffer───ssh
             ├─sshd─┬─sshd───sshd───bash───pstree
             │      └─sshd───sshd
             └─{init(Debian)}
The bash behind the Relay(12) is the ugly window. Relay(12) 后面的 bash 是丑陋的窗口。

ptybuffer is from my autostart.sh which was started by cron ptybuffer 来自我的 autostart.sh ，它是由 cron 启动的

The ssh is from the autostart script which initiates an outgoing ssh connect to allow to tunnel to the sshd ssh 来自自动启动脚本，该脚本启动传出 ssh 连接以允许通过隧道连接到 sshd

the sshd incoming connection without anything is from Remmina connecting to the VNC running under Windows sshd 没有任何内容的传入连接来自 Remmina 连接到在 Windows 下运行的 VNC

The only problem left is, that a logout on Windows closes the ugly window and hence WSL stops. However I think this can be corrected with Task Scheduler if I really need it.剩下的唯一问题是，Windows 上的注销会关闭丑陋的窗口，因此 WSL 会停止。不过，我认为如果我确实需要的话，可以使用任务计划程序来纠正这个问题。

Not work for me

wsl version:  2.1.5.0

microsoft / WSL