I usually use the linux subsystem when I'm programming anything on Windows 10 so all my paths are relative to ~. I have a python script that runs forever in the background until I kill the process. How would I do that on Windows 10 bash without an open terminal?

Things I've tried:

  • bash -c "python3 script.py from Run.
  • nohup python3 -u script.py then closing the terminal.
  • setsid python3 script.py then closing the terminal.

None of these worked. Is there a way to do this? Alternatively, is there a way to alter the paths so they work if I run the script from W10 AND bash without having to switch them around every time?


A recent addition to WSL allows for starting wsl commands directly from the 'run' or Start menu. You can append an ampersand to the command (normal shell behavior), which results in a momentary bash terminal which immediately disappears but the command continues.

Examples, within Start » Run:

wsl sleep 20 &
wsl python -c 'import time; time.sleep(20);' &

If you go into Windows' Task Manager, it will show a Sleep or Python2 command running for 20 seconds, then self-clearing.

One thing I've found is that environment variables are not available. For instance, DISPLAY, if set in the windows normal method, is not passed to WSL. For this, there needs to be a way to pass these variables. Even if the command does not support setting the needed variable via a command line argument, it's possible to do it using bash itself:

# direct, command-dependent
wsl emacs --display=:0 &

# indirect, more flexible
wsl bash -c "DISPLAY=:0 emacs" &

NB: I'm currently running win10_64, Version 1709 (OS Build 16299.64).

| improve this answer | |


Microsoft has addressed this. Background / daemon processes are now allowed to continue running even after bash.exe (or other WSL launcher process) is closed. A recent build of Win10 (spring 2018 for public releases, build 17046 or greater) is required.

The below is preserved for posterity.

Sadly/absurdly, there is no way to do this. Microsoft, in their infinite wisdom, have decided that WSL (Windows Subsystem for Linux) will only run while you have a bash.exe process open. Close the last one (or possibly even close the last window; I'm not sure if it'll tolerate being run headless) and WSL shuts down, killing all of its processes.

The justification for this was "to conserve resources", which is absurd on several different levels but most notably because, dammit, my computer has those resources and they are there to be used! If I want a process to run, it should run; if I don't want it to run, I can kill it. For something explicitly intended as a developer tool, it sometimes feels like WSL is only usable as a plaything and its users can't be trusted to know what they're doing.

Anyhow, if you want this fixed, vote for Consider enabling cron jobs, daemons and background tasks on the UserVoice page. It's currently the second-most-voted-for request, and is "on the backlog".

| improve this answer | |
  • "most notably because, dammit, my computer has those resources and they are there to be used" very well put! it really boggles the mind... – airstrike Jul 6 '17 at 0:27
  • I have build 17134 and can't have a background job without a bash window. – John Pick Aug 20 '18 at 22:30
  • @JohnPick They won't launch automatically after a reboot, but they should stay running when the window is closed (as long as they aren't attached to it, of course). – CBHacking Aug 22 '18 at 6:18
  • @CBHacking To be more specific, if I start a Node.js server in the background, then it's both a job (jobs) and a process (ps aux). I can use fg to bring it to the foreground. But, after I close the last bash window and open a new bash window, the job is gone, the process is still running, and I can't move the process to the foreground. Sorry if my terminology is off. – John Pick Aug 23 '18 at 16:45
  • @JohnPick Ah, that's a completely different issue - this question is about processes, not about shell job management - and ought to have been asked elsewhere, but the answer is simple enough I'll give it here: launch the process under tmux or screen to support re-attaching to a different terminal. Linux (and other *nix) machines running natively have the same limitation. – CBHacking Aug 24 '18 at 2:32

Yeah, it's "impossible" at the moment.

But it's possible to have it "appear" like a background process with some trickery. I wanted this functionality pretty bad myself so after a couple of hours I came up with a shitty but working solution.

The main point is to create an invisible shell that you launch WSL Bash to with VBScript. You can then have that script be run on startup. Proper Task Scheduling didn't work for some strange reason.

Linux side to enable daemons you can have your own rudimentary startup system that abuses .bashrc for example.

The process is detailed here in this document I wrote https://emil.fi/bashwin. I didn't implement task monitoring but it should be pretty easy to extend.

| improve this answer | |

Have you tried this solution?

It uses a WSH helper to launch any application hidden.

Then you can just create a new task in Tak Scheduler to launch the command when you login. Something like wscript <path to runHidden.vbs> bash.exe -c "python script.py"

| improve this answer | |

It took me forever but I found a stupidly complicated way of doing it (from a batch file):

start bash -c "DISPLAY=:0 [command] & (sleep 0.5 && kill -n 9 $$)"

Here's a breakdown of what it does and why:

  • `start`: to make the batch file window go away
  • `bash -c`: lets you run a bash command
  • `DISPLAY=:0`: sets your X-server
  • `[command]`: your command/commands (`[command && [command]`)
  • `&`: to make the next command run after it starts and not when it's done
  • `sleep 0.5`: to make sure the process has started
  • `&&`: to make the next command run after it's done and not when it starts
  • `kill -n 9 $$`: to kill the bash shell so it's only the graphical application

Note: DISPLAY=:0 sets it to the x-server at :0. To change it to (eg) :1, do DISPLAY=:1 etc.

Note: start is only required if it's from a batch script. If it's from the terminal, you don't need this

Note: sleep needs to be set differently for each application. You might even need to omit it.

| improve this answer | |

I don't know how well Windows Service Manager (SrvMan) from http://tools.sysprogs.org/srvman/ would work for you, but it has worked for me for other programs. In fact, I did tried running the "bash.exe" as a service to see if it would work, and I'm guessing I have to tinker around a bit more to get LAMP to actually work in the background.

| improve this answer | |
  • 1
    How does this address the question  of how to run a Python script in the background? – Scott Jul 6 '17 at 2:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.