systemd
摘自项目主页：
- systemd 是一个 Linux 系统基础组件的集合，提供了一个系统和服务管理器，运行为 PID 1 并负责启动其它程序。功能包括：支持并行化任务；同时采用 socket 式与 D-Bus 总线式启用服务；按需启动守护进程（daemon）；利用 Linux 的 cgroups 监视进程；支持快照和系统恢复；维护挂载点和自动挂载点；各服务间基于依赖关系进行精密控制。systemd 支持 SysV 和 LSB 初始脚本，可以替代 sysvinit。除此之外，功能还包括日志进程、控制基础系统配置，维护登陆用户列表以及系统账户、运行时目录和设置，可以运行容器和虚拟机，可以简单的管理网络配置、网络时间同步、日志转发和名称解析等。
systemctl 基本用法[编辑 | 编辑源代码]
监视和控制 systemd 的主要命令是 systemctl。其用途包括查看系统状态以及管理系统和服务。详见 systemctl(1)。
- 在 systemctl 参数中添加
-H 用户名@主机名可以远程控制其他机器。该功能使用 SSH 连接到远程的 systemd 实例。 - Plasma 用户可以安装 systemctl 图形前端 systemd-kcmAUR。安装后可以在系统管理下找到。
使用单元[编辑 | 编辑源代码]
单元通常包括但不限于：服务（.service）、挂载点（.mount）、设备（.device）和套接字（.socket）。
使用 systemctl 是，通常需要使用单元文件的全名，包括扩展名（例如 sshd.socket）。不过在以下 systemctl 命令中可以使用简写：
- 如果无扩展名，systemctl 会假定扩展名为 .service。例如，
netctl和netctl.service是等价的。 - 挂载点会自动转化为相应的 .mount 单元。例如，
/home等价于home.mount。 - 与挂载点类似，设备会自动转化为相应的 .device 单元，因此
/dev/sda2等价于dev-sda2.device。
详见 systemd.unit(5)。
@ 符号（例如：name@string.service ），这意味着它是模板单元 name@.service 的一个 实例，实际文件名中不包括 string 部分（如 name@.service）。string 被称作实例标识符，在 systemctl 调用模板单元时，会将其当作一个参数传给模板单元，模板单元会使用这个传入的参数代替模板中的 %I 指示符。在实例化之前，systemd 会先检查 name@string.suffix 文件是否存在。如果存在，就直接使用这个文件，而不是模板实例化。大多数情况下，包含 @ 标记都意味着这个文件是模板。如果一个模板单元没有实例化就调用，该调用通常返回失败，除非是某些例如 cat 之类的命令。下列命令默认对系统单元进行操作，因为 systemctl 默认了 --system 参数。若要对（调用用户的）用户单元进行操作，使用无 root 权限的systemctl --user。参看systemd/用户#基础设置以为所有用户启用或禁用单元。
- 下面的大部分命令都可以跟多个单元名，详细信息参见 systemctl(1)。
--now选项可与enable、disable和mask同时使用，可使这些动作立即生效，而非重启后生效。- 一个软件包可能会为不同的功能提供多个不同的单元。如果你刚安装了软件包，可以通过
pacman -Qql package | grep -Fe .service -e .socket命令检查这个软件包提供了哪些单元。
| 动作 | 命令 | 注释 |
|---|---|---|
| 分析系统状态 | ||
| 显示系统状态 | systemctl status |
|
| 列出正在运行的单元 | systemctl orsystemctl list-units |
|
| 列出失败的单元 | systemctl --failed |
|
| 列出已安装的单元1 | systemctl list-unit-files |
|
| Show process status for a PID | systemctl status pid |
cgroup slice, memory and parent |
| 检查单元状态 | ||
| 显示单元的手册页 | systemctl help 单元 |
如果单元支持 |
| 显示单元的状态 | systemctl status 单元 |
包括其是否在运行 |
| 检查单元是否配置为自动启动 | systemctl is-enabled 单元 |
|
| 启动、重新启动和重新加载单元 | ||
| 立即启动单元 | systemctl start 单元 as root |
|
| 立即停止单元 | systemctl stop 单元 as root |
|
| 重新启动单元 | systemctl restart 单元 as root |
|
| 重新加载单元及其配置 | systemctl reload 单元 as root |
|
| 重新加载 systemd 配置2 | systemctl daemon-reload as root |
扫描单元的变动 |
| 启用单元 | ||
| 开机自动启用单元 | systemctl enable 单元 as root |
|
| 开机自动启用单元，并立即启动它 | systemctl enable --now 单元 as root |
|
| 取消开机自动启用单元 | systemctl disable 单元 as root |
|
| 重新启用 单元3 | systemctl reenable 单元 as root |
先取消启用，再启用 |
| 屏蔽单元 | ||
| 屏蔽单元，使其无法启动4 | systemctl mask 单元 as root |
|
| 取消屏蔽单元 | systemctl unmask 单元 as root |
|
- systemd.unit(5) § UNIT FILE LOAD PATH 中描述了查找单元文件的路径。
- 这不会要求已改变的单元重新加载自己的配置（见重新加载动作）。
- For example, in case its
[Install]section has changed since last enabling it. - Both manually and as a dependency, which makes masking dangerous. 查看已禁用的单元：
# systemctl list-unit-files --state=masked
电源管理[编辑 | 编辑源代码]
安装 polkit 后才能以普通用户身份使用电源管理。如果你正登录在一个本地的 systemd-logind 用户会话，且当前没有其它活动的会话，那么以下命令无需 root 权限即可执行。否则（例如，当前有另一个用户登录在某个 tty），systemd 将会自动请求输入 root 密码。
| 动作 | 命令 |
|---|---|
| 重启 | systemctl reboot
|
| 关机 | systemctl poweroff
|
| 待机 | systemctl suspend
|
| 休眠 | systemctl hibernate
|
| 进入混合休眠模式（同时休眠到硬盘并待机） | systemctl hybrid-sleep
|
编写单元文件[编辑 | 编辑源代码]
systemd 单元文件的语法来源于 XDG 桌面项配置文件.desktop文件，最初的源头则是Microsoft Windows的.ini文件。单元文件可以从多个地方加载，systemctl show --property=UnitPath 可以按优先级从低到高显示加载目录：
/usr/lib/systemd/system/：软件包安装的单元/etc/systemd/system/：系统管理员安装的单元
- 当
systemd运行在用户模式下时，使用的加载路径是完全不同的。 - systemd 单元名仅能包含 ASCII 字符，下划线和点号和有特殊意义的字符('@', '-')。其它字符需要用 C-style "\x2d" 替换。参阅 systemd.unit(5) 和 systemd-escape(1) 。
单元文件的语法，可以参考系统已经安装的单元，也可以参考 systemd.service(5) 中的EXAMPLES章节。
# 开头的注释可能也能用在 unit-files 中，但是只能在新行中使用。不要在 systemd 的参数后面使用行末注释， 否则 unit 将会启动失败。处理依赖关系[编辑 | 编辑源代码]
使用 systemd 时，可通过正确编写单元配置文件来解决其依赖关系。典型的情况是，单元 A 要求单元 B 在 A 启动之前运行。在此情况下，向单元 A 配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依赖关系是可选的，可添加 Wants=B 和 After=B 。请注意 Wants= 和 Requires= 并不意味着 After= ，即如果 After= 选项没有制定，这两个单元将被并行启动。
依赖关系通常被用在服务（service）而不是目标（target）上。例如， network.target 一般会被某个配置网络接口的服务引入，所以，将自定义的单元排在该服务之后即可，因为 network.target 已经启动。
服务类型[编辑 | 编辑源代码]
编写自定义的 service 文件时，可以选择几种不同的服务启动方式。启动方式可通过配置文件 [Service] 段中的 Type= 参数进行设置。
Type=simple：（默认值） systemd认为该服务将立即启动。服务进程不会 fork 。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket 启用型。Type=forking：systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定PIDFile=，以便 systemd 能够跟踪服务的主进程。Type=oneshot：这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置RemainAfterExit=yes使得 systemd 在服务进程退出之后仍然认为服务处于启用状态。Type=notify：与Type=simple相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由libsystemd-daemon.so提供。Type=dbus：若以此方式启动，当指定的BusName出现在DBus系统总线上时，systemd认为服务就绪。Type=idle：systemd会等待所有任务处理完成后，才开始执行idle类型的单元。其他行为与Type=simple类似。
type 的更多解释可以参考 systemd.service(5)。
修改现存单元文件[编辑 | 编辑源代码]
为了避免和 pacman 冲突，不应该直接编辑软件包提供的文件。有两种方法可以不改动原始文件就做到修改单元文件：创建一个优先级更高的本地单元文件或创建一个片段，应用到原始单元文件之上。两种方法都需要在修改后重新加载单元，用 systemctl edit 编辑单元(会自动重载单元)或通过下面命令重新加载单元：
# systemctl daemon-reload
systemd-delta命令用来查看哪些单元文件被覆盖、哪些被修改。系统维护的时候需要及时了解哪些单元已经有了更新。- 使用
systemctl cat unit可以查看单元的内容和所有相关的片段.
替换单元文件[编辑 | 编辑源代码]
要替换 /usr/lib/systemd/system/unit, 创建文件 /etc/systemd/system/unit 并重新启用单元以更新链接：
# systemctl reenable unit
或者运行：
# systemctl edit --full unit
这将会在记事本中打开 /etc/systemd/system/unit，如果文件不存在，可以将安装的版本复制到这里，在编辑完成之后，会自动加载新版本。
附加配置片段[编辑 | 编辑源代码]
要附加配置片段，先创建名为 /etc/systemd/system/<单元名>.d/ 的目录，然后放入 *.conf 文件，其中可以添加或重置参数。这里设置的参数优先级高于原来的单元文件。下面的更新方式比较简单：
# systemctl edit unit
这将会在编辑器中打开文件 /etc/systemd/system/unit.d/override.conf，编辑完成之后自动加载。
Conflicts= 就必须 替换原始文件。重置到软件包版本[编辑 | 编辑源代码]
要回退单元的变更，使用 systemctl edit 并执行:
# systemctl revert unit
示例[编辑 | 编辑源代码]
例如，如果想添加一个额外的依赖，创建如下文件即可：
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit] Requires=<新依赖> After=<新依赖>
要修改一个非 oneshot 单元的 ExecStart 命令，创建下面文件:
/etc/systemd/system/unit.d/customexec.conf
[Service] ExecStart= ExecStart=new command
修改 ExecStart 前必须将其置空，参见 ([1] 。所有可能多次赋值的变量都需要这个操作，例如定时器的 OnCalendar 。
下面是自动重启服务的一个例子：
/etc/systemd/system/unit.d/restart.conf
[Service] Restart=always RestartSec=30
目标（target）[编辑 | 编辑源代码]
运行级别（runlevel）是一个旧的概念。现在，systemd 引入了一个和运行级别功能相似又不同的概念——目标（target）。不像数字表示的启动级别，每个目标都有名字和独特的功能，并且能同时启用多个。一些目标继承其他目标的服务，并启动新服务。systemd 提供了一些模仿 sysvinit 运行级别的目标，仍可以使用旧的 telinit 运行级别 命令切换。
获取当前目标[编辑 | 编辑源代码]
不要使用 runlevel 命令了：
$ systemctl list-units --type=target
创建自定义目标[编辑 | 编辑源代码]
在 sysvinit 中有明确定义的运行级别（如：0、1、3、5、6）与 systemd 中特定的 目标 存在一一对应的关系。然而，对于用户自定义运行级别（2、4）却没有。如需要同样功能，建议你以原有运行级别所对应的 systemd 目标为基础，新建一个/etc/systemd/system/<目标名>.target（可参考/usr/lib/systemd/system/graphical.target）, 然后创建目录/etc/systemd/system/<目标名>.wants，并向其中加入需启用的服务链接（指向/usr/lib/systemd/system/）。
"SysV 运行级别" 与 "systemd 目标" 对照表[编辑 | 编辑源代码]
| SysV 运行级别 | Systemd 目标 | 注释 |
|---|---|---|
| 0 | runlevel0.target, poweroff.target | 中断系统（halt） |
| 1, s, single | runlevel1.target, rescue.target | 单用户模式 |
| 2, 4 | runlevel2.target, runlevel4.target, multi-user.target | 用户自定义运行级别，通常识别为级别3。 |
| 3 | runlevel3.target, multi-user.target | 多用户，无图形界面。用户可以通过终端或网络登录。 |
| 5 | runlevel5.target, graphical.target | 多用户，图形界面。继承级别3的服务，并启动图形界面服务。 |
| 6 | runlevel6.target, reboot.target | 重启 |
| emergency | emergency.target | 急救模式（Emergency shell） |
切换当前运行目标[编辑 | 编辑源代码]
systemd中，运行目标通过“目标单元”访问。通过如下命令切换：
# systemctl isolate graphical.target
该命令仅更改当前运行目标，对下次启动无影响。这等价于sysvinit中的 telinit 3 或 telinit 5 命令。
更改开机默认启动目标[编辑 | 编辑源代码]
开机启动的目标是 default.target，默认链接到 graphical.target （大致相当于原来的运行级别5）。
用 systemctl 检查当前的默认启动目标：
# systemctl get-default
用 systemctl 修改default.target以变更开机默认启动目标：
$ systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target. Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.
另一方法是向bootloader添加内核参数：
systemd.unit=multi-user.target（大致相当于运行级别3）systemd.unit=rescue.target（大致相当于运行级别1）
默认目标顺序[编辑 | 编辑源代码]
Systemd 根据下面顺序选择 default.target：
- 上面的内核参数
/etc/systemd/system/default.target软链接/usr/lib/systemd/system/default.target软链接
临时文件[编辑 | 编辑源代码]
/usr/lib/tmpfiles.d/ 和 /etc/tmpfiles.d/ 中的文件描述了 systemd-tmpfiles 如何创建、清理、删除临时文件和目录，这些文件和目录通常存放在 /run 和 /tmp 中。配置文件名称为 /etc/tmpfiles.d/<program>.conf。此处的配置能覆盖 /usr/lib/tmpfiles.d/ 目录中的同名配置。
临时文件通常和服务文件同时提供，以生成守护进程需要的文件和目录。例如 Samba 服务需要目录 /run/samba 存在并设置正确的权限位，就象这样：
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
此外，临时文件还可以用来在开机时向特定文件写入某些内容。比如，要禁止系统从USB设备唤醒，利用旧的 /etc/rc.local 可以用 echo USBE > /proc/acpi/wakeup，而现在可以这么做：
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
详情参见systemd-tmpfiles(8) 和 tmpfiles.d(5)。
/sys 中的配置文件添加参数，因为 systemd-tmpfiles-setup 有可能在相关模块加载前运行。这种情况下，需要首先通过 modinfo <模块名> 确认需要的参数，然后在 /etc/modprobe.d 目录下的配置文件中修改配置参数。另外，还可以使用 udev 规则[损坏的链接：无效的章节]，在设备就绪时设置相应属性。定时器[编辑 | 编辑源代码]
一个定时器是一个以 .timer 为结尾的单元配置文件并包含由 systemd 控制和监督的信息。systemd/Timers
cron。systemd/Timers#替代 cron挂载[编辑 | 编辑源代码]
因为 systemd 也负责按 /etc/fstab 挂载目录。在系统启动和重新加载系统管理器时，systemd-fstab-generator(8) 会将 /etc/fstab 中的配置转化为 systemd 单元。
systemd 扩展了 fstab 的传统功能，提供了额外的挂载选项。例如可以确保一个挂载仅在网络已经连接时进行，或者仅当另外一个分区已挂载时再挂载。这些选项通常以 x-systemd. 开头，systemd.mount(5) § FSTAB 中包含了完整说明。
automounting 也是一个例子，可以在使用时，而不是启动时挂载分区，详情请参考 fstab#Automount with systemd。
GPT 分区自动挂载[编辑 | 编辑源代码]
在 GPT 分区磁盘系统上，systemd-gpt-auto-generator(8) 会按照 可探测分区规范 进行挂载。可以在 fstab 中忽略。
要禁用自动挂载，请修改分区的 类型 GUID 或设置分区属性 63 位 "不自动挂载"，详情参考 gdisk#Prevent GPT partition automounting。
小技巧[编辑 | 编辑源代码]
在网络已连接后再启动某服务[编辑 | 编辑源代码]
如果需要将某服务延迟到网络已连接后再启动, 直接在 .service 文件中包含以下依赖项:
/etc/systemd/system/foo.service
[Unit] ... Wants=network-online.target After=network-online.target ...
管理网络所用的软件的网络等待服务也必须启用。这样 network-online.target 才能正确反映网络状态.
- 如果你使用 NetworkManager, 启用
NetworkManager-wait-online.service. - 如果你使用 systemd-networkd, 只要
systemd-networkd.service是启用的，默认下systemd-networkd-wait-online.service也是启动的; 使用systemctl is-enabled systemd-networkd-wait-online.service检查一下, 不需要其他操作.
如果需要更为详细的解释，请查看 网络配置同步点 中的讨论.
默认启用新安装的单元[编辑 | 编辑源代码]
Arch Linux附带的 /usr/lib/systemd/system-preset/99-default.preset 包含 disable *. 这会导致默认情况下 systemctl preset 会禁用所有新安装的的单元, 比如某个新包安装后, 用户必须手动启用新单元.
如果你不需要这种行为, 直接创建一个把 /etc/systemd/system-preset/99-default.preset 连接到 /dev/null 的符号链接来覆盖配置文件. 这会导致 systemctl preset 无视单元类型直接启用所有单元 — 除非 systemctl preset的配置目录中有文件另有声明. 用户单元不受影响. 查看 systemd.preset 的帮助来获得更多信息.
systemd.preset 的手册页中指定的预设配置文件中明确指定要禁用哪个单元.应用程序环境沙盒[编辑 | 编辑源代码]
可以创建沙箱单元文件，以在加固的虚拟环境中隔离应用程序及其进程。systemd通过 命名空间, Capabilities 的黑/白名单, and control groups 和 执行环境配置 来将进程禁锢在容器中。
使用应用程序沙箱增强现有 systemd 单元文件通常需要反复试验测试，同时大量搭配 strace包, stderr 和 journalctl 等错误记录工具。你可能希望首先在上游文档中搜索已完成的测试以作为试验的基础。
关于如何使用 systemd 部署沙盒的一些示例:
CapabilityBoundingSet定义了一组白名单允许的能力，但也可用于将单元的特定能力列入黑名单。- 比如
CAP_SYS_ADM能力，它应是一个 安全沙箱的目标：CapabilityBoundingSet=~ CAP_SYS_ADM
- 比如
疑难解答[编辑 | 编辑源代码]
寻找错误[编辑 | 编辑源代码]
这个例子中的失败的服务是 systemd-modules-load :
1. 通过 systemd 寻找启动失败的服务:
$ systemctl --state=failed
systemd-modules-load.service loaded failed failed Load Kernel Modules
或者使用 systemd 消息:
$ journalctl -fp err
2. 我们发现了启动失败的 systemd-modules-load 服务. 我们想知道更多信息:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
Docs: man:systemd-modules-load.service(8).
man:modules-load.d(5)
Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
如果没列出 Process ID, 通过 systemctl 重新启动失败的服务 ( 例如 systemctl restart systemd-modules-load )
3. 现在得到了 PID ,你就可以进一步探查错误的详细信息了.通过下列的命令收集日志,PID 参数是你刚刚得到的 Process ID (例如 15630):
$ journalctl -b _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. -- Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp' Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'
4. 我们发现有些内核模块的配置文件不正确,因此在 /etc/modules-load.d/ 中检查一下:
$ ls -Al /etc/modules-load.d/
... -rw-r--r-- 1 root root 79 1. Dez 2012 blacklist.conf -rw-r--r-- 1 root root 1 2. Mär 14:30 encrypt.conf -rw-r--r-- 1 root root 3 5. Dez 2012 printing.conf -rw-r--r-- 1 root root 6 14. Jul 11:01 realtek.conf -rw-r--r-- 1 root root 65 2. Jun 23:01 virtualbox.conf ...
5. 错误消息 Failed to find module 'blacklist usblp' 也许和 blacklist.conf 相关. 让我们注释掉第三步发现的错误的选项:
/etc/modules-load.d/blacklist.conf
# blacklist usblp # install usblp /bin/false
6. 最后重新启动 systemd-modules-load 服务:
# systemctl start systemd-modules-load
如果服务成功启动,不会有任何输出.如果你还是遇到了错误,回到步骤三,获得新的 PID 来跟踪日志并解决错误.
可以像这样确认服务成功启动:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.
诊断启动问题[编辑 | 编辑源代码]
使用如下内核参数引导：
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
更多有关调试的信息，参见该文。
诊断一个服务[编辑 | 编辑源代码]
如果某个 systemd 服务的工作状况不合预期,希望调试的话,设置 SYSTEMD_LOG_LEVEL 环境变量 为 debug . 例如以调试模式运行 systemd-networkd 服务:
在此服务的配置文件片段中加入：
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
或者等价的,临时编辑系统单元文件,例如:
- SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
重启 systemd-networkd 服务，用 --follow 选项检查日志。
关机/重启十分缓慢[编辑 | 编辑源代码]
如果关机特别慢（甚至跟死机了一样），很可能是某个拒不退出的服务在作怪。systemd 会等待一段时间，然后再尝试杀死它。请阅读这篇文章，确认你是否是该问题受害者。
短时进程无日志记录[编辑 | 编辑源代码]
若 journalctl -u foounit.service 没有显示某个短时进程的任何输出，那么改用 PID 试试。例如，若 systemd-modules-load.service 执行失败，那么先用 systemctl status systemd-modules-load 查询其 PID（比如是123），然后检索该 PID 相关的日志 journalctl -b _PID=123。运行时进程的日志元数据（诸如 _SYSTEMD_UNIT 和 _COMM）被乱序收集在 /proc 目录。要修复该问题，必须修改内核，使其通过套接字连接来提供上述数据，该过程类似于 SCM_CREDENTIALS。
禁止在程序崩溃时转储内存[编辑 | 编辑源代码]
要使用老的内核转储，创建下面文件:
/etc/sysctl.d/49-coredump.conf
kernel.core_pattern = core kernel.core_uses_pid = 0
然后运行：
# /usr/lib/systemd/systemd-sysctl
同样可能需要执行“unlimit”设置文件大小：
$ ulimit -c unlimited
更多信息请参阅 sysctl.d(5) 和 /proc/sys/kernel 文档。
启动的时间太长[编辑 | 编辑源代码]
不少用户用了 systemd-analyze 命令以后报告启动的时间比预计的要长,通常会说 systemd-analyze 分析结果表示 NetworkManager 占据了太多的启动的时间.
有些用户的问题是 /var/log/journal 文件夹似乎过大.这也许也会对像systemctl status 或 journalctl 的命令有影响.一种解决方案是删除其中的文件 (但最好将它们备份到某处) 然后限制日志文件的大小.
systemd-tmpfiles-setup.service 在启动时启动失败[编辑 | 编辑源代码]
从 systemd 219 开始, /usr/lib/tmpfiles.d/systemd.conf 指定 /var/log/journal 的 ACL 属性和目录, 因此日志所在的文件系统上要启用ACL.
参阅 Access Control Lists#Enable ACL 获得如何包含 /var/log/journal 启动 ACL 的详细信息.
启动时显示的 systemd 版本和安装版本不一致[编辑 | 编辑源代码]
需要 重新生成 initramfs。
禁用远程机器的 emergency 模式[编辑 | 编辑源代码]
如果远程机器位于云主机，emergency 模式会导致系统无法远程连接，可以通过下面方式禁用紧急模式：
# systemctl mask emergency.service # systemctl mask emergency.target
参见[编辑 | 编辑源代码]
- Wikipedia:systemd
- Official web site
- 手册页
- 其他发行版
- Lennart's blog story, update 1, update 2, update 3, summary
- Debug Systemd Services
- systemd for Administrators (PDF)
- How To Use Systemctl to Manage Systemd Services and Units
- Session management with systemd-logind
- Emacs Syntax highlighting for Systemd files
- Two part introductory article in The H Open magazine.