TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems. journalctl go brrrr
Strap in, folks. Old timer with a gavel to slam.
When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:
Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.
systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.
It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools. systemctl is used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.
Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify -k for dmesg, a service using --unit, point to a binary in /usr/bin, select previous boot with -b -1, -f for follow, -e take me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.
systemd-boot is blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefer systemd-boot because of bootctl, because like journalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.
Now we we’re seeing systemd managing VM’s (machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.
You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.
To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.
Having to occasionally go back to OpenRC or Upstart systems is jarring. Systemd just does so much and does it so much better. Poettering seems like a bit of a chode but he genuinely made an incredible project. I also think that when people say systemd isn’t Unix-like, they forget that systemd isn’t monolithic and it’s possible to use some components of it but not others. The core is all based on a standardized way to start and manage processes and services, be it for boot or usage.
@taanegl@DmMacniel omg i was so prepared to hear a anti-lennart-pottering rant about sysv init scripts
thanks for what instead turned out to be a very thoughtful and educational text which i will now send to all these sysv ppl
DNS resolution, clock synchronization, there’s something about keyboard configuration but it stopped to make me problems for no reason so I don’t know what exactly…
Oh, and IPC so that Gnome can not be done until other inits won’t run!
What else besides running services can system.d do?
TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems.
journalctlgo brrrrStrap in, folks. Old timer with a gavel to slam.
When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:
Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.
systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.
It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools.
systemctlis used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us
journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify-kfor dmesg, a service using--unit, point to a binary in/usr/bin, select previous boot with-b -1,-ffor follow,-etake me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.systemd-bootis blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefersystemd-bootbecause ofbootctl, because likejournalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.Now we we’re seeing systemd managing VM’s (
machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.
To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.
Having to occasionally go back to OpenRC or Upstart systems is jarring. Systemd just does so much and does it so much better. Poettering seems like a bit of a chode but he genuinely made an incredible project. I also think that when people say systemd isn’t Unix-like, they forget that systemd isn’t monolithic and it’s possible to use some components of it but not others. The core is all based on a standardized way to start and manage processes and services, be it for boot or usage.
@taanegl @DmMacniel omg i was so prepared to hear a anti-lennart-pottering rant about sysv init scripts
thanks for what instead turned out to be a very thoughtful and educational text which i will now send to all these sysv ppl
Damn. Thanks for the writeup.
Old timer built Linux… Old timers built open source. Don’t disrespect.
…yes, I know. I’m one of them. Used to compile my OS and everything.
Systemd is still better than init/daemons, categorically.
bootload, manage devices, manage the network interface, manage accounts, log in, provide a host for temp files, schedule stuff, log events
All of this is background stuff to me so I don’t care
(n.b.: systemd also suffers from a linux kernel vs linux situation. systemd has a component named systemd that only does services stuff)
You forgot manage containers, manage system timers, manage network interfaces (in some cases)…
DNS resolution, clock synchronization, there’s something about keyboard configuration but it stopped to make me problems for no reason so I don’t know what exactly…
Oh, and IPC so that Gnome can not be done until other inits won’t run!
But there are a lot of other modules.
I said “manage the network interface” and “schedule stuff”
That requires podman or some other program, so that’s like saying shell does container management
No,
systemd-nspawndoesn’t need any other container management program, it’s its own thing.You’re right about the first two, but as someone pointed out already, wrong about the last.
Also see
machinectlI believe you mean GNU/SystemD/Linux…
I can’t believe how much time has passed since the controversy. If I remember correctly the problem is that systemd eats babies
Many, many things.
The best feature I like is that it can keep track of dependencies and status. It is a “smart” control system for your computer