Systemd

From Mark Weiman's Wiki
Jump to navigation Jump to search

Introduction

I am going to begin this page by stating that I actually like systemd. It greatly simplifies system setup and configuration to a point where I do not have to write out some esoteric init.d or rc.d script, set up logging, or install several applications to do tasks that I would do on almost any system.

I think the main reason people object to systemd so religiously is it's not "unix" enough. This is usually due to the fact that people say it's too "monolithic" and that we shouldn't have one project doing multiple things on a system. I have a couple of reasons why I disagree.

  • Unix is a dead project. Although many of its principles are still valid, there's a case for not copying it exactly.
  • systemd is separated into several programs, we don't just run the same command for everything.

A more accurate view of what systemd does is that it adds a new layer to the computer's stack. It adds a system layer to the operating system to do very common tasks. It would look like the following.

  1. Hardware
  2. EFI/BIOS
  3. Kernel
  4. System (where systemd lies)
  5. Applications

What do I mean by applications that do tasks that someone might do on almost every system?

  • Have an init system (SysV, upstart, OpenRC, etc)
  • Have a logging system (rsyslogd, etc)
  • Set up a time synchronization (NTP)
  • Set up networks (Network Manager, netctl, etc)
  • Set up timers (cron)
  • Set up DNS resolving
  • Mount disks (fstab)
  • Setup and organize devices

Having one system with a standard format for configuration is definitely appealing and I'd argue preferable. This page contains some thoughts, workarounds for bugs (all software has bugs remember), and general notes.

Services

networkd

See Systemd/Networkd.

resolved

Timers

Time Synchronization

Mounts

journald

nspawn/machinectl

udev