Hi @deyvisonrocha -- are you able to run a command to start each of these services manually? If so: There are instructions here on how to start sshd when your computer starts. You could probably do the same thing for each of the three services that you listed, but swap the command to start sshd with the command that you are using to start each of those processes.

Sounds very much like #612, and the Devs seem to think it needs a resolution of this Uservoice issue.

It's possible to get things running as services, but it is not exactly user friendly. I'm still having trouble getting services to start after the OS boots but before I log in.

One could probably make a folder somewhere, populate it with scripts that need to run as "services", and use run-parts to start them all. Think of it as an alternative to init that just launches things in a folder on startup. Having that as a workaround (or something else) might make it easier for volunteers to support as more and more people try to use WSL. The question is, whether the "official" WSL method that is in the backlog will take long enough coming to make it worth one's while to implement.

@aseering It did not work for me. =/

@deyvisonrocha -- hm... Do you have any errors in either the Windows Task Scheduler or the logs for the programs that you were trying to start?

There was also recently a mention on some ticket (I forget which?) that recent versions of WSL require that the Windows startup script used here to also restart the lxssmanager? Maybe someone here will have seen that thread and can comment.

To give a little bit of context why our service story is currently a little funny. We create a WSL "instance" when an NT client launches a Linux binary. Other NT processes launching Linux binaries will create them within the same instance. When the last NT client goes away the instance is terminated meaning all Linux applications running will exit. This way you're only running Linux binaries when you need them.

Services represent an interesting design problem. To support running them natively we'd have to boot an entire (potentially a subset) Ubuntu OS including the Ubuntu's init and daemons. These would be running at all times and you'd essentially be running two full operating systems with one kernel.

We're definitely looking at ways to support running Linux services better in the future. Potentially some kind of "keep alive" to keep an instance running even after an NT client has gone away.

@benhillis I even came up with a name for this "ubuntu as a linux service host process" idea, "lxsssvchost.exe" with obvious allusions to the Win32 service host process.

@benhillis - As long as the -c "scriptname" option works with bash.exe, if you put a "while true" loop at the end of the script (with some sleeping to keep load reasonable?), it will run pretty much forever. Or one can run a daemon in the "foreground" to keep the environment open forever. The technique for launching it from Task Scheduler without a console window cluttering the desktop means we are almost there (see the instructions at Adam's forum, and other places, for the technique).

It's not a full upstart/init, but it is definitely running without a console window open. Keeping the script running forever or the daemon running in the foreground means the environment doesn't close. So it clearly functions as a service, even if we have to go through extra steps to make it work. So having the devs operating on the assumption that the only thing that can possibly work is the full console while the user is logged in -- that seems to be a bit more restriction than needed or helpful.

@rodrymbo Personally the -c "scriptname" in a while loop sounds worse than just keeping a bash.exe window open. What I'm going to suggest is simply a workaround (not a final solution) but I feel like I can share it since this is a developer feature :)

If that part really bothers you, you could always write a small NT app that uses the CreateProcess api to launch bash.exe hidden (and then sleep forever).

http://stackoverflow.com/questions/780465/winapi-createprocess-but-hide-the-process-window

That being said, we do have an undocumented com interface that some people have already started poking around at (#790) that could be used to similar effect. Eventually I suspect we will document the interface, but later when things are less in flux.

@benhillis -- well, the while loop is in the bash script, not a CMD script. So it basically keeps the bash script running forever, like a daemon running in the foreground. The point is that technique, run from Task Scheduler, means the console is not running. The process running forever inside bash.exe keeps it from exiting. So while CreateProcess would do it, TaskScheduler does also, and doesn't require me to compile anything. :P

A while loop in Bash (or sleeping forever) is a bit inelegant. If you need something simpler, think of running sudo /usr/sbin/cron -f or sudo /usr/sbin/sshd -D -- both run forever (without an external script sleeping anywhere) if one minimizes the console window, or if one launches it via Task Scheduler with the technique I mentioned so there is no console window to be closed accidentally.

The reason something has to run or sleep forever in the foreground, is that, since it is a script, it is not running interactively. As soon as the last thing finishes, the script -- and bash -- exits, so anything launched into the background is lost, by WSL design. So you can have a script launch things into the background or as daemons, but unless it sleeps or does something in a loop, or launches the last process to run forever in the foreground, as soon as the script finishes, bash and all the stuff it so carefully started running, will close (currently).

Bash scripts can sleep forever too :-) sleep 99999999999999....

Sleep -1 for the win?

Nope! No sleep for us.

$ sleep -- -1
sleep: invalid time interval ‘-1’
Try 'sleep --help' for more information.

Try not to lose too much sleep over the 'interesting design problem' of having two operating systems running. I don't know about everyone else, but according to my Resource Monitor, I've got several operating sized systems running already. My biggest operating system, by far, is called chrome, which on an average day has a commit size of around a half a gigabyte whether there's a browser window on my screen or not. In second place is MsMpEng.exe, which, based on the 200MB committed as I write this, I'm going to go ahead and assume must be running it's own operating system under the hood. The svchost.exe tree comes in third.

So at this point, I'm pretty comfortable with init/upstart starting on boot.

@therealkenc -- you should start emacs, add another operating system :-)

