Windows Bash services are stopped when closing the Bash tab

[Skalin]

This is just a FEATURE!

• All services from WSL are terminated when I close all instances of Bash
• There should be a setting allowing me to run them allways in the background and also at the start of the system. This disables the @reboot ability of cron.
• My Windows Build Number: 14393.5

[rodrymbo]

See https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13301121-let-bash-continue-running-even-when-the-terminal-h

[russalex]

Thanks @Skalin

The ability to run without having a terminal open is a heavily requested feature for daemons, cron jobs, and other scenarios. Please vote on the User Voice page listed above (thanks @rodrymbo).

Also note that we are pretty locked down for the Anniversary Update but will be looking at this for future releases.

[fpqc]

There is a trick, just run a copy of bash.exe with the third-party run.exe program on startup.

[Skalin]

Why the hell would I use thirt-party program to start something implemented in Windows?

[fpqc]

@Skalin I dunno, because right now the feature that you want isn't directly supported, and for the moment it's your only choice to get the annoying black window off of your screen!

The feature for windows says it is in beta when you installed it, but it might be better called an alpha, because the feature list isn't frozen.
Run.exe is open-source (GPLv2) and of part of the Xming project and is available (32-bit, 64-bit, and source) at:
http://www.straightrunning.com/XmingNotes/#head-148

the manpage is available here:
http://www.straightrunning.com/projectrun.php

Also, I don't work for Microsoft, and I'm just trying to help you out, so there's no need to be short with me.

[russalex]

Thanks for pointing out run.exe @fpqc. I have not tried it myself and it is good to know that there is a potential work-around for people who want to run without a console window up. You have mentioned it in a few other threads and it looks like a useful tool for many.

I am always amazed at this community and it's ability to work around features we simply haven't had time to implement. It just shows the desire for WSL as a whole. Rest assured we will continue to work on natively supporting many of these features. Until then, workarounds like this may be required for some scenarios.

Please keep the feature requests, and the potential workarounds, piling in.

[xilun]

@russalex Great to hear that you are warming up for the next round of great stuff :)

@fpqc maybe you can also open a topic about running in the background on http://wsl-forum.qztc.io/

[lawre]

+1 for WSL as a service, sorely needed to get cygwin off the desktop.

[lawre]

@fpqc run.exe works beautifully. I'm just curious why you would run a copy of bash.exe rather than point it to c:\windows\system32\bash.exe? I find this is working fine.

[fpqc]

@lawre idk it's already in the Windows PATH, why would I write the full path to bash.exe when it lives in system32?

[fpqc]

@xilun idk, I made an account on that forum and never got the confirmation email =p

[aseering]

@fpqc -- could you try again?, and check your spam filters? I'm currently hosting that forum, but the hosting provider has been flaky. If it doesn't work, I may migrate elsewhere.

[fpqc]

@aseering found it in my e-mail spam folder. Cool registered *shades*

[felipemouradev]

Hi everyone, I had problem with cron service, but I solved it with node-cron and forever... Thats works...

[heldchen]

from todays 17046 release notes.

Allow background processes. [GH 709, 1007, 1511, 2252, 2391, et al.]

wow! how?

[Brian-Perkins]

I will update that wording slightly. This support enables processes to run after the last terminal has been closed. There is not yet a direct mechanism for starting processes at boot, etc.

[therealkenc]

Nice. But you probably saw this coming.

ken@WinDev1612Sys:/mnt/c/Users/there/source$ ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /init ro
   36 ?        S      0:00 dbus-launch --autolaunch=2e97729bd10d45a992b7e6901e82eb13 --binary-syntax --close-stderr
   37 ?        Ss     0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
   45 ?        Sl     0:00 /usr/lib/gvfs/gvfsd
   57 ?        S      0:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
   59 ?        Sl     0:00 /usr/lib/dconf/dconf-service
24031 tty1     Ss     0:00 /init ro
24032 tty1     S      0:00 -bash
24317 tty1     R      0:00 ps ax

What is the preferred method to shut down daemony things that get launched? In this case they were a side effect of opening a large popular application that helpfully autostarts stuff it needs. I assume killing them manually by PID is the way to go for now.

As a total side note, that gvfsd (of all things in the world) autostarted without any errors or warnings. It can't possibly "work", of course. But it sure made me laugh.

[therealkenc]

WSL no longer panics when the last console instance is closed. Available in Spring Creators.

[ivivanov-bg]

Any way to disable this 'new feature' ?

[therealkenc]

Any way to disable this 'new feature' ?

Short answer is you can kill off the WSL instance with wsl --terminate <distro> on 18305 or better.

Longer answer. I suppose it would be possible to put an exit trap in your .bashrc that counts existing bash processes, and then kill off all other detached processes (with sudoers tricks) if that bash instance was the last one standing. Wouldn't recommend it. But doable I guess.