Difference between revisions of "Systemd"

From Mark Weiman's Wiki
Jump to navigation Jump to search
(Created page with "= 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...")
 
 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
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 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 program doing multiple things on a system. I have a couple of reasons why I disagree.
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.
* Unix is a dead project. Although many of its principles are still valid, there's a case for not copying it exactly.
Line 46: Line 46:


= nspawn/machinectl =
= nspawn/machinectl =
= udev =

Latest revision as of 05:08, 10 February 2021

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