Hacker News Reader

Comment by adtac | Hacker News Reader

>Note that Alpine Linux doesn’t use systemd, it uses OpenRC. This didn’t factor into my decision at all. systemd has worked well for me on my Arch Linux systems. [...]

How does systemd, or any init for that matter, come into the picture if you're running everything inside docker? Containers don't use any init, right? They just execute the binary in the host environment (but containerised). Or am I missing something?

Edit: nevermind, OP is using Alpine as the host OS as well.

View on HN

Correct. Docker containers typically only contain one process, and that process runs as PID 1. If you need an init system, tini is very popular, and is now built in to docker itself[1]. Systemd is way heavy and overkill inside docker.

[1] https://github.com/krallin/tini

They don't always have one process though. And this is actually a significant good case for OpenRC, as it is far more lightweight than systemd. I haven't used tini.

s6-overlay [1] is also a popular choice for Alpine-based containers.

[1] https://github.com/just-containers/s6-overlay

Specifically why is it way heavy though? What does systemd provide which isn't needed?

Primarily, you would run an init system in a docker container in order to correctly proxy signals to the one process in question, which would otherwise run as PID 1 - for example, sending SIGTERM to docker run running a PID 1 with no registered handler will result in nothing, because Linux won't use the default handler (killing it).

Secondarily, if you want to be neat and save some pids and kernel memory, you need an init system to wait(3) on orphaned zombie processes.

These are the only two use cases AFAIK, which a small init system such as tini satisfies, without the complexity and size of systemd.

That doesn't answer the question: what does systemd provide which isn't needed?

I have multiple network devices. I want some to be controlled by processes running in a container; effectively I want some processes to run under a user account but still provide root (root-like?) access to the specified network device(s). I want to be able to give a specific (containerized) user full control over one or more specific network devices. My (naive?) understanding is that the init daemon takes care of bringing the network online and then subsequent management of it. For systemd, that would be Network Manager? Or do I misunderstand?

In my experience I had to update a bunch of scripts and configs which used systemd commands as well as using GNU versions of other commands (with some basic programs like `find` or `grep` this turned out to break a lot of stuff). That was my only big annoyance.

Plus the package manager and system structure was a bit of a learning curve.

But otherwise I was very happy with it. The lack of portability with my Linux ArchLinux/Debian desktop/servers can be overcome with time and experience like anything.

I used some basic Docker images as well but they always needed some config work, as they mostly installed the base software but didn’t get your apps running. Other people may be using more sophisticated images though.

> Containers don't use any init, right? They just execute the binary in the host environment (but containerised).

It depends on the container runtime. LXC/LXD run an actual init system and can be treated like lightweight VMs running multiple processes.

You can run systemd inside a systemd-nspawn container. I've found this quite useful for debugging/testing custom Raspberry Pi disk images. You can simply import the rootfs into the container and have something that behaves almost like the real system, including startup, but right there on your development machine. I don't think you can do anything like that in Docker. But I do appreciate most people probably don't want/need that systemd support.

The host environment you're running Docker in still needs a services to be executed at boot.

I just ran `docker run -it alpine /bin/sh` and when inside, I ran top. It looks like `/bin/sh` ran as PID 1. No init, just sh (busybox in this case).

Edit: Ah you meant the host OS. I can't reply to wezm down below for whatever reason (there's no "reply" button), so I'll just edit this to say I didn't realise that he was using alpine as your host OS as well. I haven't seen many people running it outside Docker, so it's quite interesting.

He means the host OS.

Host operating systems need a init, of course. I was just startled by the irrelevant discussion on alpine's init system when it isn't involved anywhere.

Yeah my host is running Alpine as well the containers so it's init needs to start docker, cron, etc.

There's no init and only one process by default in alpine's docker image but you can add them and run more processes if you want.

To the best of my knowledge, they share a kernel, not an init.

Reply on news.ycombinator.com