I suspect this was a remarkably complicated project; WSL2 has its own concept of OS lifetime and startup and making it work with systemd sounds tricky. Should be nice for compatibility though; a surprising number of Ubuntu packages rely on some boot-time initialization that systemd is supposed to do.
Yes it would be interesting to see how much if any of this work is open source. I’ll bet there’s some interesting engineering going on under the covers to make this happen.
In Genode the init component basically enforces security policies, so you can create a tree of subinits that are successively more locked down, and there isn’t any escape hatch to escalate privilege. File-system and networking is in userspace, so managed by init, and you can arbitrarily namespace networking and file-systems by isolating instances in different inits.
This means the same process manager can be used on a per-project level. You could write your systemd units for development, which would be pretty close to those for the system.
The UBI init images, named ubi-init, contain the systemd initialization system, making them useful for building images in which you want to run systemd services, such as a web server or file server. […]
Because the ubi8-init image builds on top of the ubi8 image, their contents are mostly the same. However, there are a few critical differences:
ubi8-init:
CMD is set to /sbin/init to start the systemd Init service by default
includes ps and process related commands (procps-ng package)
sets SIGRTMIN+3 as the StopSignal, as systemd in ubi8-init ignores normal signals to exit (SIGTERM and SIGKILL), but will terminate if it receives SIGRTMIN+3
This is great! One issue that recently came up for me is that the Ubuntu 20.04 LTS docker.io package omits the /etc/init.d/docker script from upstream, so there was no (easy) way to start the docker daemon in WSL. Honestly, a super odd packaging decision given how much Ubuntu seems to be the first-est class citizen of WSL.
From my experience, WSL would really rather you run Docker Desktop (which runs the docker-machine in hyper-v) and let it push the docker cli into the WSL guest.
I suspect this was a remarkably complicated project; WSL2 has its own concept of OS lifetime and startup and making it work with systemd sounds tricky. Should be nice for compatibility though; a surprising number of Ubuntu packages rely on some boot-time initialization that systemd is supposed to do.
Yes it would be interesting to see how much if any of this work is open source. I’ll bet there’s some interesting engineering going on under the covers to make this happen.
I really wish systemd didn’t insist on being PID 1. Then it would be the perfect answer to “how do I run multiple processes in a single container?”
Yes, you don’t know what you are missing until you’ve used an init system that supports arbitrary recursion, like the Genode init.
If you’d like, could you say a little more about what value you’ve found in that sort of thing?
In Genode the init component basically enforces security policies, so you can create a tree of subinits that are successively more locked down, and there isn’t any escape hatch to escalate privilege. File-system and networking is in userspace, so managed by init, and you can arbitrarily namespace networking and file-systems by isolating instances in different inits.
This means the same process manager can be used on a per-project level. You could write your systemd units for development, which would be pretty close to those for the system.
What semantics of systemd do you think are better suited inside containers than other (perhaps less opinionated) supervisor inits?
Familiarity, and the ability to write daemons for both in-container and out-of-container use.
And being able to use existing software which expects to be launched by systemd!
It’s also worth noting that podman just has a ‘–systemd=true|false|always’ flag that allows this behaviour.
From the RHEL containers manual (emphasis mine):
ubi8/ubi-init in the Red Hat Container Catalog. Red Hat’s UBI images are free for everyone. I am not affiliated with Red Hat.
…I am affiliated with Red Hat and didn’t know this.
Whoops. Thank you!
This is great! One issue that recently came up for me is that the Ubuntu 20.04 LTS docker.io package omits the /etc/init.d/docker script from upstream, so there was no (easy) way to start the docker daemon in WSL. Honestly, a super odd packaging decision given how much Ubuntu seems to be the first-est class citizen of WSL.
From my experience, WSL would really rather you run Docker Desktop (which runs the docker-machine in hyper-v) and let it push the docker cli into the WSL guest.
Docker desktop now uses wsl2 for it’s host. So far i haven’t had any problem with it