1. 从init到systemd：为什么现代Linux离不开它

如果你在最近十年里用过任何一个主流的Linux发行版，比如Ubuntu、CentOS、Fedora或者Debian，那你几乎肯定和systemd打过交道，哪怕你当时并不知道它的名字。它就像一个无处不在的管家，从你按下开机键的那一刻起，就接管了几乎所有系统启动和服务的生命周期。但很多朋友对它的感情很复杂：一方面，它确实让系统管理变得统一和强大；另一方面，它的“霸道”和复杂性也常常让人头疼，网上甚至流传着“trying to remove systemd which is protected”这样的梗，足见其地位之稳固。

简单来说，systemd是一个系统和服务管理器。在它出现之前，Linux世界长期由SysV init脚本统治。那是一个“脚本为王”的时代，每个服务都自己写一个shell脚本来控制启动、停止，系统按顺序（串行）执行这些脚本。这种方式简单直接，但问题也很多：启动慢（因为要等前一个服务完全启动才能启动下一个）、依赖关系管理混乱、服务状态难以精确监控、日志分散等等。

systemd的出现就是为了解决这些问题。它用并行化的方式启动服务，只要服务之间没有依赖，就可以同时启动，这大大加快了系统启动速度。它用单元（Unit）文件这种声明式的配置文件来定义服务，取代了过程式的脚本，使得服务管理更加标准化。它还集成了日志管理（journald）、设备管理、网络配置等一大堆功能，试图提供一个统一的管理界面。所以，当你想“移除”systemd时，系统会拼命保护它，因为它已经深度嵌入到现代Linux的“五脏六腑”之中，不仅仅是几个服务脚本那么简单。

理解systemd，对于任何需要在Linux上进行运维、开发甚至日常使用的朋友来说，都是一项绕不开的基础技能。无论是排查服务启动失败，还是想把自己写的Java应用（正如热搜词里的“systemd部署java项目”）做成一个可靠的系统服务，亦或是解决“systemd 放启动脚本一会就服务关闭”这种诡异问题，都离不开对systemd核心机制的理解。接下来，我们就抛开那些复杂的理论，从实际使用的角度，一层层拆解这个强大的管家。

2. systemd的核心概念：单元、目标和依赖

要驾驭systemd，首先得弄懂它组织和管理系统的基本逻辑。这套逻辑的核心就是“单元”和“目标”。

2.1 单元：一切皆可配置的抽象

在systemd眼里，系统里的一切资源都可以被定义为一个“单元”。一个单元就是一个配置文件，描述了systemd需要管理的一个对象及其属性。这些配置文件通常存放在以下几个目录，优先级从高到低：

• /etc/systemd/system/：系统管理员创建和管理的自定义单元文件，优先级最高。
• /run/systemd/system/：运行时生成的单元文件，重启后消失。
• /usr/lib/systemd/system/：软件包安装的默认单元文件，不要直接修改这里。

单元有很多类型，每种类型以不同的后缀区分，最常用的几种你必须熟悉：

1. .service：这是你打交道最多的类型，代表一个后台服务。比如nginx.service、docker.service。我们部署Java项目，最终就是要创建一个.service单元。
2. .target：代表一组单元的集合，可以理解为“运行级别”的进化版。比如multi-user.target对应多用户命令行模式，graphical.target对应图形界面模式。系统启动就是从一个target切换到另一个target的过程。
3. .socket：监听一个套接字（网络或本地）。当有连接到来时，才启动对应的服务。这对于按需启动、节省资源非常有用。
4. .timer：用来替代cron的计划任务单元。可以基于日历时间或单调时间（开机后多久）来触发其他单元。
5. .mount和.automount：管理文件系统挂载。
6. .path：监控文件或目录的变化，并触发其他单元。

一个单元文件的结构很简单，主要由[Unit]、[Service]、[Install]等区块组成，每个区块下是一些键值对。我们稍后会详细拆解一个服务单元的写法。

2.2 依赖与顺序：精准控制启动流程

systemd强大的地方在于它能精确地描述单元之间的依赖关系和启动顺序。这是在[Unit]区块中定义的几个关键指令：

• Requires=：强依赖。如果A单元Requires=B，那么启动A时，B也必须被启动。如果B启动失败或停止，A也会被停止。
• Wants=：弱依赖。启动A时，会尝试启动B，但即使B启动失败，A仍然可以启动。这是更常用的依赖方式。
• After=/Before=：定义启动顺序。After=B表示A必须在B之后启动。它只定义顺序，不隐含依赖关系。通常需要和Wants=或Requires=配合使用。
• Conflicts=：冲突关系。如果A和B冲突，那么启动A时会停止B，反之亦然。

