-
Notifications
You must be signed in to change notification settings - Fork 819
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
In Window 10 with WSL installed, a Task Scheduler task setup to run at Startup/Logon which intiates a PowerShell script which executes the bash command fails. #3829
Comments
Could you try replacing: With: And see if that fixes the issue for you? We'll also look into the startup PATH behavior for bash.exe :) |
What about fully qualifying the path to bash.exe or wsl.exe (c:\Windows\System32\bash.exe). |
@mscraigloewen @benhillis thanks for the quick response Case 1: using wsl instead of bash
At task startup, this is the error thrown by the script:
Case 2: using full path of exe(c:\Windows\System32\wsl.exe)
At task startup, this is the error thrown by the script:
Note 1 : mentioning full path of bash exe(c:\Windows\System32\bash.exe) after removing symlink also failed at task startup even though it went through in PowerShell Note 2: Mentioning path like this also failed at task startup even though this too successfully went throught with PowerShell. The only thing that worked is with the WORKAROUND when symlinks are created.
Now Case 1 went through at Task Start up. CONCLUSION: IMO this make a case for a fix. |
It looks like looking at system32 folder from a 32-bit application. |
Looking at Case 2 failure above (when I tried full path 'c:\Windows\System32\wsl.exe) and it failed at task startup, it is clear that specifing C:\Windows\sysnative\wsl.exe will also fail with
So this will fail with PowerShell execution too |
It’s not entirely clear that it’ll fail: Since it looks like the task being scheduled is launched with filesystem redirection turned on, and perhaps even in 32-bit mode itself, The issue isn’t exactly that system32 isn’t in the path; it’s that system32 is redirected to syswow64 for a 32-bit process. |
@0xbadfca11 My apologies I tried with C:\Windows\sysnative\wsl.exe after removing the symlink to wsl My PowerShell script now looks like
On startup, task gets executed without error and ssh service does get started. Thank you. Learnt something about sysnative as well. Thanks @DHowett |
Another workaround might be to use the distro-named .exe, which is probably in a "normal" directory. For example, |
@rodrymbo
Thank you. |
One correction for all these workarounds.
None of these workarounds work on a Task Scheduler Tasks triggered On System Startup. Could Anyone suggest a work around that will work at System Start Up, and not for just for Logged In User? |
Is it possible to start ubuntu1804.exe without it displaying a window? If so it might be possible to install and run a service that would execute the command and arguments. Something like the cygrun command from Cygwin. |
I've not been able to get ubuntu1804 to run from task manager in the "whether user is logged on or not" context. But since this is a desktop machine, I just use an "only when user logged in" context, which works just fine and accomplishes almost the same thing. (Takes some testing to make sure it is doing what you want.) It would be nice to have it run as a true service, but there are plenty of complications to consider. One is that it still needs to run in some (Windows) user context, so if not yours, you'd need to create one and install a distro for it. The other is that, once the background task or daemon starts, the Windows system context tends to be frozen, so, for example, if you mount a drive after that, the background process won't see the new drive. On to "start without displaying a window": One of the first things I did when I first started using WSL was work up a way to start WSL without leaving a window lying around. The first thing I did was use vbscript, which has the
syntax, where the 0 means hide the window and False is in the "wait on return" position. You may need to fiddle with it to get it to work the way you want. Once it is working, the "hide window" switch makes sure there is no window kicking around. As with most such things, just because I got it working many months ago doesn't mean it is still the best way to do it, but since it works, I'm still using it. :P The You can probably use one of the commands to start a process in the background from a bash script; thus the script can exit (closing the window) but the process will still keep running in the background. It didn't used to work that way, but it works much better now. It might take some trial and error to get it working the way you want, but of course once you find a vbs script you can run from wscript (or a bash script you can run from ubuntu1804.exe and ignore the window that opens then closes again) you can put it into Task Scheduler. |
I am in the same scenario with powershell script to start WSL with SSH in task scheduler. I tried With the symlink workaround, my powershell script looks like below With the Sysnative wsl workaround (symlink removed), my powershell script looks like below |
I am fairly certain the problem really is #2979 This is a duplicate of microsoft/winget-cli#1011 and also https://stackoverflow.com/q/65770661/308851 I have tried to set up the task to run as the user WSL is installed under but that's obviously (?) a no go because you'd need to store the user password. (And I am in an AD and I can't even get to the password prompt but w/e.) The only way would be to install WSL somehow under I give up and will run my script on login. |
Try with non-store version of WSL 2 add a new SchTask this works with only with WSL inside version. new WSL store version breaks this #9231 |
@enachi Can you describe how to install a non-store version of WSL2? Thanks! |
I tried everything in this thread to get WSL2 to run at startup via the Task Scheduler, and nothing worked. However, I was able to get WSL2 to run at startup without the Task Scheduler by doing the following: I wrote a script called
I then placed a shortcut to Works like a charm, albeit after a ~5 second delay or so on my machine. The minimized PowerShell window disappears once the WSL process is successfully kicked off, so this meets my criteria for running WSL totally in the "background" at startup. To be clear, I installed Ubuntu via Microsoft Store, as I'm running Tailscale in WSL and thus much prefer having the ability to start it via |
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request. Thank you! |
Please fill out the below information:
Your Windows build number: (Type
ver
at a Windows Command Prompt)Microsoft Windows [Version 10.0.17763.253]
What you're doing and what's happening:
In Window 10 with WSL installed, a Task Scheduler task setup to run at Startup/Logon which intiates a PowerShell script which executes the bash command fails.
This is the PowerShell script:
Note: Running this with powershell as Administrator works fine. If fails only when run as a task via TaskScheduler
But running from Task Scheduler at log on throws this error:
Note the reason it cannot find bash is that bash.exe is found only in the 32 bit version (c:\Windows\System32\bash.exe) and it looks like the path for TaskScheduler does not include 32bit libraries by default in Windows?
Create a symlink to 32bit bash.exe in SysWOW64
Now the TaskScheduler task executes successfully and the ssh service is started as instructed.
Can this PATH issue be fixed in a future release, so that this unnecessary workaround can be avoided?
The text was updated successfully, but these errors were encountered: