25

As I've understood it, systemd is Linuxes' "master"-daemon, managing all other processes right after it has been started up and run its init-function. Since I had this (now resolved) issue, of not being able to use any systemd commands on WSL I realised, that it does not have a systemd process at all.

Now, out of curiosity I wanted to know, which process management WSL relies on instead of systemd. Since I've not found a satisfying answer on the "general google search", I thought, lets try it here.

2
  • 13
    The youth already understands systemd as an integral part of Linux. What a pity. blog.desdelinux.net/en/list-free-systemd-distributions And, as a general example: Android does not use systemd as well.
    – fraxinus
    May 5 at 21:17
  • 14
    It works without systemd in the same way that every other version of Linux did in the 25 years before systemd became common.
    – Mark
    May 5 at 23:01

4 Answers 4

37

Great question -- So much fun stuff to cover here.

First, let's establish some terminology:

systemd is Linux's "master"-daemon, managing all other processes right after it has been started up and run its init-function.

First, a good point from @mascoj in the comments is that Systemd isn't required by Linux at all. It's certainly used in the vast majority of Linux distributions, but there are other alternatives (as @user1686's answer mentions) that both predate and have come since Systemd. Some distributions use these alternatives by default, and (personal opinion) some of these distributions may work better under WSL as a result.

At a high level, Systemd typically serves several functions:

  • Init system: Performs boot-time system initialization (e.g. creates or cleans temp files, etc.)
  • Run services at boot (e.g. cron, sshd, mariadb, etc.)
  • PID 1 process: The master process under which all other processes live
  • Process supervisor (a.k.a. process manager): Starts, monitors, restarts additional services
  • Additional services (Systemd does a lot, e.g. logging, mounts, and much more)

Most of these functions can be handled separately, but Systemd "does it all".

Some distributions and systems don't rely on Systemd and do things less monolithically. For instance, some systems have the init system hand off control to a separate process supervisor at some point during the boot. The process supervisor may nor may not be PID1. If it's not, then typically the Init process remains as PID1 and the process supervisor runs under it. The process supervisor typically has a list of services that are desired at boot time, and it executes and monitors these.

Some distributions (Artix comes to mind, and I'm fairly certain Gentoo as well) allow you to mix and match from several different init systems and process supervisors.


Now let's cover the question in the title at a high level:

How does WSL/WSL2/WSLg work without Systemd?

  • WSL2:

    It's important to understand that, when you are running a WSL2 distribution, that distribution is not running in a virtual machine. WSL2 itself is running a virtual machine with its own distribution (probably Mariner-based, if I had to take a guess).

    Inside that hidden virtual machine is where your distribution is run in its own set of namespaces. If you run more than one distribution at the same time in WSL2, they are all running in that same VM, each with its own:

    • PID namespace
    • Mount namespace
    • IPC namespace
    • UTS namespace
    • WSLg System Distribution (Windows 11 only)

    However, they all share the following with the parent WSL2 VM (and thus each other):

    • User namespace
    • Network namespace
    • Cgroup namespace
    • Device tree (other than /dev/pts)
    • CPU/Kernel/Memory/Swap (obviously)
    • /init binary (but not process)

    This is very, very similar to the way that container systems, such as Docker or Podman (and others), work.

    And inside most (but certainly not all) containers, you'll find it rare that a process supervisor is running.

    Most containers are told what services to start by the "outside" process (such as Docker) that starts them. In the case of WSL, there has traditionally been the wsl command with which you tell WSL what services to start. E.g. (an oversimplified and not necessarily a great example):

    wsl -e crond
    

    However, one important difference is that, unlike traditional containers, WSL always has its own Init process that runs as PID1 (see below for why). For most other container types, PID1 is the process you tell it to start first.

  • WSL1

    While WSL1 isn't technically "running in a container/namespace" like WSL2, it does share the same Init concept for interoperability.

    It's also important to remember that WSL1 doesn't support all Linux syscalls. When WSL1 first shipped, it's coverage was somewhere around 70%. It does a fairly great job of running a large number of tools, but I have a feeling that the number of units that Systemd normally attempts to bring up would probably expose some gaps.

  • WSLg

    WSLg runs in what is called a "System distribution", which is definitely based on the Mariner distribution. One WSLg system distribution is created for each WSL2 distribution that attempts to run GUI applications.

    In this case, it's really up to Microsoft to determine how to launch the necessary services. You can create your own system distribution, if you'd like, and Microsoft provides a reference implementation to start with, but there's likely very little need for Systemd's functionality there.


None of that is to say that running a process supervisor in WSL (1 or 2) wouldn't be useful - It would in some cases. But personally, I'm glad that WSL leaves this up to the user. This allows it to operate like a container (fast startup, efficient resource usage) by default, but more like (but not quite) a full-blown "virtual OS" in other cases.


And the main question:

Now, out of curiosity I wanted to know, which process management WSL relies on instead of Systemd.

Let's break it down into the functions that we said Systemd handles above:

  • PID1/Init System: As mentioned above, WSL's proprietary /init system is used for both these functions. This special /init is needed because it handles the deep interop integration between Linux and Windows. Traditional Linux init systems such as Systemd have no idea how to handle this.

    In theory, WSL2 could use Systemd to boot and set up some special services to handle the integration, but:

    • This would add overhead to a very streamlined startup

    • Some distributions don't use Systemd, so they would have to configure each distribution differently (best to leave this to the user, if needed).

    • It's possible that /init would still need to be PID1 anyway, to continue to handle certain Interop features even after boot.

      Since Systemd requires that it be PID1, that creates a bit of a conflict. I do think the Microsoft team is working on this, but it's clearly not something that has been solved yet.

  • Process supervisor/manager: WSL2 really doesn't have one by default. However, as @user1686 pointed out in another answer, that hasn't been a problem until recently. Scripts were created for each service, with entry points for the service command (or similar) to start/stop/restart/status.

    Ubuntu, at least, still provides many of these scripts for services. So when you want to start sshd, for instance, you can just run sudo service ssh start, which in turn calls its script. Same if you install Maridb (sudo service mysql start).

    However, some services don't provide SysVInit-style scripts. They may only provide Systemd units instead, at least on Systemd-based distributions. These just won't work (easily) on WSL distributions. See this answer where I cover the alternatives when that happens.

  • Run services at boot

    Under Windows 10, there still isn't a great way to handle this. Of course, a WSL distribution doesn't really "boot", but it does have a defined "first start" where you might want to run something.

    Under Windows 10, the best best was to either start the services manually or run them via your user startup files (e.g. ~/.bashrc). See this answer for some ideas on that.

    But it sounds like you are on Windows 11 (since you mention WSLg), and in that case, there is a feature that allows you to specify a command (or series of commands) to run once when the distribution starts. Again, see this answer for the information on how to configure that.

Running a process manager at startup

Using these techniques, it's entirely possible to run whatever process supervisor you want, as long is it doesn't require that it be PID1.

Some that I've tried so far on WSL:

  • Supervisord designed for running services in containers.
  • dinit -- Available for Artix, an Arch-based distribution which has 5 different init/process manager options that you can use.
  • s6, also available with Artix. This one had some issues under WSL2, and I think they were on the WSL2 side, but I can't be sure.

Both s6 and dinit tend to think they are running on a physical/virtual machine (naturally), so they attempt to do some startup that isn't necessary under WSL. I've been able to remove the unnecessary items, and then dinit, at least, runs quite well. I haven't rolled these into a reproducible set of instructions for others, yet, though.

Running Systemd

It's even possible to run Systemd, by faking it out so that it's running as PID1 inside a new namespace inside a WSL2 (but not WSL1) distribution (which is, as we discussed, running in its own namespace already). I don't necessarily recommend it, personally, but lots of folks do. I cover some of this towards the end of this AU answer, so I won't repeat it here.

8
  • 3
    There is a very common class of containers that do run a full init (frequently, systemd) – "system containers" managed using LXC, nspawn, or OpenVZ. Way too many people think Docker invented containers...
    – user1686
    May 5 at 14:52
  • 3
    Great answer, only thing I think it could use to clear things up a bit more is that systemd is NOT part of linux. It is a convenience utility built to run in a Linux distribution.
    – mascoj
    May 5 at 21:06
  • 1
    @mascoj Also a good point - Edited to make that explicit. May 5 at 22:44
  • 1
    @NotTheDr01ds: Systemd can be PID1 if it's run in a process namespace (PID_NS), which is how system containers generally work already – that's a big part of what distinguishes them from classic "chroots". (Even in Docker/etc., the main service process is the container's PID1.) I would be somewhat surprised if WSL2 didn't use PID namespaces along with everything else that it does use.
    – user1686
    May 6 at 4:26
  • 1
    @DanM. You are correct that I primarily focus on WSL2 here. There are some differences as far as this question goes, but they aren't as substantial as you might think. Both WSL1 and WSL2's primary conflict with Systemd is the PID1 clash - WSL's init on both versions runs as PID1, which is the main reason Systemd doesn't run on either. The workaround mentioned in the last paragraph, however, is only available on WSL2, since it requires kernel namespace support. I'll see if I can work some of that into the answer when I get a chance. Thanks! May 6 at 17:13
27

Systemd is actually a fairly recent project, having been started in ~2010. Many others have been used before it: sysvinit, upstart, init-ng, s6, launchd (I think it had a Linux version once). Several Linux distributions still do not use systemd for various reasons.

Out of all those, systemd is the closest one that you even could call a "process manager". Linux doesn't actually rely on a process manager at all; any process can directly make (fork) a new child process whenever it decides to, uncontrolled. (Indeed so uncontrolled that when systemd started codifying things like "logging out should kill your leftover processes", wars were fought over it.)

The real primary job of systemd and other such programs is only to be a service manager: to automatically start certain specific processes, such as the daemon responsible for displaying the login screen (GDM, agetty) and – sometimes – to restart them when they crash. But once you get to the login screen, everything else can happen without the involvement of systemd/init.

Indeed with sysvinit, the actual init process did incredibly little: about the only service it oversaw was agetty. Literally everything else was done through ordinary shell scripts that never touched init proper. The command to start a service? Shell script. The whole initial boot process? Shell script that runs more shell scripts.

So for something like WSL, which doesn't want to behave like a full system (it's not supposed to be like a full VM that you have to boot before using; starting WSL meant to be instant, as if you literally were running Linux apps on Windows), the init process can be fairly minimal. I don't really know what WSL2 uses, but it could be completely custom.

(For WSL1 there might not even be an init process, given how WSL1 isn't even a VM but only a collection of special processes that still run directly on Windows.)

8
  • 15
    "Systemd is actually a fairly recent project" – I am always surprised when people ask "How does X work without Y" when Y is fairly new and clearly X has worked for decades without Y before that. The most extreme example is people who seem to think that navigating on Mars will be impossible because Mars has no GPS when people have been navigating for literally hundreds of thousands of years before GPS was invented. May 5 at 5:38
  • 5
    @JörgWMittag: I think that's completely normal for people who grew up with the new system already in place. Asking is how they find out that Y is new and "clearly" X worked before it, and is a completely different thing than just concluding that it would be impossible.
    – user1686
    May 5 at 6:00
  • 6
    @Celesteaka.73chn0 It's a shame that those in your generation will grow up implicitly learning that systemd is "the" or even "a good" way to do things, because there are those of us (controversy alert!) who believe that it is precisely the opposite of everything that Unix has ever stood for. But the flame wars over it have largely died down, and if I had any tact or decorum I wouldn't be posting this potentially inflammatory comment at all. May 5 at 20:10
  • 1
    I would like to unsubscribe from this conversation.
    – user1686
    May 6 at 4:39
  • 2
    @SteveSummit some would say it's a shame the older generation rejects it because it's clearly superior. Science advances not so much by new discoveries being made, as by the devout followers of old paradigms dying.
    – user253751
    May 6 at 17:19
14

WSL 2 has a custom init system that is not open source (at least I haven’t found the source). You can see its processes with tools like ps or htop.

It is a multi-call binary that does at least the following:

  • Run 9p server for file access
  • Launch shell inside a WSL 2 distribution container
  • Manage WSL 2 distribution containers
  • Run other interop stuff

You cannot see all of these processes/daemons because some run outside all WSL 2 containers (in the root namespace).

Whatever init system may or may not exist in the distribution is not used. Instead, shells are spawned directly using the configured user ID.

2
  • 1
    Great description! Is there a way how to access the root namespaces of WSL2 while using the Microsoft's init? May 5 at 7:50
  • 3
    @pabouk-Ukrainestaystrong No, sorry. I’m not aware of any “exploit” to access the root namespace. I’m sure it’s possible though, for example by reverse engineering how the host’s wsl command communicates with the VM (probably over Hyper-V Sockets).
    – Daniel B
    May 5 at 12:01
4

Systemd is not an inherent part of Linux; many Linux distributions do not use it. WSL will be running whatever your installed Linux distribution uses.

1
  • 10
    Actually it won’t. It will run WSL 2’s special init and then just spawn a shell.
    – Daniel B
    May 4 at 17:42

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.