举个例子，一个Web应用服务可能Wants=network.target并且After=network.target，表示它希望在网络就绪后启动，但网络没起来它也能启动（虽然可能出错）。而一个数据库服务可能被很多其他服务Requires，成为系统的关键节点。

理解这些依赖，是解决服务启动顺序问题和编写复杂单元文件的基础。systemd会根据这些依赖关系自动生成一个启动树，并以最大并行度去执行，这也是系统启动变快的魔法所在。

3. 实战：编写一个可靠的systemd服务单元文件

理论说再多，不如动手写一个。我们以热搜词中“systemd部署java项目”为场景，假设我们有一个打包好的Spring Boot应用的JAR包，名叫myapp.jar，放在/opt/myapp/目录下。我们的目标是为它创建一个稳定运行、异常可自愈的systemd服务。

3.1 基础服务文件创建与剖析

首先，以管理员身份创建服务单元文件：

sudo vim /etc/systemd/system/myapp.service

文件内容如下，我们逐段分析：

[Unit] Description=My Awesome Java Application Documentation=https://myapp.com/docs After=network.target Wants=network.target [Service] Type=simple User=appuser Group=appgroup WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -jar /opt/myapp/myapp.jar Environment="JAVA_HOME=/usr/lib/jvm/java-11-openjdk" Environment="APP_PROFILE=prod" # 关键：重启策略 Restart=on-failure RestartSec=10 # 资源限制与安全 LimitNOFILE=65536 LimitNPROC=4096 PrivateTmp=true ProtectSystem=strict ReadWritePaths=/opt/myapp/logs /var/lib/myapp # 日志配置 StandardOutput=journal StandardError=journal SyslogIdentifier=myapp [Install] WantedBy=multi-user.target

[Unit]区块解析：

• Description：服务的描述信息，systemctl status时会显示。
• Documentation：可选，指向文档的URL。
• After和Wants：确保服务在网络就绪后启动。对于大多数网络应用，这是标准配置。

[Service]区块解析（核心部分）：

• Type：服务类型。simple是最常见的，systemd认为ExecStart启动的进程就是主服务进程。如果你的程序会自己fork到后台，应该用forking，并指定PIDFile。
• User/Group：极其重要！不要用root运行你的应用。创建一个专用用户和组（如appuser），用这个身份运行，可以极大提升安全性。
• WorkingDirectory：进程的工作目录。你的应用读取相对路径配置文件（如./application.yml）时，就是基于这个目录。
• ExecStart：启动命令的绝对路径。这就是为什么直接放脚本有时会失败——路径、环境变量可能不对。
• Environment：设置环境变量。对于Java应用，设置JAVA_HOME是稳妥的做法。

Restart与RestartSec：解决“服务一会就关闭”的关键。

• Restart=on-failure：仅在进程非正常退出（退出码非0）或被信号终止时重启。这是最常用的策略。其他值还有always（总是重启）、on-abnormal等。
• RestartSec=10：重启前等待10秒，避免程序频繁崩溃时疯狂重启消耗资源。

资源与安全限制：

• LimitNOFILE/LimitNPROC：限制进程能打开的文件描述符数量和子进程数，防止程序bug耗尽系统资源。
• PrivateTmp=true：给服务一个私有的/tmp目录，增强隔离性。
• ProtectSystem=strict：严格保护系统目录（如/usr，/boot）只读。
• ReadWritePaths：明确指定服务需要读写权限的路径。这是ProtectSystem的补充，实现了最小权限原则。

日志配置：

• StandardOutput/StandardError=journal：将标准输出和错误输出重定向到systemd的日志系统（journald），这样就能用journalctl统一查看日志。
• SyslogIdentifier：在日志中标识该服务消息的名称。

[Install]区块：

• WantedBy=multi-user.target：表示当系统进入multi-user.target（多用户命令行模式）时，这个服务应该被启用。执行systemctl enable myapp时，systemd实际上就是在multi-user.target.wants/目录下创建了一个指向本服务的软链接。

创建好文件后，需要让systemd重新加载配置，然后启动服务：

sudo systemctl daemon-reload # 必须执行，让systemd识别新单元文件 sudo systemctl start myapp sudo systemctl enable myapp # 设置开机自启

3.2 高级配置：应对复杂场景

上面的配置适用于大多数场景。但实际生产环境可能更复杂：

场景一：需要特定启动顺序如果你的Java应用依赖数据库和缓存，可以这样强化依赖：

[Unit] After=network.target postgresql.service redis.service Requires=postgresql.service redis.service

这样，只有PostgreSQL和Redis都成功启动后，你的应用才会启动。

