Upstart 和 systemd 是替代 SysVinit 的现代 init 系统，前者事件驱动、配置在 /etc/init/ 下、用 initctl 管理；后者单元依赖驱动、配置在 /usr/lib/systemd/system/ 等目录、用 systemctl 管理，且功能更全面。
Upstart 和 systemd 都是用来替代传统 SysVinit 的现代 init 系统，但它们的设计哲学、触发机制和管理方式有本质区别。当前主流发行版已基本淘汰 Upstart（Ubuntu 14.10 后弃用，RHEL 6 是最后广泛使用的版本），systemd 成为事实标准。理解两者的差异，有助于排查老系统问题或读懂遗留配置。
启动逻辑：事件驱动 vs 单元依赖驱动
Upstart 的核心是“事件”——服务的启停由系统或其它进程发出的事件触发。比如 udev 加载完成会广播 virtual-filesystems 事件，Upstart 检测到后就启动 udev 作业；某个服务启动成功后可主动发出 started myservice 事件，触发下游服务。这种机制让启动更灵活、响应更快，但也使流程不易追踪。
systemd 则基于“单元（unit）”和显式依赖关系。每个服务定义在 .service 文件中，通过 Wants=、After=、Requires= 等字段声明与其他单元的关系。systemd 在启动时构建依赖图，并尽可能并行启动无依赖冲突的服务。它不依赖外部事件，而是通过 socket 激活、D-Bus 激活、路径监控等内建机制实现按需启动。
配置文件位置与格式差异明显
Upstart 的作业配置存放在 /etc/init/ 目录下，以 .conf 结尾，纯文本格式，语法简洁：
- 用 start on 和 stop on 定义触发条件
- 用 exec 或 script 指定运行命令
- 不支持原生依赖声明，靠事件链间接表达先后关系
systemd 的服务单元文件主要位于：
- /usr/lib/systemd/system/：发行版默认提供的服务定义
- /etc/systemd/system/：管理员覆盖或自定义的服务（优先级最高）
- /run/systemd/system/：运行时生成的临时单元（如容器或挂载点）
文件是 INI 风格，结构清晰，分 [Unit]、[Service]、[Install] 等节，支持环境变量、资源限制、重启策略、日志绑定等丰富功能。
服务管理命令与状态可见性不同
Upstart 使用 initctl 工具：
- initctl list 查看所有作业状态（start/stop/waiting）
- initctl start/stop myjob 手动控制作业
- initctl emit myevent 手动发送事件（调试常用）
systemd 统一使用 systemctl：
- systemctl status myservice 显示详细状态、最近日志、cgroup 信息
- systemctl --failed 快速定位失败服务
- journalctl -u myservice 查看该服务专属日志流
- 所有服务自动集成到 journald，无需额外配置日志转发
兼容性与生命周期管理能力
Upstart 做到了对 SysVinit 脚本的兼容：它能读取 /etc/init.d/ 下的传统脚本，并将其包装为作业运行；/etc/inittab 中的 runlevel 设置仍被识别（如 RHEL 6）。但它本身不提供快照、状态恢复、挂载点管理等功能。
systemd 兼容 SysVinit 和 LSB 脚本，同时大幅扩展了系统管理边界：
- 统一管理系统服务、定时器（.timer）、套接字（.socket）、挂载点（.mount）、设备（.device）等各类资源
- 内置 cgroups v1/v2 支持，天然隔离资源、便于监控和限流
- 支持 systemctl snapshot 创建运行时快照，配合 systemctl restore 回滚（部分发行版启用）
- 提供 login session、user instance、container scope 等面向现代工作负载的抽象
systemd 不仅管“怎么启动”，还管“怎么活着”和“怎么收尾”，而 Upstart 更聚焦于“启动那一刻的响应”。
