systemd is really well designed

One of the things I think has generally worked well about “Linux” and the ecosystem on top of it has been the variety of userspace.  There’s obviously some pointless things, but also some genuine innovation.  It works well when upstream projects are structured in a way that they can be mixed and matched.

For Fedora CoreOS we are combining two technologies; Ignition and rpm-ostree.  Previously they were used independently (Ignition with a ChomeOS style A/B updater) and rpm-ostree with the traditional Fedora-and-derivatives setup of Kickstart for bare metal, and cloud-init for clouds.

Putting the two together has been working well so far, but I’ve recently been working on support for root filesystem reprovisioning which is where the two projects intersect strongly.  This has meant a lot of time writing code in the initramfs.

And the topic of this blog is “systemd is well designed” because the design for systemd in the initramfs is very flexible and also well documented.  We’re continuing to support Ignition independent of OSTree, as well as OSTree independent of Ignition, while also having both of them work together.  Further, the projects are written in different languages; Ignition is Go, OSTree is C, we have the usual (unfortunate) mix of shell script in there, and it’s likely we’ll add some Rust soon too.

This is where systemd excels; we can plug these things together in a coordinated fashion by writing unit files with careful dependencies.  They can communicate however they want; in practice, writing files in /run is a common pattern.

Also worth noting is we’re using dracut, which is itself independent of systemd, designed to just implement the systemd boot sequence – our units plug into the “custom initrd services” section.  And it all Just Worked.  The systemd initramfs boot sequence (and the boot sequence in general) was designed long before either OSTree or Ignition were created, but it’s stood the test of time.


  1. It’s nice seeing systemd appreciation. The UNIX “philosophers” out there are really tiring when they preach that PID 1 must do only one thing well, neither two things, nor zero things, no, one thing. The damn shell dwellers, enemies of innovation and always acting like they only have 320 KB of RAM!

  2. I love systemd and feel it was one of the best innovations for Linux in a long time. I honestly can’t believe there are people that prefer the old days when there was no actual service manager. At work we’re slowly becoming more container focused and one of the things I always miss when constructing container services is the lack of systemd. I know if I’m constructing a proper microservice there should be no need for initialization ordering or service management, but it still feels like a loss.

    Anyways, sounds like a fun project!

  3. It would help if the article would actually give some definite explanations WHY the author here believes that system is “well” designed. I understand that the author of course writes from a pro IBM Red Hat point of view since that is what he is paid to do – but I can not find within this article a single convincing argument as to how, where or why systemd would be well-designed.

    It is massively over-engineered and complicated to use. That’s admittedly one strong selling point for support, but for casual linux users who want to change their system? That’s a dead end at once.

    > initramfs is very flexible and also well documented.

    Now I don’t agree with this, but here is one thing that fascinates me – IF you write that it is the most awesome documentation ever, why are you too shy to link in to the documentation? I mean, hyperlinks are not impossible in 2019 right? 🙂

    • is already linked in the article – I think the problem is my blog’s theme doesn’t make hyperlinks obvious.

      I could certainly imagine if the initramfs was just a big shell script it’d be simpler for the simple cases – but the `if nfs {}` and `if ostree {}` and `if ignition {}` etc. type conditionals would grow unmaintainable fast. The point of the blog is that I found the systemd design to work really well for what I was trying to do.

  4. Thanks! How much work needs to be done to add ignition support for debian, ubuntu and other systems?
    I think that ignition can’t fully replace cloud-init, cloud-init works for netbsd, freebsd and windows. Also linux kernel developers do much stuff to add ability to resize rootfs online, grow partitions and other.

  5. You work for IBM/Red Hat, so, of course, you promote systemd.

    Systemd is not “innovative” as suggested by the above Koolaid drinker, and it sucks.

    It wouldn’t be so bad if there weren’t so many arbitrary dependencies to systemd. The only reasons for such unnecessary lock-ins is greed and politics. It’s more difficult for Red Hat (and IBM) if they actually have to compete on merit without the aid of artificial lock-ins.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s