场景二：应用启动慢，需要更长的超时时间有些Java应用（尤其是大型Spring应用）启动可能需要一两分钟。systemd默认的超时时间可能不够，会导致它误认为启动失败。

[Service] ... TimeoutStartSec=300 # 将启动超时时间设为300秒

场景三：优雅关闭（Graceful Shutdown）对于Web应用，直接发SIGTERM信号可能打断正在处理的请求。我们可以利用ExecStop来发送自定义停止指令，并留出宽限期。

[Service] ... ExecStop=/bin/kill -s TERM $MAINPID KillSignal=SIGTERM TimeoutStopSec=30 # 等待30秒，让应用处理完现有请求 KillMode=process # 只杀主进程，不杀整个进程组

对于Spring Boot应用，它内置了优雅关闭的端点，你可以把ExecStop做得更智能，比如先调用/actuator/shutdown端点（如果开启了的话）。

4. 服务生命周期管理与深度排错

服务跑起来了，管理它的生命周期和出了问题如何排查，是日常运维的必修课。

4.1 常用的systemctl命令

这些命令是你和systemd管家对话的主要方式：

• systemctl start|stop|restart|reload <unit>：启、停、重启、重载配置（如果服务支持）。
• systemctl status <unit>：最常用的命令，查看服务的实时状态、是否激活、最近的日志片段以及进程树。
• systemctl enable|disable <unit>：启用或禁用开机自启。
• systemctl is-enabled|is-active <unit>：检查服务是否启用或正在运行。
• systemctl daemon-reload：修改了单元文件后必须运行，让systemd重新加载配置。
• systemctl list-units --type=service --all：列出所有服务单元。
• systemctl list-dependencies <unit>：查看一个单元的依赖树，非常有用。

4.2 日志排查：journalctl的威力

当服务状态显示failed或者activating卡住时，journalctl是你的第一把手术刀。它是systemd的集中化日志工具。

• 查看特定服务的全部日志：

  sudo journalctl -u myapp.service

• 实时追踪日志（类似tail -f）：

  sudo journalctl -u myapp.service -f

• 查看从今天开始的日志：

  sudo journalctl -u myapp.service --since today

• 查看最近一次启动的日志（对于排查启动失败至关重要）：

  sudo journalctl -u myapp.service -b

• 按优先级过滤：-p参数可以按日志级别过滤，如-p err只看错误，-p info看信息和错误。
• 结合grep进行筛选：

  sudo journalctl -u myapp.service | grep -i "exception\|error"

很多“服务一会就关闭”的问题，根源都能在日志里找到。可能是：

1. 依赖缺失：日志里会提示Failed at step EXEC，或者连接数据库失败。
2. 权限问题：Permission denied，检查User/Group以及文件权限。
3. 端口冲突：Address already in use。
4. 应用自身错误：Java的NullPointerException，配置文件读取失败等。

4.3 深入诊断：systemd-analyze与状态探针

如果日志还不够清晰，可以用更底层的工具：

• systemd-analyze blame：列出每个单元启动所用的时间，帮你找到拖慢系统启动的“元凶”。
• systemd-analyze critical-chain <unit>：图形化显示指定单元启动的关键路径，即哪些依赖的延迟导致了该单元启动慢。这对于优化启动顺序非常有帮助。
• 检查服务的详细属性：

  sudo systemctl show myapp.service

  这会输出该服务的所有内部属性，包括进程ID、控制组路径、内存用量等，信息量巨大。
• 进入服务的CGroup命名空间：systemd使用CGroup来管理进程组资源。你可以通过systemd-cgls查看层级，或者直接进入服务所在的CGroup查看所有进程：

  sudo systemd-cgtop # 类似top，按CGroup显示资源使用 ps -ef | grep $(systemctl show -p MainPID myapp.service | cut -d= -f2) # 查找服务的主进程及其子进程

5. 避坑指南：从“trying to remove systemd”到服务稳定运行

网上关于systemd的抱怨，很多源于不熟悉其设计哲学和操作细节。这里集中解答几个高频问题。

5.1 为什么“无法移除systemd”？

这个热搜词反映了一个常见误解。在绝大多数现代发行版中，systemd是PID 1（第一个进程），是系统的基石。它管理着所有其他进程、挂载点、套接字等。试图用apt remove systemd或yum remove systemd，包管理器会阻止你，因为它会破坏几乎整个系统的功能。

如果你真的需要一个没有systemd的环境，应该选择那些明确不使用systemd的发行版，比如Devuan（Debian的衍生版）、Artix Linux，或者某些容器基础镜像（如Alpine Linux早期版本）。在已安装systemd的系统上“移除”它，不是一个可行的操作，更像是一次系统重装。

