Systemd by Example（2021）
Systemd 的强大与复杂性让 Linux 用户意见分裂：许多人称赞它的 timers、通过 journalctl 的日志记录以及统一的服务管理，而另一些人则在学习曲线、竞态条件和其被认为违背传统 Unix 哲学方面感到困难。评论者强调，优秀的参考文档、教程、playground，甚至 LLM，都能让创建 unit、timer 和受沙箱保护的服务变得高效，尤其是相比老旧的 init 系统和临时拼凑的 cron 配置。批评者则反驳说，它繁复的行为、不透明的默认设置以及与 Linux API 的紧耦合，使其更难调试、可移植性更差，而且在嵌入式或更简单的场景中有时过度。
概述
- 线程讨论了一系列关于 systemd 的教程，并以此作为更广泛争论 systemd 的优势、复杂性和理念的跳板。
- 许多人认为这套系列异常清晰，对构建关于 unit、job 和依赖关系的心智模型很有帮助。
学习 Systemd
- 这种基于示例的系列和一个在线 playground 被称赞为让 systemd 不再那么令人生畏。
- 有些人强调，systemd 的 man pages 作为参考文档很出色，但不适合作为教程。
- 少数人指出，LLM 在生成 unit 文件和 timer 方面出人意料地有效。
Systemd Timers vs Cron
- 几位用户强烈偏好 systemd timers：
- 清晰地区分“运行什么”与“何时运行”。
- 时间表达更易读（“hourly”、日历语法），并且可通过
systemctl status和journalctl更容易调试。
- 其他人则认为 cron 更简单，并且在类 Unix 系统之间更具可移植性，而且某些 cron 实现已经有
@hourly风格的快捷写法。 - 关于 systemd timers 是否真的“更具可移植性”的争论随之展开：一方把“可移植性”限定在 Linux 之内，另一方坚持它应该意味着跨多个操作系统家族。
UX：systemctl / journalctl
- 许多系统管理员喜欢统一日志：不必去
/var/log下追文件；journalctl -u service被视为很强大，尤其是在 verbose/json 模式下。 - 另一些人则觉得这个 CLI UX “繁复造作”或不直观：
- 子命令帮助行为和职责过载的命令（例如
journalctl同时用于分页和日志管理）让一些人感到沮丧。 - 二进制日志加上不熟悉的选项，让人难以确信自己看到了所有相关输出。
- 子命令帮助行为和职责过载的命令（例如
- 也有人承认，习惯和熟悉程度在很大程度上影响了哪种方式感觉“更简单”。
复杂性、理念与采用
- 支持 systemd 的声音：
- 强调沙箱、依赖处理、日志记录以及统一的服务管理。
- 认为 systemd 现在已经是主流 Linux 发行版上的事实标准，而“Unix 哲学”相比实用的可靠性和交付期限已不那么相关。
- 批评的声音：
- 认为 systemd 过于复杂，像“类 OS”，在边缘情况下难以推理（例如关机顺序、嵌入式网络竞态）。
- 更喜欢更简单的 init 系统或基于 shell 的 init 脚本；有些人已经退回 sysvinit，并感到更满意。
- 认为 systemd 破坏了传统的“小而可组合工具”的 Unix 精神，而且难以扩展或替换组件。
特殊情况与陷阱
- 嵌入式和网络密集型设置凸显了棘手的竞态条件以及不明显的指令（
RemainAfterExit、排序、network targets）。 - 有些人建议，这类情况或许最好使用 systemd 自己的网络组件来处理，而不是混用外部工具。