(says /me as an emacs user)

@rodrymbo et al -- I've summarized the sleep <bignum> approach here:

http://wsl-forum.qztc.io/viewtopic.php?f=6&t=10

Definitely a workaround. But it might help for now.

Joking aside, I hope this is solved by just putting the WSL 'instance' in the tray, just like Chrome or OneDrive. Defender is only offensive because it has no 'exit' menu item. That's also where lxrun functionality goes. A keep-alive mechanism fighting a reference-count mechanism is a classic anti-pattern.

A pretty little tray icon would be nice, but a higher priority for me would be getting a few daemons going at boot (before the user logs in). Being able to start sshd and cron and maybe a web browser or database would make things much more useful.

I suppose some might want to try to get a full Ubuntu system going at boot, but I'd be happy with just a few things. A bash console has almost everything we need, once a few processes are running in the background, like syslog and cron (assuming network interfaces and other gotchas are fixed).

The icon isn't the point. Having lxrun /stop would be fine. The difficulty comes from the referencing counting, and the false premise that GNU Bash is a special program. init needs to fire up exactly one service: wsld. This launches gnu bash (by default) and doesn't prompt for credentials (by default).

If people want their init to also fire up cron, rsyslogd, sshd -- plus apache, mongodb and compiz for all I care -- whatever, that's their business. Those don't fit the model that 'MS Bash Prompt' exists for grep/sed/awk/git though - that is, programs that talk to files, ttys, and outgoing sockets. But the only thing that's missing here, critically, is init and wsld. Everything else is just configuration detail.

@therealkenc - The normal linux paradigm would have bash (or probably login/getty) open a terminal window, do stuff, and then close the window again when bash exits. And if all of the Ubuntu daemons and services were left running when that bash console closes, I'm sure there'd be too many complaints to Microsoft. So it seems to me that having things run in the background or as daemons or services should be reserved for those who tell WSL that's what they want. But once we have that sort of environment running, I'd say it should stay running until the user tells it to stop. And once that environment is running, there'd be no need for reference counting, just the usual process management, commands inside the bash environment (like ps and kill, perhaps shutdown). Having lxrun.exe /stop (or bash.exe -s or a menu from a tray icon) would also be useful. It looks to me like Microsoft has designated lxrun.exe for managing the image, while bash.exe (not GNU bash) initiates the WSL environment and runs /init which runs GNU bash.

It looks like your idea of wsld has been incorporated into /init, which is a Microsoft program, unlike the usual /sbin/init. When one uses one of the techniques for starting a service (e.g. sshd) automatically, in many of them init becomes the parent process, not bash. So in a sense we're already most of the way there. I haven't experimented to see whether /init is watching for the last bash process in order to shut things down, but I'd guess that is the culprit. My point is that we can see that things are working (/init is PID 1 and runs things, including bash). It's just a matter of merging the linux paradigm. (In other words, I'm not saying that wsld and init need to be merged or separated, conceptually, still just talking about the paradigm.)

I think I would support it defaulting to shutting down when the console closes, for normal users, as long as we can easily get to a more complete environment (syslog, cron, etc) that starts when the user logs in and potentially when the PC boots. It looks like the pieces are there and working, it's just a matter of the WSL devs putting together the best way to do it and finding time to implement it.

The 'normal Linux paradigm' doesn't even know what a window is. Never heard of them. Bash doesn't know what a window is either. On Linux, the X11 service from X.org knows what a window means.

As I said, none of the Ubuntu services you are talking about need to be running. None of them. They can, of course. But they don't need to. wlsd and init serve different purposes. wsld is more like getty.

Microsoft seems to be perfectly okay with 33MB worth SkypeHost.exe running on my system, waiting for a packet that will never arrive. Close all your cmd windows. conhost.exe is still running. There is no reference count on conhost. wsld is not semantically different, other than the fact that it runs in the WSL pico process and is an ELF64 object. 'Normal users' wouldn't enable WSL on their systems, so it wouldn't be running, of course.

We are pretty much there, now, except Microsoft seems to be saying that the minimum number of things running (besides init) should be one (bash) while the rest of us are saying we'd like the option to run 0 (or at least 0 bash) without it shutting down. I doubt it would run with 0 very often, but that's a way to generalize, sure.

init in WSL doesn't seem very huge or use much resource (in real time). It probably has a virtual size that is much larger, but it's not using it all the time. I can't imagine Microsoft thinks having init running all the time will bog down a machine being used by a developer. (It might on a phone, but I wasn't contemplating setting up a cheap underpowered phone that way.) So it is just a matter of convincing them it's what we want.