5.2 服务自动关闭的N种可能及排查链路

“systemd 放启动脚本一会就服务关闭”这个问题非常典型。请按照以下链路逐步排查：

第一步：立即查看服务状态和日志

sudo systemctl status myapp.service sudo journalctl -u myapp.service -b --no-pager | tail -50

状态信息会明确告诉你服务是failed、inactive还是activating。日志的前几行错误信息是黄金线索。

第二步：检查单元文件语法和路径

1. 语法检查：systemd-analyze verify /etc/systemd/system/myapp.service。这个命令能发现很多配置文件的低级错误。
2. 路径与权限：确认ExecStart的命令、WorkingDirectory的路径都存在且可执行。特别是，如果User不是root，要确保该用户对相关目录和文件有读、写、执行（如果需要）的权限。一个快速测试方法是切换到该用户手动执行启动命令：

sudo -u appuser /usr/bin/java -jar /opt/myapp/myapp.jar

第三步：审查重启策略与退出码如果服务是反复重启后最终放弃，查看Restart配置。如果设成了on-failure，但你的程序是正常退出（退出码为0），systemd是不会重启它的。在Java中，System.exit(0)就是正常退出。你需要确保程序在异常时才返回非0码，或者将Restart改为always（但要小心无限重启循环）。

第四步：检查资源限制与看门狗

1. 资源耗尽：检查LimitNOFILE等限制是否设得太低，导致应用打开文件或创建线程失败。查看journalctl里是否有Too many open files之类的错误。
2. 看门狗超时：如果服务配置了WatchdogSec，它需要定期向systemd报平安（通过sd_notify）。如果应用没有实现这个功能，systemd会认为服务挂掉而杀死它。对于普通服务，通常不需要开启看门狗。

第五步：依赖与顺序问题检查[Unit]区块的After和Requires。如果依赖的服务（如network.target）在服务启动时还没完全就绪，虽然Wants允许你启动，但你的应用可能因为连不上网络而自行退出。可以考虑使用systemd更高级的依赖，如network-online.target（需要systemd-networkd-wait-online.service支持），它代表网络真正就绪。

5.3 自定义脚本与systemd的集成要点

有些人习惯写一个复杂的启动/停止脚本，然后在ExecStart里调用这个脚本。这可以，但要注意：

1. 脚本必须前台运行：systemd通过管理ExecStart启动的进程来监控服务。如果你的脚本后台化（&）了主进程然后自己退出，systemd会认为服务已经结束，可能会触发不必要的重启或直接标记为失败。确保你的脚本最后执行的是那个需要持续运行的前台命令。
2. 环境变量：在脚本里设置的环境变量，对于ExecStart直接调用的命令是可见的。但如果你在单元文件里也设置了Environment，它们会合并，单元文件的优先级可能更高，需要注意冲突。
3. 停止信号处理：如果你的脚本需要处理SIGTERM等停止信号来做清理工作，要确保信号能正确传递给脚本。在脚本开头用trap捕获信号是一种方法。

一个更“systemd风格”的做法是，尽量把逻辑写在单元文件里，而不是包装脚本里。单元文件的声明式配置更易于理解、维护和复用。

5.4 性能调优与小技巧

• 加快服务启动：对于不紧急的服务，可以设置Type=idle，让systemd在所有活跃任务完成后才启动它，避免在系统启动高峰期竞争资源。
• 内存与CPU限制：使用MemoryMax、CPUQuota等指令在单元文件中直接限制服务的资源使用，比用ulimit更直接和统一。
• 临时覆盖配置：不想修改原单元文件？可以创建覆盖目录：/etc/systemd/system/myapp.service.d/override.conf。在里面写新的配置片段（如[Service]下加一个Environment），执行systemctl daemon-reload后生效。原单元文件保持不变，便于升级。
• 调试模式：在ExecStart前加上/bin/sh -x，或者在Java命令前加上-Ddebug等调试参数，可以在日志中输出更详细的启动信息。生产环境记得去掉。

理解和管理systemd，是一个从抵触到接受，再到熟练运用的过程。它确实复杂，但提供的标准化、可观测性和控制力也是旧式init脚本无法比拟的。把它当成一个功能强大的框架，摸清它的脾气（配置规则），你就能让它可靠地托管你的所有服务，从简单的脚本到复杂的Java微服务集群。当你再看到“服务关闭”的问题时，第一反应不再是重启，而是systemctl status和journalctl，这说明你已经入门了。剩下的，就是在不断的实践中积累更多应对特定场景的经验，比如如何用systemd管理Docker容器，如何配置跨主机的服务依赖等等，那将是更深入的话题了。