Systemd 使用介绍
2016-06-27 14:17:12 
阿炯
Systemd 是一种新型init系统，我们知道，每个操作系统都有一个启动程序，而Linux init是其操作中不可缺少的程序之一。所谓的init进程，它是一个由内核启动的用户级进程。内核自行启动(已经被载入内存，开始运行，并已初始化所有的设备驱动程序和数据结构等)之后，就通过启动一个用户级程序init的方式，完成引导进程。所以init始终是第一个进程(其进程编号始终为1)，最早使用 systemd 的是gentoo，最早使用并成为默认 init system 的是openSUSE，经过调整适应了其它许多发行版，例如Debian、RedHat、Suse和CentOS。systemd 是 相当一部分 Linux 系统的一组基本构件，它提供了一个以 PID 1 身份运行的系统和服务管理器，并引导启动了系统的其他部分。
systemd是Linux下的一种init软件，由Lennart Poettering带头开发，并在LGPL 2.1及其后续版本许可证下开源发布。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。它确实能加快系统的启动过程，但同时也引入了复杂性、不开放性和引起了开源社区的巨大分裂。它直接导致了Debian Fork出来了无systemd的Debian分支Devuan，Gentoo发起了OpenRC、eudev项目等。
官方介绍
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.
systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
systemd是linux的系统和服务管理器。systemd和SysV、LSB init scripts兼容，它可以作为sysvinit的一个替代品：
提供了更积极的并行能力
使用socket和D-Bus activation来启动服务
能够按需启动守护进程
采用基于依赖关系的服务控制逻辑来完成各项事务
采用linux cgroups来跟踪进程
支持快照和恢复
管理存储挂载
与多数发行版使用的System V风格init相比，systemd采用了以下新技术：
采用Socket激活式与总线激活式服务，以提高相互依赖的各服务的并行运行性能；
用cgroups代替PID来追踪进程，以此即使是两次fork之后生成的守护进程也不会脱离systemd的控制。
从设计构思上说，由于systemd使用了cgroup与fanotify等组件以实现其特性，所以只适用于Linux。
大部分人用过传统的SysV init 初始化脚本，它通常情况下在/etc/rc.d/init.d/文件夹下。这些脚本调用守护进程二进制代码，在后台fork一个进程。尽管shell脚本非常的灵活，但是很难实现像superviseing(监管)进程和并行执行命令这样的任务。通过对systemd的新式守护进程的介绍，我们发现systemd可以在runtime(运行时)更加简单的监管和控制守护进程，并且简化了监控的实现方式(implementation)。在 systemd 之前，init 程序的实现就有 SysV Init，Ubuntu 的 upstart，Gentoo 的 OpenRC 等等。
systemd最大特点有两个：令人惊奇的激进的并发启动能力，极大地提高了系统启动速度；另外就是用 CGroup 统计跟踪子进程，干净可靠。
反对systemd的意见主要是：
不遵循 UNIX 原则。
systemd 在设计之初就不考虑 Linux 以外的平台，不遵循 POSIX 标准，而且很多功能根本就是 Linux 特有的，无法移植到 Linux 之外的平台，这尤其让 BSD 爱好者们很受伤，在 Debian 7 以前，一直维护着Linux和FreeBSD两个内核，只不过后者没什么人用，Debian 8 为了支持systemd 不得不放弃支持 Debian kFreeBSD。
接管了太多服务，如 syslog 被 systemd-journal 取代，crond 也被 systemd 的 timer 单元取代，udev 也准备集成到 systemd 中来，未来甚至还可能取代 /etc/fstab。尽管这些新的服务大部分都是独立于主进程的，但是还是有整个系统被红帽控制住的感觉(systemd的作者Lennart Poettering 就职于红帽，systemd 也主要是红帽的 Fedora 首先在推，OpenSUSE 后面跟随)。这在开源社区看来是件不正确的事情。
systemd引入了一个新术语：cgroups(控制组)，它基本上是可被分层次安排的进程任务组。
这里简单介绍一下cgroup(control group)称为Containers，Containers着眼于资源的分配，利用configfs作配置。它有两个重要概念：
第一是 subsystem，内核可以给进程提供的服务/资源；
第二是container，一个进程组，成员共享同样的一个或多个子系统分配限制。Containers是分层次的，一个container可以hold多个container。它的可取之处是创建了一个资源分配的框架，其它开发者可以利用这个框架去开发自己的资源分配patch，比如磁盘设备。
如果仅仅通过原来的初始化系统，决定哪个进程是做什么的、属于哪个用户的变得越来越困难。但是通过systemd，当一个进程派生其它进程时，这些子进程会被自动变成父进程控制组的成员，这样一来就可以避免继承的混乱。
单元的概念
系统初始化需要做的事情非常多。需要启动后台服务，比如启动 SSHD 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；等等。systemd 将配置单元归纳为以下一些不同的类型。然而systemd 正在快速发展，新功能不断增加。所以配置单元类型可能在不久的将来继续增加。
service ：代表一个后台服务进程，比如 mysqld。这是最常用的一类。
socket ：此类配置单元封装系统和互联网中的一个 套接字 。当下，systemd 支持流式、数据报和连续包的 AF_INET、AF_INET6、AF_UNIX socket 。每一个套接字配置单元都有一个相应的服务配置单元 。相应的服务在第一个"连接"进入套接字时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。
device ：此类配置单元封装一个存在于 Linux 设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。
mount ：此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。比如可以在启动时自动将其挂载；可以在某些条件下自动卸载。Systemd 会将/etc/fstab 中的条目都转换为挂载点，并在开机时处理。
automount ：此类配置单元封装系统结构层次中的一个自挂载点。每一个自挂载配置单元对应一个挂载配置单元 ，当该自动挂载点被访问时，systemd 执行挂载点中定义的挂载行为。
swap： 和挂载配置单元类似，交换配置单元用来管理交换分区。用户可以用交换配置单元来定义系统中的交换分区，可以让这些交换分区在启动时被激活。
target ：此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么，只是引用其他配置单元而已。这样便可以对配置单元做一个统一的控制。这样就可以实 现大家都已经非常熟悉的运行级别概念。比如想让系统进入图形化模式，需要运行许多服务和配置命令，这些操作都由一个个的配置单元表示，将所有这些配置单元 组合为一个目标(target)，就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。 (例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)
timer：定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。
snapshot ：与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。
每个配置单元都有一个对应的配置文件，系统管理员的任务就是编写和维护这些不同的配置文件
对老的sysvinit的影响
systemd 已经创建了比任何软件都多的技术问题、感情问题和社会问题。这一点从“Linux 初始化软件之战”上就能看出，这场争论在 Debian 开发者之间持续了好几个月。当 Debian 技术委员会最终决定将 systemd 放到 Debian 8 Jessie的发行版里面时，其反对者试图通过多种努力来取代这项决议。
这也说明了 systemd 对 Unix 传承下来的系统处理方式有很大的干扰。“一个软件只做一件事情”的哲学思想已经被这个新来者彻底颠覆。除了取代了 sysvinit 成为新的系统初始化工具外，systemd 还是一个系统管理工具。目前为止，由于 systemd-sysv 这个软件包提供的兼容性，那些我们使用惯了的工具还能继续工作。但是当 Debian 将 systemd 升级到214版本后，这种兼容性就不复存在了。升级措施预计会在 Debian 8 "Jessie" 的稳定分支上进行。从此以后用户必须使用新的命令来管理系统、执行任务、变换运行级别、查询系统日志等等。
systemd 不仅提供了比 sysvinit 更快的启动速度，还让日志系统在更早的时候启动起来，可以记录内核初始化阶段、内存初始化阶段、前期启动步骤以及主要的系统执行过程的日志。所以以前那种需要通过对显示屏拍照或者暂停系统来调试程序的日子已经一去不复返啦。
systemd 的日志文件都被放在 /var/log 目录。如果你想使用它的日志功能，需要执行一些命令。
Systemd 的并发启动
在 Systemd 中，所有的服务都并发启动，比如 Avahi、D-Bus、livirtd、X11、HAL 可以同时启动。Systemd 的开发人员仔细研究了服务之间相互依赖的本质问题，发现所谓依赖可以分为三个具体的类型(socket 依赖、D-Bus 依赖、文件系统依赖)，而每一个类型实际上都可以通过相应的技术解除依赖关系。
我还想找到无(No Systemd)systemd的发行版本
这个可以在Without Systemd Wiki页面中找到，还是有相当多的Linux发行版本，像笔者就从Debian迁移到了Crux这个小巧的发行版本了。
参考来源：
Systemd 专题
systemd 与 sysVinit 彩版对照表
Systemd On Wikipedia
Without Systemd
Linux系统启动速度优化工具systemd-analyze，它是Linux自带的分析系统启动性能的工具。
systemd-analyze可使用的命令：
systemd-analyze [OPTIONS…] [time]
systemd-analyze [OPTIONS…] blame
systemd-analyze [OPTIONS…] critical-chain [UNIT…]
systemd-analyze [OPTIONS…] plot [> file.svg]
systemd-analyze [OPTIONS…] dot [PATTERN…] [> file.dot]
systemd-analyze [OPTIONS…] dump
systemd-analyze [OPTIONS…] set-log-level LEVEL
systemd-analyze [OPTIONS…] set-log-target TARGET
systemd-analyze [OPTIONS…] get-log-level
systemd-analyze [OPTIONS…] get-log-target
systemd-analyze [OPTIONS…] syscall-filter [SET…]
systemd-analyze [OPTIONS…] verify [FILES…]
systemd-analyze命令具体含义：
systemd-analyze 可以显示系统启动过程中的性能统计数据、 获取 systemd 系统管理器的状态与跟踪信息、 校验单元文件的正确性。
systemd-analyze time 可以显示如下时间：
(1)在启动第一个用户态进程(init)之前，内核运行了多长时间；
(2)在切换进入实际的根文件系统之前，initrd(initial RAM disk)运行了多长时间；
(3)进入实际的根文件系统之后，用户空间启动完成花了多长时间。
注意，上述时间只是简单的计算了系统启动过程中到达不同标记点的时间，并没有计入各单元实际启动完成所花费的时间以及磁盘空闲的时间。
systemd-analyze blame 按照每个单元花费的启动时间从多到少的顺序，列出所有当前正处于活动(active)状态的单元。这些信息有助于用户优化系统启动速度。不过需要注意的是，这些信息也可能具有误导性，因为花费较长时间启动的单元，有可能只是在等待另一个依赖单元完成启动。
systemd-analyze critical-chain [UNIT…] 为指定的单元(省略参数表示默认启动目标单元)以树状形式显示时间关键链(time-critical chain)。“@”后面的时刻表示该单元的启动时刻；“+”后面的时长表示该单元总计花了多长时间才完成启动。不过需要注意的是，这些信息也可能具有误导性，因为花费较长时间启动的单元，有可能只是在等待另一个依赖单元完成启动。
systemd-analyze plot 输出一个 SVG 图像，详细显示每个单元的启动时刻， 并高亮显示每个单元总计花了多长时间才完成启动。
systemd-analyze dot 按照 GraphViz dot(1) 格式输出单元间的依赖关系图。在实践中，通常使用 systemd-analyze dot | dot -Tsvg > systemd.svg 命令来最终生成描述单元间依赖关系的 SVG 图像。除非使用了 –order 或 –require 选项限定仅显示特定类型的依赖关系，否则将会显示所有的依赖关系。如果指定了至少一个 PATTERN 参数(例如 *.target 这样的 shell 匹配模式)，那么将会仅显示所有匹配这些模式的单元的直接依赖关系。
systemd-analyze dump 按照人类易读的格式输出全部单元的状态(一般都有几千数万行)。 因为它的输出格式经常在未通知的情况下发生变化， 所以切勿将此输出用于程序分析。
systemd-analyze set-log-level LEVEL 将 systemd 守护进程的日志等级更改为 LEVEL (可使用的值参见 systemd(1) 的 –log-level= 选项)
systemd-analyze set-log-target TARGET 将 systemd 守护进程的日志目标更改为 TARGET (可使用的值参见 systemd(1) 的 –log-target= 选项)
systemd-analyze get-log-level 打印出 systemd 守护进程当前的日志等级。
systemd-analyze get-log-target 打印出 systemd 守护进程当前的日志目标。
systemd-analyze syscall-filter [SET…] 如果指定了至少一个 SET 参数，那么仅显示指定的集合所包含的系统调用列表；否则显示全部系统调用集合的详情。注意，必须在 SET 参数中包含 “@” 前缀。
systemd-analyze verify 校验指定的单元文件以及被指定的单元文件引用的其他单元文件的正确性，并显示发现的错误。FILES参数可以是单元文件的精确路径(带有上级目录)，也可以仅仅是单元文件的名称(没有目录前缀)。对于那些仅给出了文件名(没有目录前缀)的单元，将会优先在其他已经给出精确路径的单元文件的所在目录中搜索，如果没有找到，将会继续在常规的单元目录中搜索(详见unit(5)手册)。可以使用$SYSTEMD_UNIT_PATH 环境变量来更改默认的单元搜索目录。
如果没指定任何命令，那么等价于使用 systemd-analyze time 命令。
systemd-analyze 实战
Startup finished in 3.220s (kernel) + 23.420s (userspace) = 26.641s
graphical.target reached after 23.111s in userspace
可以看到开机用了23秒以上，接下来查询下这锅应该谁背：
systemd-analyze blame
21.594s NetworkManager-wait-online.service
680ms systemd-logind.service
587ms lvm2-monitor.service
570ms lightdm.service
534ms dev-sdc2.device
371ms upower.service
309ms tlp.service
292ms systemd-timesyncd.service
260ms systemd-udevd.service
252ms ModemManager.service
217ms systemd-journald.service
131ms systemd-journal-flush.service
121ms boot-efi.mount
117ms avahi-daemon.service
115ms bluetooth.service
111ms polkit.service
111ms NetworkManager.service
110ms udisks2.service
102ms systemd-modules-load.service
可以看到NetworkManager-wait-online.service耗时最长，花了21秒。这里的记时有可能是等待其他服务器启动的，再来看看其关联服务的启动时间：
systemd-analyze critical-chain NetworkManager-wait-online.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
NetworkManager-wait-online.service +21.594s
└─NetworkManager.service @1.398s +111ms
└─dbus.service @1.390s
└─basic.target @1.389s
└─sockets.target @1.389s
└─dbus.socket @1.389s
└─sysinit.target @1.384s
└─systemd-backlight@backlight:intel_backlight.service @1.313s +71ms
└─system-systemd\x2dbacklight.slice @1.312s
└─system.slice @207ms
└─-.slice @207ms
可这一看到这里它在等待其他的服务，但是也没有花21秒怎么多。
发现了影响启动的服务，最简单的方式是禁用此服务：
sudo systemctl disable NetworkManager-wait-online.service
方案二：编辑/lib/systemd/system/NetworkManager-wait-online.service文件，将文件中的
[Service] Type=oneshot ExecStart=/usr/bin/nm-online -s -q --timeout=30
超时时间由30改为10。
另外来看下还有哪些开机启动的服务可被优化：
systemctl list-unit-files --type=service | grep enabled
autovt@.service enabled
avahi-daemon.service enabled
bluetooth.service enabled
bumblebeed.service enabled
cronie.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.ModemManager1.service enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timesync1.service enabled
display-manager.service enabled
getty@.service enabled
lightdm.service enabled
ModemManager.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager.service enabled
org.cups.cupsd.service enabled
systemd-fsck-root.service enabled-runtime
systemd-remount-fs.service enabled-runtime
systemd-timesyncd.service enabled
tlp-sleep.service enabled
tlp.service enabled
ufw.service enabled
相关服务对应的功能：
NetworkManager-wait-online.service：网络服务管理器，禁用后不影响正常的网络使用
autovt@.service：登陆相关 保留
avahi-daemon.service：让程序自动发现本地网络服务。除非你有兼容的设备或使用 zeroconf 协议的服务，否则应该关闭它。
service：蓝牙服务，如果使用也可以禁用
service：显卡驱动，保留
service：预定日程和时间触发事件的守护进程。保留
dbus-org.bluez.service：蓝牙守护进程，可禁止
dbus-org.freedesktop.Avahi.service：让程序自动发现本地网络服务。除非你有兼容的设备或使用 zeroconf 协议的服务，否则应该关闭它。
dbus-org.freedesktop.ModemManager1.service：用于提供移动宽频broadband(2G/3G/4G)接口。可禁用
dbus-org.freedesktop.NetworkManager.service：桌面网卡管理可禁用
dbus-org.freedesktop.nm-dispatcher.service：网卡守护进程，可禁用
dbus-org.freedesktop.timesync1.service：时间同步，可禁用
display-manager.service： 用来管理显示的生命周期，它决定如何根据当前连接的物理显示设备控制其逻辑显示，保留
getty@.service enabled：tty控制台相关，保留
service enabled：图形化界面显示，保留
service： 被 dbus 激活的守护进程，用于提供移动宽频broadband(2G/3G/4G)接口。可禁用
NetworkManager-dispatcher.service：网卡守护进程，可禁用
service：检测网络、自动连接网络的程序。建议保留
cups.cupsd.service：通用UNIX打印系统守护进程.，可禁用
systemd-fsck-root.service：负责对根文件系统进行检查，建议保留
systemd-remount-fs.service：在系统启动早期启动的服务，它会根据 fstab(5) 中设置的挂载选项，重新挂载根目录与 /usr 目录， 以及虚拟文件系统。这是一个必需的动作， 因为这些文件系统在能够读取 /etc/fstab 文件之前，就已经被预先挂载了， 例如在初始内存盘(initial RAM disk)中挂载、或在进入容器环境前挂载。保留
systemd-timesyncd.service：跨网络同步系统时钟的守护服务，可禁用
tlp-sleep.service：电池优化，电源管理，建议保留
service：电池优化，电源管理，建议保留
service： 防火墙服务，建议保留
systemd 246 稳定版发布
2020年08月04日，systemd 246 稳定版已发布，此版本提供了大量新功能，其中许多功能与对磁盘卷的加密和签名支持有关，今年秋季发布更新的 Linux 发行版有机会用上。该版本的主要更新有：
systemd -journald 支持使用 Zstd 压缩日志文件。同样，systemd-coredump 收集的 coredumps 也可以使用 Zstd 算法进行压缩
systemd 自动创建的 Tmpfs 挂载，如 /tmp 和 /run，现在对 /tmp 和 /dev/sdm 的内存限制为 50%，而对其他挂载的内存限制为 10%
systemd-homed 的 LUKS 后台可以在用户注销时自动丢弃空的系统块（empty system blocks）
systemd-homed 可更好地保护潜在的双重数据加密场景，它还支持使用 FIOD2 安全令牌解锁主目录
systemd-cryptsetup 现在可以在引导启动过程中激活 Microsoft BitLocker 卷
新增 systemd-xdg-autostart-generator 命令，用于从 XDG autostart .desktop 文件生成 systemd unit 文件
支持在引导启动时使用内核选项命令 systemd.hostname= 设置系统主机名，此外还有其他新的内核命令行选项，比如 systemd.swap= 用于切换是否启用 SWAP，systemd.clock-usec= 用于指定引导时的 Unix 时间
systemd 已开始创建一个新的硬件数据库文件，它正在收集关于 PCI 和 USB 设备正确自动暂停的信息。此数据库最初基于来自 ChromeOS/ChromiumOS 的数据
对 cgroup v2 freezer 的基本支持
PID 1 可以在引导启动早期时自动加载预编译的 AppArmor 策略
systemd 247 稳定版发布
2020年12月1号，systemd 247 已正式发布，systemd 是 Linux 系统的一组基本构件。它提供了一个以 PID 1 身份运行的系统和服务管理器，并引导启动了系统的其他部分。 该版本添加了一项名为 systemd-oomd 的新服务， 用于监控资源的争夺情况，并在当内存/交换空间压力超过定义的限制时，可以终止进程。该功能目前处于实验性阶段，只在开发者模式下启用。 同时随着 Linux 发行版开始改用 Btrfs 作为默认文件系统，v247 中的 systemd-homed 在 LUKS 卷中创建主目录时也默认使用 Btrfs 文件系统。homed.conf 的 DefaultFileSystemType= 选项仍支持更改默认值。还包括以下更新内容：
用于 systemd-homed 的 JSON 用户记录增加了对“恢复密钥”的支持，作为解锁帐户/主目录的辅助口令。
Systemd-cryptsetup 获得了对处理内核命令行上指定的分离的 LUKS headers 的支持。
Bootctl 的 set-default 和 set-oneshot 命令现在可以接受三个特殊的字符串"@default"、"@oneshot"、"@current "来代替引导条目 id。
systemd 的系统服务现在支持"凭证(credentials)"逻辑，作为一种用安全可靠的方式将特权数据传递给服务的手段。预期的用例涉及到密码、加密密钥和其他每项服务的私有数据处理，但也有可能涉及到像用户名和证书这样的低特权数据。systemd-nspawn 是 systemd 凭证的早期使用者之一。
在系统中发现部分库的 runtime 依赖关系时，可以使用 dlopen() 加载，从而最大限度地减少 systemd 可能需要的依赖关系，并构建体积更小的操作系统镜像。
用于检查操作系统磁盘镜像的 systemd-dissect 工具已经被移动至 /usr/bin 中，已升级为具有稳定接口的官方支持工具。
systemd-repart partitioner 现在可以选择以 JSON 形式转储其输出。
设置 SYSTEMD_RDRAND=0 环境变量将禁用 RdRand CPU 指令的使用，即便是在支持的 CPU 上。
systemd 250 稳定版发布
2021年12月下旬，systemd 250 正式版发布，这是一个重大更新版本。它包含了过去半年多积累的许多新功能和改进，在发布多个候选版之后，终于在近日正式发布：
支持加密和经过身份验证的凭据。这可以是存储在 /var/ 或系统上的 TPM2 芯片上的密钥，其中凭据将在服务启动时自动解密。还有一个名为 systemd-creds 的新工具用于处理凭据，可用于 SSL 证书、密码和其他类似数据。
扩展 GPT 可发现分区规范 (GPT Discoverable Partitions Specification)，支持 systemd 支持的大多数架构上的 root 和 /usr/ 分区，以及其他更改。
Systemd-logind 具有新的设置，可用于长按系统上的电源、重启或挂起键。如果想要控制行为，可以将长按（大于 5 秒）这些按钮配置为登录。
RestrictFileSystems= for 的新 per-service 设置用于限制服务可以根据其类型访问的文件系统。
服务还有一个新设置 RestrictNetworkInterfaces= for 用于限制对特定网络接口的服务访问。
默认的最大 inode 数已从 /dev 的 64k 增加到 1M，而 /tmp 从 400k 增加到 1M。
per-user 服务管理器现在支持与 systemd-oomd 通信以获取内存不足的终止信息。
各种 TPM 2.0 可信平台模块的支持改进。
支持使用新的 /etc/integritytab 文件在启动时激活 dm-integrity 卷。
用于信号分析仪和相机的新硬件数据库。摄像头硬件数据库会跟踪摄像头是否指向前/后以及不同类型（例如红外）
在使用 sd-boot 加载程序时添加了一个新单元 systemd-boot-update.service，以确保引导加载程序保持最新，并从 /usr 中的操作系统树信息自动传播。
更轻松地支持在运行 systemd-homed 时在系统之间迁移主目录。Systemd-homed 现在在支持的内核/文件系统上使用 UID 映射安装，其中文件现在由“nobody”内部拥有，然后通过 UID 映射安装接口映射到系统本地使用的 UID。这通过不再需要递归 chown 文件来改进系统之间的主目录迁移。
在 Fedora 最近决定这样做之后，Systemd-homed 现在默认为家庭区域使用 Btrfs Zstd 压缩。
对 LoongArch 架构的初步支持。
Systemd-journald 现在为支持的文件系统上的归档日志文件重新启用写时复制。
在 /etc/machine-info 中引入 KERNEL_INSTALL_MACHINE_ID= 支持。该值将优先于任何 /etc/machine-id 值。
支持从 /loader/credentials/*.cred 加载凭据，用于 SSH 密钥、rootfs 加密密钥、dm-integrity 密钥等凭据。这些用于非内核/initrd 特定的凭据，可加载任何内核映像。
自 Windows Vista 以来使用的 Microsoft Windows 启动数据的适当 BCD（启动配置数据）解析器。
systemd 网络生成器现在支持用于具有 IPv6 链路本地连接的 link6 网络配置。
允许使用新的“-Dlink-boot-shared=false”选项为 bootctl 和 systemd-bless-boot 静态链接构建。添加此支持是由 CentOS/RHEL 9 驱动的，CentOS/RHEL 9 具有除 bootctl/systemd-bless-boot 之外的完整 systemd 堆栈。
systemd 日志的打孔改进。
默认启用 systemd-network-generator
Systemd 和 PulseAudio 作者离开红帽，加入了微软
科技媒体 Phoronix 于2022年7月上旬消息称，Systemd 的首席开发人员 Lennart Poettering 已经离开红帽并加入了微软，以继续他在 systemd 方面的工作。Lennart 在红帽工作了 15 年之久，还领导了 PulseAudio、Avahi 项目的创建。
Lennart 对现代的 Linux 桌面一直起着重要作用。目前还没有关于他工作变动的正式官方公告，但外界已经有很多人在讨论他的去向；还有一些人在社交媒体上公开评论，暗示他加入了 Redmond 公司。针对这些言论，Phoronix 方面在进行了一天的跟踪调查后表示，“事实证明这并不是一个玩笑。这位负责多个知名项目的著名开源开发者加入了微软，并继续专注于 systemd 开发。虽然有些人可能并不总是赞同他的观点或处理一些事情的方法，但他对 Linux / 开源世界的巨大贡献以及他多年来对推进生态系统的奉献是不言而喻的。”
事实上，微软方面一直都在招揽了一些 Linux 开发人员和其他著名的开源开发人员人才。包括雇佣了 Python 之父 Guido van Rossum，还有 GNOME 创建者 Miguel de Icaza 曾在 2016 年微软收购 Xamarin 时受雇，但已于今年早些时候离开微软；Nat Friedman 作为 Xamarin 的一员，在公司被微软收购后担任了 GitHub 的 CEO；Gentoo Linux 创始人 Daniel Robbins 之前也受雇于微软，Steve French 作为 Linux CIFS/SMB2/SMB3 的维护者和 Samba 团队的成员为微软工作。
且微软也曾雇佣了大量的上游 Linux 开发者，如 Matteo Croce、Matthew Wilcox、Tyler Hicks、Shyam Prasad N、Michael Kelley，以及许多其他的 Linux 爱好者 / 开发者所能一眼认出的名字。就在今年早些时候，另一位长期 Linux 内核开发人员 Christian Brauner 也加入了微软。Christian Brauner 曾在 Canonical 从事 Linux 内核、LXC、systemd 等方面的工作，后来转到了微软。随着 Linux 在 Azure 上的普及，Windows Subsystem for Linux (WSL) 的成功进一步得到了验证。微软致力于 Mesa 作为在 Direct3D 12 之上支持各种图形 / 计算 API 的一部分，确保 Linux 内核中良好的 Hyper-V 支持；并维护各种像 CBL-Mariner 和 Azure Cloud Switch 这样的内部 Linux 发行版。因此，该公司也在继续吸引更多的上游 Linux 开发人员，包括开源生态系统的一些知名面孔。目前在Microsoft Careers上显示了 663 个提到 Linux 的工作职位。
systemd 252发布
systemd 252 现已于2022年11月上旬发布。公告写道，systemd 在 2023 年底后将不再支持 cgroups v1，如果用户运行的服务使用了 cgroups v1 特性，请尽早实现对 cgroups v2 的兼容。目前大多数 Linux 发行版已使用 cgroups v2。此外，systemd 还计划在 2023 年下半年移除对 split-usr 和 unmerged-usr 处理的支持，这项提醒对部分 Linux 发行版来说更为紧迫。部分新特性包括：
添加 systemd-measure 辅助工具，用于在启动附带 systemd-stub 的统一内核镜像 (UKI) 时预计算 PCR 测量值，可更好地推动 TPM2 策略。
如果 systemd 检测到操作系统镜像已经过了支持期限，它将设置一个 "support-ended" 标记元。这与 os-release 新增的 "SUPPORT_END=" 字段相呼应，用于指定操作系统支持状态被认定不受支持的日期。
为 ConditionCredential= 和 AssertCredential= 添加新的设置项，用于在没有提供特定凭据的情况下跳过失败的单元。
DefaultDeviceTimeoutSec= 可用于指定设备的默认超时。
允许在竞争 CPU 的不同用户服务之间进行更多资源隔离的更改。
支持 systemd 在 “first boot” 条件下进行完整预设，而不仅仅是启用。
C.UTF-8 现在用作默认语言环境，而没有配置其他任何内容。
新的 watchdog-related D-Bus 属性现在由 systemd 发布。
现在支持以 EFI 混合模式启动具有 32 位 UEFI 固件的 64 位内核的 Systemd 启动支持。
改进了对 Parallels 和 KubeVirt 虚拟化的检测。
OpenSSL 现在是 systemd-resolved 的默认加密后端，但仍支持 GnuTLS。
Systemd-repart 现在支持创建 SquashFS 分区以及 dm-verity 分区。
systemd-oomd 现在会在 cgroup 被 kill 时，会发送 “Killed” D-Bus 信号。
对于 RISC-V 上的 systemd，在启用 “SystemCallFilter” 选项时，现在将 riscv_flush_icache () 系统调用添加到默认允许的系统调用列表中。
现在允许 transient units 插入。
systemd 的 sd-stub 现在将使用 LoadImage/StartImage 来执行内核。sd-stub 现在还添加了一个临时 UEFI SecurityOverride 以允许 boot 未签名的嵌套 images。
对 systemd-resolved 进行了各种改进。Systemd-resolved 现在在 /run/systemd/resolve/io.systemd.Resolve.Monitor 为 root 公开一个 varlink 套接字，该套接字可以为连接到该套接字的任何客户端提供 JSON 格式的已处理 DNS 请求。Systemd 的 resolvectl 现在也支持 "monitor" 选项来使用此 monitoring socket。
Portablectl 获得了一个 “--force” flag，用于跳过某些 sanity checks。
systemd-udev 现在将为 Infiniband 设备创建 infiniband/by-path 和 infiniband/by-ibdev 链接。
systemd 中的 mkosi 配置现在支持自动编译适合 systemd 测试的内核配置了。
更多详情可查看此处。
systemd是Linux下的一种init软件，由Lennart Poettering带头开发，并在LGPL 2.1及其后续版本许可证下开源发布。其开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。它确实能加快系统的启动过程，但同时也引入了复杂性、不开放性和引起了开源社区的巨大分裂。它直接导致了Debian Fork出来了无systemd的Debian分支Devuan，Gentoo发起了OpenRC、eudev项目等。
官方介绍
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.
systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.
systemd是linux的系统和服务管理器。systemd和SysV、LSB init scripts兼容，它可以作为sysvinit的一个替代品：
提供了更积极的并行能力
使用socket和D-Bus activation来启动服务
能够按需启动守护进程
采用基于依赖关系的服务控制逻辑来完成各项事务
采用linux cgroups来跟踪进程
支持快照和恢复
管理存储挂载
与多数发行版使用的System V风格init相比，systemd采用了以下新技术：
采用Socket激活式与总线激活式服务，以提高相互依赖的各服务的并行运行性能；
用cgroups代替PID来追踪进程，以此即使是两次fork之后生成的守护进程也不会脱离systemd的控制。
从设计构思上说，由于systemd使用了cgroup与fanotify等组件以实现其特性，所以只适用于Linux。
大部分人用过传统的SysV init 初始化脚本，它通常情况下在/etc/rc.d/init.d/文件夹下。这些脚本调用守护进程二进制代码，在后台fork一个进程。尽管shell脚本非常的灵活，但是很难实现像superviseing(监管)进程和并行执行命令这样的任务。通过对systemd的新式守护进程的介绍，我们发现systemd可以在runtime(运行时)更加简单的监管和控制守护进程，并且简化了监控的实现方式(implementation)。在 systemd 之前，init 程序的实现就有 SysV Init，Ubuntu 的 upstart，Gentoo 的 OpenRC 等等。
systemd最大特点有两个：令人惊奇的激进的并发启动能力，极大地提高了系统启动速度；另外就是用 CGroup 统计跟踪子进程，干净可靠。
反对systemd的意见主要是：
不遵循 UNIX 原则。
systemd 在设计之初就不考虑 Linux 以外的平台，不遵循 POSIX 标准，而且很多功能根本就是 Linux 特有的，无法移植到 Linux 之外的平台，这尤其让 BSD 爱好者们很受伤，在 Debian 7 以前，一直维护着Linux和FreeBSD两个内核，只不过后者没什么人用，Debian 8 为了支持systemd 不得不放弃支持 Debian kFreeBSD。
接管了太多服务，如 syslog 被 systemd-journal 取代，crond 也被 systemd 的 timer 单元取代，udev 也准备集成到 systemd 中来，未来甚至还可能取代 /etc/fstab。尽管这些新的服务大部分都是独立于主进程的，但是还是有整个系统被红帽控制住的感觉(systemd的作者Lennart Poettering 就职于红帽，systemd 也主要是红帽的 Fedora 首先在推，OpenSUSE 后面跟随)。这在开源社区看来是件不正确的事情。
systemd引入了一个新术语：cgroups(控制组)，它基本上是可被分层次安排的进程任务组。
这里简单介绍一下cgroup(control group)称为Containers，Containers着眼于资源的分配，利用configfs作配置。它有两个重要概念：
第一是 subsystem，内核可以给进程提供的服务/资源；
第二是container，一个进程组，成员共享同样的一个或多个子系统分配限制。Containers是分层次的，一个container可以hold多个container。它的可取之处是创建了一个资源分配的框架，其它开发者可以利用这个框架去开发自己的资源分配patch，比如磁盘设备。
如果仅仅通过原来的初始化系统，决定哪个进程是做什么的、属于哪个用户的变得越来越困难。但是通过systemd，当一个进程派生其它进程时，这些子进程会被自动变成父进程控制组的成员，这样一来就可以避免继承的混乱。
单元的概念
系统初始化需要做的事情非常多。需要启动后台服务，比如启动 SSHD 服务；需要做配置工作，比如挂载文件系统。这个过程中的每一步都被 systemd 抽象为一个配置单元，即 unit。可以认为一个服务是一个配置单元；一个挂载点是一个配置单元；一个交换分区的配置是一个配置单元；等等。systemd 将配置单元归纳为以下一些不同的类型。然而systemd 正在快速发展，新功能不断增加。所以配置单元类型可能在不久的将来继续增加。
service ：代表一个后台服务进程，比如 mysqld。这是最常用的一类。
socket ：此类配置单元封装系统和互联网中的一个 套接字 。当下，systemd 支持流式、数据报和连续包的 AF_INET、AF_INET6、AF_UNIX socket 。每一个套接字配置单元都有一个相应的服务配置单元 。相应的服务在第一个"连接"进入套接字时就会启动(例如：nscd.socket 在有新连接后便启动 nscd.service)。
device ：此类配置单元封装一个存在于 Linux 设备树中的设备。每一个使用 udev 规则标记的设备都将会在 systemd 中作为一个设备配置单元出现。
mount ：此类配置单元封装文件系统结构层次中的一个挂载点。Systemd 将对这个挂载点进行监控和管理。比如可以在启动时自动将其挂载；可以在某些条件下自动卸载。Systemd 会将/etc/fstab 中的条目都转换为挂载点，并在开机时处理。
automount ：此类配置单元封装系统结构层次中的一个自挂载点。每一个自挂载配置单元对应一个挂载配置单元 ，当该自动挂载点被访问时，systemd 执行挂载点中定义的挂载行为。
swap： 和挂载配置单元类似，交换配置单元用来管理交换分区。用户可以用交换配置单元来定义系统中的交换分区，可以让这些交换分区在启动时被激活。
target ：此类配置单元为其他配置单元进行逻辑分组。它们本身实际上并不做什么，只是引用其他配置单元而已。这样便可以对配置单元做一个统一的控制。这样就可以实 现大家都已经非常熟悉的运行级别概念。比如想让系统进入图形化模式，需要运行许多服务和配置命令，这些操作都由一个个的配置单元表示，将所有这些配置单元 组合为一个目标(target)，就表示需要将这些配置单元全部执行一遍以便进入目标所代表的系统运行状态。 (例如：multi-user.target 相当于在传统使用 SysV 的系统中运行级别 5)
timer：定时器配置单元用来定时触发用户定义的操作，这类配置单元取代了 atd、crond 等传统的定时服务。
snapshot ：与 target 配置单元相似，快照是一组配置单元。它保存了系统当前的运行状态。
每个配置单元都有一个对应的配置文件，系统管理员的任务就是编写和维护这些不同的配置文件
对老的sysvinit的影响
systemd 已经创建了比任何软件都多的技术问题、感情问题和社会问题。这一点从“Linux 初始化软件之战”上就能看出，这场争论在 Debian 开发者之间持续了好几个月。当 Debian 技术委员会最终决定将 systemd 放到 Debian 8 Jessie的发行版里面时，其反对者试图通过多种努力来取代这项决议。
这也说明了 systemd 对 Unix 传承下来的系统处理方式有很大的干扰。“一个软件只做一件事情”的哲学思想已经被这个新来者彻底颠覆。除了取代了 sysvinit 成为新的系统初始化工具外，systemd 还是一个系统管理工具。目前为止，由于 systemd-sysv 这个软件包提供的兼容性，那些我们使用惯了的工具还能继续工作。但是当 Debian 将 systemd 升级到214版本后，这种兼容性就不复存在了。升级措施预计会在 Debian 8 "Jessie" 的稳定分支上进行。从此以后用户必须使用新的命令来管理系统、执行任务、变换运行级别、查询系统日志等等。
systemd 不仅提供了比 sysvinit 更快的启动速度，还让日志系统在更早的时候启动起来，可以记录内核初始化阶段、内存初始化阶段、前期启动步骤以及主要的系统执行过程的日志。所以以前那种需要通过对显示屏拍照或者暂停系统来调试程序的日子已经一去不复返啦。
systemd 的日志文件都被放在 /var/log 目录。如果你想使用它的日志功能，需要执行一些命令。
Systemd 的并发启动
在 Systemd 中，所有的服务都并发启动，比如 Avahi、D-Bus、livirtd、X11、HAL 可以同时启动。Systemd 的开发人员仔细研究了服务之间相互依赖的本质问题，发现所谓依赖可以分为三个具体的类型(socket 依赖、D-Bus 依赖、文件系统依赖)，而每一个类型实际上都可以通过相应的技术解除依赖关系。
我还想找到无(No Systemd)systemd的发行版本
这个可以在Without Systemd Wiki页面中找到，还是有相当多的Linux发行版本，像笔者就从Debian迁移到了Crux这个小巧的发行版本了。
参考来源：
Systemd 专题
systemd 与 sysVinit 彩版对照表
Systemd On Wikipedia
Without Systemd
Linux系统启动速度优化工具systemd-analyze，它是Linux自带的分析系统启动性能的工具。
systemd-analyze可使用的命令：
systemd-analyze [OPTIONS…] [time]
systemd-analyze [OPTIONS…] blame
systemd-analyze [OPTIONS…] critical-chain [UNIT…]
systemd-analyze [OPTIONS…] plot [> file.svg]
systemd-analyze [OPTIONS…] dot [PATTERN…] [> file.dot]
systemd-analyze [OPTIONS…] dump
systemd-analyze [OPTIONS…] set-log-level LEVEL
systemd-analyze [OPTIONS…] set-log-target TARGET
systemd-analyze [OPTIONS…] get-log-level
systemd-analyze [OPTIONS…] get-log-target
systemd-analyze [OPTIONS…] syscall-filter [SET…]
systemd-analyze [OPTIONS…] verify [FILES…]
systemd-analyze命令具体含义：
systemd-analyze 可以显示系统启动过程中的性能统计数据、 获取 systemd 系统管理器的状态与跟踪信息、 校验单元文件的正确性。
systemd-analyze time 可以显示如下时间：
(1)在启动第一个用户态进程(init)之前，内核运行了多长时间；
(2)在切换进入实际的根文件系统之前，initrd(initial RAM disk)运行了多长时间；
(3)进入实际的根文件系统之后，用户空间启动完成花了多长时间。
注意，上述时间只是简单的计算了系统启动过程中到达不同标记点的时间，并没有计入各单元实际启动完成所花费的时间以及磁盘空闲的时间。
systemd-analyze blame 按照每个单元花费的启动时间从多到少的顺序，列出所有当前正处于活动(active)状态的单元。这些信息有助于用户优化系统启动速度。不过需要注意的是，这些信息也可能具有误导性，因为花费较长时间启动的单元，有可能只是在等待另一个依赖单元完成启动。
systemd-analyze critical-chain [UNIT…] 为指定的单元(省略参数表示默认启动目标单元)以树状形式显示时间关键链(time-critical chain)。“@”后面的时刻表示该单元的启动时刻；“+”后面的时长表示该单元总计花了多长时间才完成启动。不过需要注意的是，这些信息也可能具有误导性，因为花费较长时间启动的单元，有可能只是在等待另一个依赖单元完成启动。
systemd-analyze plot 输出一个 SVG 图像，详细显示每个单元的启动时刻， 并高亮显示每个单元总计花了多长时间才完成启动。
systemd-analyze dot 按照 GraphViz dot(1) 格式输出单元间的依赖关系图。在实践中，通常使用 systemd-analyze dot | dot -Tsvg > systemd.svg 命令来最终生成描述单元间依赖关系的 SVG 图像。除非使用了 –order 或 –require 选项限定仅显示特定类型的依赖关系，否则将会显示所有的依赖关系。如果指定了至少一个 PATTERN 参数(例如 *.target 这样的 shell 匹配模式)，那么将会仅显示所有匹配这些模式的单元的直接依赖关系。
systemd-analyze dump 按照人类易读的格式输出全部单元的状态(一般都有几千数万行)。 因为它的输出格式经常在未通知的情况下发生变化， 所以切勿将此输出用于程序分析。
systemd-analyze set-log-level LEVEL 将 systemd 守护进程的日志等级更改为 LEVEL (可使用的值参见 systemd(1) 的 –log-level= 选项)
systemd-analyze set-log-target TARGET 将 systemd 守护进程的日志目标更改为 TARGET (可使用的值参见 systemd(1) 的 –log-target= 选项)
systemd-analyze get-log-level 打印出 systemd 守护进程当前的日志等级。
systemd-analyze get-log-target 打印出 systemd 守护进程当前的日志目标。
systemd-analyze syscall-filter [SET…] 如果指定了至少一个 SET 参数，那么仅显示指定的集合所包含的系统调用列表；否则显示全部系统调用集合的详情。注意，必须在 SET 参数中包含 “@” 前缀。
systemd-analyze verify 校验指定的单元文件以及被指定的单元文件引用的其他单元文件的正确性，并显示发现的错误。FILES参数可以是单元文件的精确路径(带有上级目录)，也可以仅仅是单元文件的名称(没有目录前缀)。对于那些仅给出了文件名(没有目录前缀)的单元，将会优先在其他已经给出精确路径的单元文件的所在目录中搜索，如果没有找到，将会继续在常规的单元目录中搜索(详见unit(5)手册)。可以使用$SYSTEMD_UNIT_PATH 环境变量来更改默认的单元搜索目录。
如果没指定任何命令，那么等价于使用 systemd-analyze time 命令。
systemd-analyze 实战
Startup finished in 3.220s (kernel) + 23.420s (userspace) = 26.641s
graphical.target reached after 23.111s in userspace
可以看到开机用了23秒以上，接下来查询下这锅应该谁背：
systemd-analyze blame
21.594s NetworkManager-wait-online.service
680ms systemd-logind.service
587ms lvm2-monitor.service
570ms lightdm.service
534ms dev-sdc2.device
371ms upower.service
309ms tlp.service
292ms systemd-timesyncd.service
260ms systemd-udevd.service
252ms ModemManager.service
217ms systemd-journald.service
131ms systemd-journal-flush.service
121ms boot-efi.mount
117ms avahi-daemon.service
115ms bluetooth.service
111ms polkit.service
111ms NetworkManager.service
110ms udisks2.service
102ms systemd-modules-load.service
可以看到NetworkManager-wait-online.service耗时最长，花了21秒。这里的记时有可能是等待其他服务器启动的，再来看看其关联服务的启动时间：
systemd-analyze critical-chain NetworkManager-wait-online.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
NetworkManager-wait-online.service +21.594s
└─NetworkManager.service @1.398s +111ms
└─dbus.service @1.390s
└─basic.target @1.389s
└─sockets.target @1.389s
└─dbus.socket @1.389s
└─sysinit.target @1.384s
└─systemd-backlight@backlight:intel_backlight.service @1.313s +71ms
└─system-systemd\x2dbacklight.slice @1.312s
└─system.slice @207ms
└─-.slice @207ms
可这一看到这里它在等待其他的服务，但是也没有花21秒怎么多。
发现了影响启动的服务，最简单的方式是禁用此服务：
sudo systemctl disable NetworkManager-wait-online.service
方案二：编辑/lib/systemd/system/NetworkManager-wait-online.service文件，将文件中的
[Service] Type=oneshot ExecStart=/usr/bin/nm-online -s -q --timeout=30
超时时间由30改为10。
另外来看下还有哪些开机启动的服务可被优化：
systemctl list-unit-files --type=service | grep enabled
autovt@.service enabled
avahi-daemon.service enabled
bluetooth.service enabled
bumblebeed.service enabled
cronie.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.ModemManager1.service enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timesync1.service enabled
display-manager.service enabled
getty@.service enabled
lightdm.service enabled
ModemManager.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager.service enabled
org.cups.cupsd.service enabled
systemd-fsck-root.service enabled-runtime
systemd-remount-fs.service enabled-runtime
systemd-timesyncd.service enabled
tlp-sleep.service enabled
tlp.service enabled
ufw.service enabled
相关服务对应的功能：
NetworkManager-wait-online.service：网络服务管理器，禁用后不影响正常的网络使用
autovt@.service：登陆相关 保留
avahi-daemon.service：让程序自动发现本地网络服务。除非你有兼容的设备或使用 zeroconf 协议的服务，否则应该关闭它。
service：蓝牙服务，如果使用也可以禁用
service：显卡驱动，保留
service：预定日程和时间触发事件的守护进程。保留
dbus-org.bluez.service：蓝牙守护进程，可禁止
dbus-org.freedesktop.Avahi.service：让程序自动发现本地网络服务。除非你有兼容的设备或使用 zeroconf 协议的服务，否则应该关闭它。
dbus-org.freedesktop.ModemManager1.service：用于提供移动宽频broadband(2G/3G/4G)接口。可禁用
dbus-org.freedesktop.NetworkManager.service：桌面网卡管理可禁用
dbus-org.freedesktop.nm-dispatcher.service：网卡守护进程，可禁用
dbus-org.freedesktop.timesync1.service：时间同步，可禁用
display-manager.service： 用来管理显示的生命周期，它决定如何根据当前连接的物理显示设备控制其逻辑显示，保留
getty@.service enabled：tty控制台相关，保留
service enabled：图形化界面显示，保留
service： 被 dbus 激活的守护进程，用于提供移动宽频broadband(2G/3G/4G)接口。可禁用
NetworkManager-dispatcher.service：网卡守护进程，可禁用
service：检测网络、自动连接网络的程序。建议保留
cups.cupsd.service：通用UNIX打印系统守护进程.，可禁用
systemd-fsck-root.service：负责对根文件系统进行检查，建议保留
systemd-remount-fs.service：在系统启动早期启动的服务，它会根据 fstab(5) 中设置的挂载选项，重新挂载根目录与 /usr 目录， 以及虚拟文件系统。这是一个必需的动作， 因为这些文件系统在能够读取 /etc/fstab 文件之前，就已经被预先挂载了， 例如在初始内存盘(initial RAM disk)中挂载、或在进入容器环境前挂载。保留
systemd-timesyncd.service：跨网络同步系统时钟的守护服务，可禁用
tlp-sleep.service：电池优化，电源管理，建议保留
service：电池优化，电源管理，建议保留
service： 防火墙服务，建议保留
systemd 246 稳定版发布
2020年08月04日，systemd 246 稳定版已发布，此版本提供了大量新功能，其中许多功能与对磁盘卷的加密和签名支持有关，今年秋季发布更新的 Linux 发行版有机会用上。该版本的主要更新有：
systemd -journald 支持使用 Zstd 压缩日志文件。同样，systemd-coredump 收集的 coredumps 也可以使用 Zstd 算法进行压缩
systemd 自动创建的 Tmpfs 挂载，如 /tmp 和 /run，现在对 /tmp 和 /dev/sdm 的内存限制为 50%，而对其他挂载的内存限制为 10%
systemd-homed 的 LUKS 后台可以在用户注销时自动丢弃空的系统块（empty system blocks）
systemd-homed 可更好地保护潜在的双重数据加密场景，它还支持使用 FIOD2 安全令牌解锁主目录
systemd-cryptsetup 现在可以在引导启动过程中激活 Microsoft BitLocker 卷
新增 systemd-xdg-autostart-generator 命令，用于从 XDG autostart .desktop 文件生成 systemd unit 文件
支持在引导启动时使用内核选项命令 systemd.hostname= 设置系统主机名，此外还有其他新的内核命令行选项，比如 systemd.swap= 用于切换是否启用 SWAP，systemd.clock-usec= 用于指定引导时的 Unix 时间
systemd 已开始创建一个新的硬件数据库文件，它正在收集关于 PCI 和 USB 设备正确自动暂停的信息。此数据库最初基于来自 ChromeOS/ChromiumOS 的数据
对 cgroup v2 freezer 的基本支持
PID 1 可以在引导启动早期时自动加载预编译的 AppArmor 策略
systemd 247 稳定版发布
2020年12月1号，systemd 247 已正式发布，systemd 是 Linux 系统的一组基本构件。它提供了一个以 PID 1 身份运行的系统和服务管理器，并引导启动了系统的其他部分。 该版本添加了一项名为 systemd-oomd 的新服务， 用于监控资源的争夺情况，并在当内存/交换空间压力超过定义的限制时，可以终止进程。该功能目前处于实验性阶段，只在开发者模式下启用。 同时随着 Linux 发行版开始改用 Btrfs 作为默认文件系统，v247 中的 systemd-homed 在 LUKS 卷中创建主目录时也默认使用 Btrfs 文件系统。homed.conf 的 DefaultFileSystemType= 选项仍支持更改默认值。还包括以下更新内容：
用于 systemd-homed 的 JSON 用户记录增加了对“恢复密钥”的支持，作为解锁帐户/主目录的辅助口令。
Systemd-cryptsetup 获得了对处理内核命令行上指定的分离的 LUKS headers 的支持。
Bootctl 的 set-default 和 set-oneshot 命令现在可以接受三个特殊的字符串"@default"、"@oneshot"、"@current "来代替引导条目 id。
systemd 的系统服务现在支持"凭证(credentials)"逻辑，作为一种用安全可靠的方式将特权数据传递给服务的手段。预期的用例涉及到密码、加密密钥和其他每项服务的私有数据处理，但也有可能涉及到像用户名和证书这样的低特权数据。systemd-nspawn 是 systemd 凭证的早期使用者之一。
在系统中发现部分库的 runtime 依赖关系时，可以使用 dlopen() 加载，从而最大限度地减少 systemd 可能需要的依赖关系，并构建体积更小的操作系统镜像。
用于检查操作系统磁盘镜像的 systemd-dissect 工具已经被移动至 /usr/bin 中，已升级为具有稳定接口的官方支持工具。
systemd-repart partitioner 现在可以选择以 JSON 形式转储其输出。
设置 SYSTEMD_RDRAND=0 环境变量将禁用 RdRand CPU 指令的使用，即便是在支持的 CPU 上。
systemd 250 稳定版发布
2021年12月下旬，systemd 250 正式版发布，这是一个重大更新版本。它包含了过去半年多积累的许多新功能和改进，在发布多个候选版之后，终于在近日正式发布：
支持加密和经过身份验证的凭据。这可以是存储在 /var/ 或系统上的 TPM2 芯片上的密钥，其中凭据将在服务启动时自动解密。还有一个名为 systemd-creds 的新工具用于处理凭据，可用于 SSL 证书、密码和其他类似数据。
扩展 GPT 可发现分区规范 (GPT Discoverable Partitions Specification)，支持 systemd 支持的大多数架构上的 root 和 /usr/ 分区，以及其他更改。
Systemd-logind 具有新的设置，可用于长按系统上的电源、重启或挂起键。如果想要控制行为，可以将长按（大于 5 秒）这些按钮配置为登录。
RestrictFileSystems= for 的新 per-service 设置用于限制服务可以根据其类型访问的文件系统。
服务还有一个新设置 RestrictNetworkInterfaces= for 用于限制对特定网络接口的服务访问。
默认的最大 inode 数已从 /dev 的 64k 增加到 1M，而 /tmp 从 400k 增加到 1M。
per-user 服务管理器现在支持与 systemd-oomd 通信以获取内存不足的终止信息。
各种 TPM 2.0 可信平台模块的支持改进。
支持使用新的 /etc/integritytab 文件在启动时激活 dm-integrity 卷。
用于信号分析仪和相机的新硬件数据库。摄像头硬件数据库会跟踪摄像头是否指向前/后以及不同类型（例如红外）
在使用 sd-boot 加载程序时添加了一个新单元 systemd-boot-update.service，以确保引导加载程序保持最新，并从 /usr 中的操作系统树信息自动传播。
更轻松地支持在运行 systemd-homed 时在系统之间迁移主目录。Systemd-homed 现在在支持的内核/文件系统上使用 UID 映射安装，其中文件现在由“nobody”内部拥有，然后通过 UID 映射安装接口映射到系统本地使用的 UID。这通过不再需要递归 chown 文件来改进系统之间的主目录迁移。
在 Fedora 最近决定这样做之后，Systemd-homed 现在默认为家庭区域使用 Btrfs Zstd 压缩。
对 LoongArch 架构的初步支持。
Systemd-journald 现在为支持的文件系统上的归档日志文件重新启用写时复制。
在 /etc/machine-info 中引入 KERNEL_INSTALL_MACHINE_ID= 支持。该值将优先于任何 /etc/machine-id 值。
支持从 /loader/credentials/*.cred 加载凭据，用于 SSH 密钥、rootfs 加密密钥、dm-integrity 密钥等凭据。这些用于非内核/initrd 特定的凭据，可加载任何内核映像。
自 Windows Vista 以来使用的 Microsoft Windows 启动数据的适当 BCD（启动配置数据）解析器。
systemd 网络生成器现在支持用于具有 IPv6 链路本地连接的 link6 网络配置。
允许使用新的“-Dlink-boot-shared=false”选项为 bootctl 和 systemd-bless-boot 静态链接构建。添加此支持是由 CentOS/RHEL 9 驱动的，CentOS/RHEL 9 具有除 bootctl/systemd-bless-boot 之外的完整 systemd 堆栈。
systemd 日志的打孔改进。
默认启用 systemd-network-generator
Systemd 和 PulseAudio 作者离开红帽，加入了微软
科技媒体 Phoronix 于2022年7月上旬消息称，Systemd 的首席开发人员 Lennart Poettering 已经离开红帽并加入了微软，以继续他在 systemd 方面的工作。Lennart 在红帽工作了 15 年之久，还领导了 PulseAudio、Avahi 项目的创建。
Lennart 对现代的 Linux 桌面一直起着重要作用。目前还没有关于他工作变动的正式官方公告，但外界已经有很多人在讨论他的去向；还有一些人在社交媒体上公开评论，暗示他加入了 Redmond 公司。针对这些言论，Phoronix 方面在进行了一天的跟踪调查后表示，“事实证明这并不是一个玩笑。这位负责多个知名项目的著名开源开发者加入了微软，并继续专注于 systemd 开发。虽然有些人可能并不总是赞同他的观点或处理一些事情的方法，但他对 Linux / 开源世界的巨大贡献以及他多年来对推进生态系统的奉献是不言而喻的。”
事实上，微软方面一直都在招揽了一些 Linux 开发人员和其他著名的开源开发人员人才。包括雇佣了 Python 之父 Guido van Rossum，还有 GNOME 创建者 Miguel de Icaza 曾在 2016 年微软收购 Xamarin 时受雇，但已于今年早些时候离开微软；Nat Friedman 作为 Xamarin 的一员，在公司被微软收购后担任了 GitHub 的 CEO；Gentoo Linux 创始人 Daniel Robbins 之前也受雇于微软，Steve French 作为 Linux CIFS/SMB2/SMB3 的维护者和 Samba 团队的成员为微软工作。
且微软也曾雇佣了大量的上游 Linux 开发者，如 Matteo Croce、Matthew Wilcox、Tyler Hicks、Shyam Prasad N、Michael Kelley，以及许多其他的 Linux 爱好者 / 开发者所能一眼认出的名字。就在今年早些时候，另一位长期 Linux 内核开发人员 Christian Brauner 也加入了微软。Christian Brauner 曾在 Canonical 从事 Linux 内核、LXC、systemd 等方面的工作，后来转到了微软。随着 Linux 在 Azure 上的普及，Windows Subsystem for Linux (WSL) 的成功进一步得到了验证。微软致力于 Mesa 作为在 Direct3D 12 之上支持各种图形 / 计算 API 的一部分，确保 Linux 内核中良好的 Hyper-V 支持；并维护各种像 CBL-Mariner 和 Azure Cloud Switch 这样的内部 Linux 发行版。因此，该公司也在继续吸引更多的上游 Linux 开发人员，包括开源生态系统的一些知名面孔。目前在Microsoft Careers上显示了 663 个提到 Linux 的工作职位。
systemd 252发布
systemd 252 现已于2022年11月上旬发布。公告写道，systemd 在 2023 年底后将不再支持 cgroups v1，如果用户运行的服务使用了 cgroups v1 特性，请尽早实现对 cgroups v2 的兼容。目前大多数 Linux 发行版已使用 cgroups v2。此外，systemd 还计划在 2023 年下半年移除对 split-usr 和 unmerged-usr 处理的支持，这项提醒对部分 Linux 发行版来说更为紧迫。部分新特性包括：
添加 systemd-measure 辅助工具，用于在启动附带 systemd-stub 的统一内核镜像 (UKI) 时预计算 PCR 测量值，可更好地推动 TPM2 策略。
如果 systemd 检测到操作系统镜像已经过了支持期限，它将设置一个 "support-ended" 标记元。这与 os-release 新增的 "SUPPORT_END=" 字段相呼应，用于指定操作系统支持状态被认定不受支持的日期。
为 ConditionCredential= 和 AssertCredential= 添加新的设置项，用于在没有提供特定凭据的情况下跳过失败的单元。
DefaultDeviceTimeoutSec= 可用于指定设备的默认超时。
允许在竞争 CPU 的不同用户服务之间进行更多资源隔离的更改。
支持 systemd 在 “first boot” 条件下进行完整预设，而不仅仅是启用。
C.UTF-8 现在用作默认语言环境，而没有配置其他任何内容。
新的 watchdog-related D-Bus 属性现在由 systemd 发布。
现在支持以 EFI 混合模式启动具有 32 位 UEFI 固件的 64 位内核的 Systemd 启动支持。
改进了对 Parallels 和 KubeVirt 虚拟化的检测。
OpenSSL 现在是 systemd-resolved 的默认加密后端，但仍支持 GnuTLS。
Systemd-repart 现在支持创建 SquashFS 分区以及 dm-verity 分区。
systemd-oomd 现在会在 cgroup 被 kill 时，会发送 “Killed” D-Bus 信号。
对于 RISC-V 上的 systemd，在启用 “SystemCallFilter” 选项时，现在将 riscv_flush_icache () 系统调用添加到默认允许的系统调用列表中。
现在允许 transient units 插入。
systemd 的 sd-stub 现在将使用 LoadImage/StartImage 来执行内核。sd-stub 现在还添加了一个临时 UEFI SecurityOverride 以允许 boot 未签名的嵌套 images。
对 systemd-resolved 进行了各种改进。Systemd-resolved 现在在 /run/systemd/resolve/io.systemd.Resolve.Monitor 为 root 公开一个 varlink 套接字，该套接字可以为连接到该套接字的任何客户端提供 JSON 格式的已处理 DNS 请求。Systemd 的 resolvectl 现在也支持 "monitor" 选项来使用此 monitoring socket。
Portablectl 获得了一个 “--force” flag，用于跳过某些 sanity checks。
systemd-udev 现在将为 Infiniband 设备创建 infiniband/by-path 和 infiniband/by-ibdev 链接。
systemd 中的 mkosi 配置现在支持自动编译适合 systemd 测试的内核配置了。
更多详情可查看此处。