Microsoft wants us to tell them what we want it to do. Almost every use case for me involves some daemon or service or something running in the background. Programs I run (not all) expect to be logging to a syslog daemon. Jobs need to run when I am not sitting there to start them, and they want to log to syslog too. And so forth. I expect to be able to have some things running all the time. Having everything in /etc/init.d running probably wouldn't be that huge a deal, but I don't need more than a few, or even the same ones all the time.

I probably shouldn't call them "windows", those rectangular things with the black background and white text (typically). Regardless of what I call them, I think of them as terminal emulators, like the physical terminals I started out with (after playing with actual teletype-and-paper style machines). But yet they are rectangular, and all those other rectangular things on the desktop are called windows, so there you have it. Bash does of course know whether it is talking to a terminal (interactively) versus running in the background, and what kind of terminal it is controlling. Perhaps we can get away with a relaxed use of "window"?

I think I like the terminal paradigm in linux better than the cmd/conhost console in Wndows. Being required to have conhost hanging around seems somewhat backward. But what I've seen is conhosts closing when they aren't needed. The only conhosts running on my machine are associated with some process that thinks it needs to run in a console (even when it isn't visible), and the conhost closes when that process closes. Maybe there are some that don't close, but I've not seen them. So probably not the best example of things running in the background all the time without closing.

The physical VT100 terminals you started out with talked to a service that ran all the time without closing. It's called getty.

init
  ->getty
      ->login
      ->bash

Instead of looping or sleeping just add "bash" to the end of the shell script. Here are my scripts for apache and mysql to run on startup.

VBS file (runs on startup)

Set WshShell = CreateObject("WScript.Shell") 
WshShell.Run "C:\Windows\System32\bash.exe -c ~/autostart.sh",0
Set WshShell = Nothing

autostart.sh file

#!/bin/bash
sudo service mysql start
sudo service apache2 start
bash

and in /etc/sudoers

# Allow apache2 and mysql to start without a sudo password
%sudo   ALL=(ALL) NOPASSWD: /usr/sbin/service apache2 *
%sudo   ALL=(ALL) NOPASSWD: /usr/sbin/service mysql *

If I need to kill it all I can find the bash process in Task Manager and kill that.

People can argue back and forward about the best way to do this but at the end of the day as a developer all I want is when services like nginx, PHP-FPM, etc are told to start at start-up I can expect them to be running next time I login to start working on something

@AaronMcHale parts of this feature are already implemented. It's coming along, so please be patient.

@AaronMcHale - Exapanding on @fpqc comment, for example, you can see this blog post for support for background tasks. So, while, startup tasks are still not supported, workarounds are possible now.

@sunilmut Is the old WSL blog abandoned? If so, you should put a post on there pointing people to the commandline blog. Or is that blog going to be reserved exclusively for technical details of the WSL internals?

No, the old blog is for more technical topics.

These would be running at all times and you'd essentially be running two full operating systems with one kernel.

I actually like the idea of 2 full operating systems with one kernel. Just look at the history of the kernel. "Strictly speaking, an operating system (and thus, a kernel) is not required to run a computer. Programs can be directly loaded and executed on the "bare metal" machine, provided that the authors of those programs are willing to work without any hardware abstraction or operating system support." This being the case, there's no reason why we can't make it so services start from Linux upon Windows boot. Just provide the core that allows Debian, RPM, Gentoo, etc. -based systems to run upon boot once you install a distro. Work has already been done to make WSL agnostic to a particular distro. Autostarting services really is a necessity for devs (who are the target audience right now) but also for enterprise scenarios as well. The overall goal of WSL shouldn't just be about devs, it should be about supporting all customers who could potentially utilize it. This one issue would be one of those things to help reach that goal.

2 years passed, does MS have ability to solve this simple issue?

Wanted to install Redis on windows today and found the documentation to refer to run it under WSL.
Nice and easy, but having to run start bash and do sudo service redis-server start after each reboot is a no-go. I rather use docker. https://redislabs.com/blog/redis-on-windows-10/

Ran course. LZ for systemd #994.