-
Notifications
You must be signed in to change notification settings - Fork 823
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
Blockers for systemd? #994
Comments
Something in this old thread ( @jackchammons ), but it seems that WSL (and all the Win10 kernel design) is a Top Secret. :) |
Considering how open the Devs have been hereabouts, I'd say the issue isn't so much "keeping it secret" as "it's a moving target". I don't think it will take too long for the Devs to figure out that what they are presenting to us is "single-user, console". To a Linux person it is like Safe Mode is to a Windows person. Yes you can do stuff in Safe Mode, and sometimes you are amazed that it even works at all, but it's not the same as running Windows, just as running WSL without cron or syslog or sshd or a terminal emulator (what we have got is sort of a console emulator) and other servers/daemons/background tasks, is not the same as running an Ubuntu developer machine. I can be happy without upstart/init/systemd running everything that comes with a fresh Ubuntu install. But the things I work on generally do logging to syslog, and don't have an option for logging to a file; so trying to work on them without rsyslogd is quite difficult. It's nice to be able to run a bash script from a shell prompt, but what would be nicer is being able to run a few from cron, to automate things. And so forth. So let's see if we can figure out what is blocking systemd, but I'd guess that when the Devs decide it's something they need to implement, they'll figure out a way. |
@rodrymbo I'm just interested for my own curiosity. Like, is the main blocker just cgroups, or is it something more difficult? Like, is WSL architected in such a way that its init process needs to be a special one generated by MS, or did they just make a stripped-down init process because they haven't implemented cgroups and didn't want to bother supporting upstart when they knew it was already obsolete? Basically, I want to compare against this: Aside from cgroups, the requirements don't seem that crazy to emulate. I don't see the specific syscalls mentioned in that guide listed in the list of supported syscalls for WSL, but on the face of it, you need cgroups, "open by fhandle syscalls", eventpoll syscall, signalfd syscall, and timerfd syscall. The rest of the requirements appear to be things that are at various stages of implementation. P.S. Mercifully, it looks like the Redhat devs have given up for now on pushing things like dbus into the kernel for the forseeable future (there was a big blowout on the kernel.org mailing list over kdbus, and kdbus was dropped from Fedora Rawhide a bit later). |
@fpqc init, upstart etc etc requires a continuous operation; in this moment WSL exists only when calling bash ... perhaps in the future will be different ... (?) Sorry for my bad English. |
@iz0eyj That's not true, do You will see that the init daemon is running at pid 1. |
@fpqc - The Microsoft init ( Not saying you shouldn't be curious, or that trying to figure it out based on clues might not provide an interesting way to pass time. It looks to me as though they could implement most of a whole linux userland system if they wanted, and much more of the rest of the system, by which I mean to a user everything would work as expected including services. So the issue will likely be how much of that can users like us convince them (in Uservoice or whatever) is worthwhile. @iz0eyj - right now, most of what you describe is happening: when Bash.exe runs, init is running (apparently launched or managed from svchost.exe or lxssmanager or something). No, it doesn't start when Windows starts (yet) but neither does each Bash.exe console start another init. And yes, it does stop (and tear down the environment) when the last Bash.exe is closed; but until that last Bash.exe closes, init is there, running along in the background. From my perspective, the tearing down of the linux environment is just a matter of the Devs requiring that the system "shutdown -h now" when the last Bash.exe closes. So in a sense, init is running continuously ... when the environment is running. I agree that for many things it would be good enough for init (or whatever accepts system calls) to return dummy responses that satisfy whatever we are trying to run. For example, @fpqc - For some things it is helpful to look in Process Explorer to see that init is running under a svchost.exe. What you see from |
@fpqc - is there a reason for implementing systemd in WSL other than bragging rights? It looks to me like that would bring along a lot of baggage we might not need. Could we go to something closer to sysvinit or whatever for starting a few services, or would having systemd implemented give us a lot of benefits I'm not seeing? |
For myself, I would like to be able to run systemd not to replace the WSL init, but because being able to start a pseudo-init with systemd --system --unit=foo.target would be a convenient way to start and subsequently manage a set of services/daemons required for a particular development, etc., configuration. By having multiple .target configuration files, that way systemd could be used to set up whatever service-set happened to be needed for a given session in a suitably Linuxy way. (And, I suppose, those who want services running all the time could put bash.exe -c /bin/systemd into a startup shortcut, but that's just gravy compared to the convenient start-and-manage service functionality that'd come out of it.) ((I added a uservoice request for this here, BTW: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/16571479-support-for-running-systemd .)) |
Well this future would be great to use PostgreSQL or MySQL in Xenial instead of the Windows Installer. The creators update did many things right, but this would be extremly huge as well. The best thing would be that Windows would be clean and the Development environment can be trashed and cleaned really really easy. |
If the desire is to manage a set of services under WSL in a more "linuxy" way it may be worth generalizing this discussion to look at other light weight approaches of doing this. SysV init is one option but there are others that have been developed for more constrained environments that may be of interest for example:
I'd hazard a guess that systemd may be one of the trickier ones to implement let alone track. I suspect the main motivation for WSL is twofold: for developer tools and for running containers. In both cases they tend to be single thing or chain/group of things per invocation. |
@carwyn All of the distro devs with whom MS has announced support (Ubuntu, Redhat, and OpenSuse) are now firmly in the Systemd camp, and all of their package managers and packages assume systemd is running. MS does not want to maintain its own distribution of Linux userland for WSL. Presumably if they do make a switch over to systemd from WSL-init, there should be nothing stopping you from writing shellscripts to wrap the interop daemon to work with sysVinit scripts. |
@fpqc granted, although there is also a MS relationship with Docker although that seems more about container management rather than what's in them. Having said that Docker seem to be sniffing around Unikernels a lot. |
one of Ubuntu official develops says M$ |
You may want to try using Upstart to run and manage third-party services |
@kenshen112 writes in another issue:
The locations of those files are controlled by Canonical via the Debian My |
@therealkenc as far as I understand all .service files should be in /etc/systemed which most aren't and that's what causes the error as far as I can see if i execute the command in my post copying the files from there previous location to /etc/ it works aside from the permission's issue. if that's how conical has it by default though then I wonder if there's a symlink missing somewhere??? |
I haven't looked into |
so first off https://askubuntu.com/questions/894419/systemd-on-ubuntu-16-04-gives-no-such-interface-error one small example of the same problem / fix occurring in ubuntu 16.04 sysctrl is a tool that allows one to create and manage service files used by systemd - the reason I said it could help us https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units it manages the stopping and starting of systemd services a key piece of what systemd does as a whole so whilst it might not fully fix systemd it'll give us some of the functionality of it at least for sysadmin's that's incredibly useful. |
@kenshen112 no. Only changes or custom systemd unitfiles go into /etc/systemd. default unitfiles belong in /usr/lib/systemd/system Systemd provides tooling to build and store diffs of default unitfiles in your /etc/systemd/system as well as completely custom unitfiles. |
I'm using SUSE Linux Enterprise Server 15 SP1 on my windows 10 machine. I installed it from microsoft store. I facing the same issue mentioned here. Is there any workaround to start (force) the services. I tried all the things mentioned. Please help. |
Well, you could use genie and start a "systemd bottle", I suppose. I don't know if there is a SUSE package for genie, though. That said, I suppose WSL could provide something like genie out of the box, since many WSL users' workflow depend on systemd. |
I've been using one-script-wsl2-systemd solution ( |
@nezorflame After following the manual installation, not able launch my wsl distribution. (after the terminate command mentioned). |
@nezorflame After following the manual installation, not able launch my wsl distribution. (after the terminate command mentioned in the https://github.com/diddledani/one-script-wsl2-systemd/tree/build-21286+). |
I suggest creating an issue in the project's repo instead. |
Genie seems to be the most used systemd solution for WSL https://github.com/arkane-systems/genie But there are still quite a lot of issues with it |
Some people recommend to just a proper VM, for example with VMware Workstation. But with this we lose the great Windows integration WSL gives us. For example with |
You can run WIndows apps in Linux with WINE, which simply proxies WinAPI to Linux counterparts. |
@EmpiricEmpire, at my job I'm currently limited to Windows and Mac |
WINE is supported on Mac as well https://www.winehq.org/ |
Let's stay on topic of systemd in WSL please. |
Agreed. Plus Wine is pretty much a non-solution. systemd for WSL is still a huge blocker, and IMO the largest blocker yet. |
Not sure what issues there are, what workarounds they've done, but Distrod is another systemd-init on WSL. |
Two issues I've run into recently due to this:
So in general I think there's a long tail of stuff that directly or indirectly depends on systemd being available. |
FYI: https://www.theregister.com/2021/11/17/ubuntu_team_systemd_windows_wsl2/
I wonder if Canonical is in contact with people from MS WSL? |
We're still keeping the ability to run non-systemd installations right? Being beholden to systemd would destroy our development process |
There is now support for systemd in WSL, for more info on how to use it please read here. |
if is for only windows 11, is useless :( this need to be retro compatible with windows 10 greetings |
For various reasons, it isn't obvious to me exactly how to determine what features are missing from WSL's implementation in order to get something like systemd up and running. From the documentation, we know for sure that WSL does not yet implement any of the syscalls related to
cgroups
, and doesn't include any of the kernel namespaces, which is probably a blocker at the moment. Are there any other missing syscalls or socket options that would block systemd from running?I also am attaching the output of
strace systemd --test
systemd-trace.txt
(using the docker image of Ubuntu yakkety installed with RoliSoft's python script)
Also, I know that WSL currently uses a kind of hardcoded init process (which sets up the network interfaces, remakes the /etc/hosts file, does some other stuff, then (I think) forks /bin/bash by default). Would the whole initialization process need to be rewritten from scratch to use systemd as the init, assuming all of the other dependencies were eventually implemented (cgroups, aforementioned missing syscalls and socket options)?
The text was updated successfully, but these errors were encountered: