bash as a Windows Task Scheduler Action fails

[diablodale]

bash as a Windows Task Scheduler/Action fails. It appears to be related to needing to be a visible window and a user interactively logged on. I have read a posts where a Microsoft admin write "when you close your last bash shell console window, we tear-down the Linux process chain in order to conserve resources". That seems to match the problem.

Setup: Windows 10 x64 build 14986 Clevo p150em based laptop 16GB ram, 500GB SSD apt update apt upgrade apt install python

Repro:

0. prepare/source a simple python app
1. Run Windows Computer Mgmt
2. Task Schedule, Create Task...
3. choose "run whether user is logged on or not"
4. choose "configure for: windows 10"
5. make new action, start program
6. program: C:\Windows\System32\bash.exe
7. arguments: -l -c "/usr/bin/python /mypath/mypythonapp.py"
8. OK, OK, type your password
9. Right click on your task, choose run

Result: Task Scheduler shows it launched bash and has its PID Win Task Manager will show the PID and that it is bash Nothing else happens. The app does not successfully run

Expected: Python app to run

Workaround: In step 3 above, choose instead "Run only when user is logged on"

Seems related to: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13653522-consider-enabling-cron-jobs-daemons-and-background

[benhillis]

Thanks for posting. The reason this isn't working is that our user-mode service (LxssManager) does not allow callers from session zero. Scheduled tasks created with the "run whether user is logged on or not" option set will run in session zero. You'll notice in task manager details tab if you enable the "SessionId" column, your created bash.exe will be in session zero. I'd suggest using the "run only when user is logged in" option as you're currently doing.

The reason bash.exe is just sitting there is because when an error is encountered (trying to use the COM interface to the service) we print the error code and wait for user input.

[diablodale]

Got it. Then perhaps there are two bugs here:

1. A non-interactive shell should never wait for user input. I ran bash with the -l (aka --login) parameter which by the man pages I'm reading https://linux.die.net/man/1/bash declare it is a non-interactive shell. I believe it is errant for a non-interactive shell to want interaction.
2. Can't run bash when user isn't logged on as task in Windows Task Manager because session 0 is currently forbidden.

No known workaround for 1. Just don't do it. Workaround for 2. The user for a desired task has to be logged in.

[nvsystems]

Is there any chance this problem will be fixed in a future release? The Windows 10 Creators Update (1703) has definitively NOT fixed it.

Bash.exe tasks scheduled with the option "Run whether user is logged on or not" just plain do not work - which prevent lots of useful stuff, in my case I wanted to start a daily backup using rsync over the internet... Works perfectly fine with the "Run only when the user is logged on" option selected, but an automated backup should always run and not only if a specific user just happens to be logged on...

Considering the option "Run only when user is logged on" as "workaround-available" is IMHO not a valid workaround, because it just doesn't work for background tasks that should run regularly. And this is what a task scheduler is for, isn't it?

[benhillis]

@nvsystems - Yes, background processes, daemons, and using WSL from session zero (task scheduler tasks) are something we're looking at improving for a future release.

[edgett]

Please make this work. This issue renders bash useless in MSSQL and IIS.

[beardedfool]

Hi Ben,

Seems rather important for backups etc as there isn't any cron- unless I'm mistaken?

I've got to go with nvsystems here- I don't think 'workaround-available' is the right tag here. I also, personally, see it as distinct from persistent daemons/ cron from within a bash session - although appreciate I may be missing the point slightly.

Can you task-schedule a login for a user as a temporary workaround? (Similar automatic login via netplwiz).

At least then I could login the session, run the bash script and logoff again. Not pretty but perhaps more of a workaround that it simply not working unless logged in.

Just in case there's a better way - I'm trying to automate 1) Wake on LAN the machine out of hours 2) Backup through bash script (borg) 3) Shut it down

[benhillis]

This should be fixed in 17017.

[edgett]

Verifying: Can now use Bash via IIS in 17017.1000

[jean]

How does this make it to non-insider Windows builds? Is there some way to be notified when the Task Scheduler fix is included in a released build?

Found a comment on the uservoice query:

the next update (~April) will have it built-in.

[WSLUser]

@jean If it's in the Release Notes (which it is) then it will part of the next stable upgrade of Windows. All items in the Release Notes area always apply to the next stable build of Windows. Basically all Insiders does is go over what will be available in the next stable version of Windows and come with a few new features and more bug fixes. In the case of WSL, there will be a tremendous amount of changes once the stable release is out but there's still a tremendous amount of work to do unfortunately. If you're looking for a backport, the official answer is only things like BSODs/GSODs that seriously impact users will be backported.

[timedroid]

This still doesn't work when trying to launch ubuntu.exe. It does work while launching wsl.exe. I needed to use "c:\windows\sysnative\wsl.exe" when launching a Jenkins slave by executing a command on master.