如何使用 Systemctl 管理 systemd 单元和服务？

Systemd 是大多数现代 Linux 发行版中默认使用的系统与服务管理器。它负责在启动过程中加载系统并管理运行中的服务。它接管进程 ID 1（PID 1），这意味着它是 Linux 内核启动的第一个用户空间进程，并将持续运行直至系统关闭。

与 SysV 等传统 init 系统不同，systemd 采用单元（unit）来定义和管理系统资源。每个单元通过配置文件（即单元文件）描述，该文件告知 systemd 如何管理该资源。单元可代表服务、设备、挂载点，甚至可表示称为目标（target）的单元组，这些目标在启动过程中充当检查点。

与systemd交互的核心工具是systemctl，它支持启动、停止、重启、启用、禁用服务及其他单元，并可查看其运行状态。

要查看与systemd及其服务相关的系统日志，可使用journalctl命令，该命令能显示systemd日志中的消息。

本指南将深入探讨如何使用systemctl命令——这款管理Linux初始化系统的工具。同时将探讨如何控制服务、查看状态、调整系统状态以及与配置文件交互。

需特别说明：尽管systemd是众多主流Linux发行版的默认初始化系统，但并非所有发行版都采用它。若遇到“bash: systemctl: command not found”等错误，说明您的系统可能依赖其他初始化系统，systemctl不可用。

使用 systemctl 管理服务

初始化系统的核心职责之一，是在 Linux 内核加载完成后启动关键组件。这些组件通常称为用户空间进程，包含维持系统平稳运行的各类服务和守护进程。初始化系统在系统运行期间也持续承担着控制这些服务的重要作用。

在 systemd 中，其管理的核心元素称为单元。单元通过名为单元文件的配置文件定义，每个文件指定特定资源的处理方式。资源类型由文件扩展名（后缀）标识。

针对服务管理，systemd使用服务单元，其文件名以.service结尾。但使用systemctl命令时通常可省略.service扩展名——systemd会自动识别为服务对象。

使用 systemctl 启动和停止服务

手动启动服务并触发单元文件中定义的操作时，请使用以下命令：

$ sudo systemctl start application.service

由于 systemd 能推断操作对象为服务，也可执行：

$ sudo systemctl start application

两种格式均有效，但为保持清晰度，本指南在处理服务单元时将始终包含 .service 后缀。

停止正在运行的服务命令如下：

$ sudo systemctl stop application.service

系统ctl重启服务

完全重启服务（即停止后重新启动）请使用：

$ sudo systemctl restart application.service

部分服务支持无需重启即可重新加载配置文件。执行配置文件重新加载请运行：

$ sudo systemctl reload application.service

若不确定服务是否支持重载，可使用更安全的组合命令：

$ sudo systemctl reload-or-restart application.service

该命令会尝试重载配置（若支持），否则直接重启服务。

使用 systemctl 启用和禁用服务

前文介绍的命令用于管理当前会话中的服务，若需使服务在系统启动时自动运行，则需启用该服务。

系统ctl 启用服务（systemd enable service）

配置服务在启动时运行，请执行：

$ sudo systemctl enable application.service

该命令会在服务文件（通常位于 /lib/systemd/system/ 或 /etc/systemd/system/）与 systemd 启动时扫描的自动启动服务目录（常见形式如 /etc/systemd/system/some_target.target.wants）之间创建符号链接。

systemctl 禁用服务

要禁止服务在启动时运行，请使用：

$ sudo systemctl disable application.service

此操作将删除符号链接，systemd 便不再自动启动该服务。

请注意：启用服务仅将其加入启动计划，不会立即在当前会话中启动。若需立即启用并启动服务，需同时执行 enable 和 start 命令。

检查服务状态

要检查服务是否运行并查看基本信息，可使用：

$ systemctl status application.service

该命令将显示服务状态（是否活动）、运行时长及最新日志条目等详细信息。

例如检查docker状态时，可能看到如下输出：

此摘要可快速评估服务健康状况，并突出显示存在的问题。

检查特定服务状态

若仅需确认服务是否运行，可使用：

$ systemctl is-active application.service

该命令返回“active”或“inactive”状态，同时输出退出代码——0表示服务处于活动状态，此信息在脚本自动化检测时尤为实用。

要确认服务是否设置为开机启动，请运行：

$ systemctl is-enabled 应用程序.service

返回结果为 enabled 或 disabled，同上文，命令退出代码可指示结果状态。

最后，若需检查服务是否因启动或运行错误而失败，请使用：

$ systemctl is-failed 应用程序.service

若出现异常则返回 failed，正常运行时返回 active。若服务被主动停止，可能显示 inactive 或 unknown。退出代码 0 表示失败，1 则表示其他状态。

查看系统整体状态（systemctl list services）

前文介绍了管理单个服务的命令，若需全面了解系统状态，systemctl 还提供相应命令。

查看活动单元

要查看当前运行中的单元，可使用 list-units 命令：

$ systemctl list-units

这将显示所有由 systemd 实时管理的单元。输出格式如下：

各列含义说明：

• UNIT：单元的实际名称
• LOAD：systemd 是否成功读取并加载单元文件至内存
• ACTIVE：表示单元是否正常运行的通用状态。
• SUB：更详细的底层状态，具体取决于单元类型。
• DESCRIPTION：简要说明单元功能的描述。

默认情况下，此命令仅显示当前活动的单元。实际上，不带附加参数运行 systemctl 也会产生相同输出。

$ systemctl

显示所有单元（活动与非活动）

若需查看systemd曾尝试加载或当前内存中存在的全部单元（包括未运行状态），可添加--all参数：

$ systemctl list-units --all

此命令将包含已运行后停止的单元，甚至包含systemd尝试加载但未找到的单元。

若需缩小范围，可按特定状态过滤。例如仅查看非活动单元：

$ systemctl list-units --all --state=inactive

也可按类型筛选。例如仅显示服务：

$ systemctl list-units --type=service

列出所有单元文件（无论是否加载）

上述命令仅显示 systemd 曾交互过的单元（包括已加载或尝试运行的单元）。要查看系统中所有可用单元文件（无论 systemd 是否接触过），请使用：

$ systemctl list-unit-files

该命令将列出 systemd 目录中所有单元定义文件，包括 systemd 从未尝试加载的文件。输出格式如下：

包含两列信息：

• UNIT FILE：单元文件名称
• STATE：单元文件状态（启用/禁用/静态/屏蔽）

状态含义说明：

• enabled：该单元设置为按需自动启动
• disabled：该单元不会自动启动，但可手动启动
• 静态：该单元未包含“install”配置段，表示其不支持直接启用，而是通过依赖关系触发。
• 屏蔽：该单元已被显式禁用，在任何情况下均无法启动（详见下节说明）。

此命令可获取系统中所有单元的完整清单，无论systemd是否实际使用过它们。

如何操作systemd单元？

目前我们主要关注服务启动/停止操作，以及查看systemd单元及其文件的基本信息。但systemd还提供多项命令可深入解析单元信息并实现精准控制。

查看单元文件

要查看systemd已加载到内存中的实际单元文件，可使用cat命令（该功能自systemd 209版本引入）。例如查看apache2服务的单元文件：

$ systemctl cat apache2.service

该命令将输出systemd当前识别的单元文件内容。当文件近期被修改或应用了自定义覆盖时，此功能尤为实用。显示内容反映了systemd所见文件的实时状态。

检查单元依赖关系

若需查看特定服务依赖的其他单元，list-dependencies命令可提供帮助。例如要查看 sshd 服务的依赖关系，请执行：

$ systemctl list-dependencies sshd.service

该命令将以树状结构展示 sshd.service 直接依赖或可选依赖的单元。systemd 目标（代表系统状态的特殊单元组合）也会显示其内部依赖关系。

若需显示所有递归依赖关系，可添加 --all 选项：

$ systemctl list-dependencies --all sshd.service

您也可反向查询依赖关系：通过添加 --reverse 标志可查看哪些单元依赖于指定服务：

systemctl list-dependencies --reverse sshd.service

若需检查哪些单元被配置为在目标服务之前或之后启动，可使用以下选项：

systemctl list-dependencies sshd.service --before

systemctl list-dependencies sshd.service --after

查看单元属性

每个单元都包含控制 systemd 处理方式的多种属性。要查看特定单元的全部属性，请使用 show 命令。该命令以键值对格式呈现详细单元数据：

systemctl show sshd.service

此命令将输出数十项属性，包括该单元所属的目标、与其他单元的冲突情况及其依赖关系。

若需查看特定属性，可使用 -p 选项进行过滤。例如检查 sshd 服务与哪些单元存在冲突：

systemctl show sshd.service -p Conflicts

屏蔽与解除屏蔽单元

有时仅停止或禁用服务尚不足够——您可能需要彻底阻止其在任何情况下启动。此时便需使用屏蔽功能。当单元被屏蔽时，systemd 会将其链接至 /dev/null，从而有效阻止手动或自动启动。

屏蔽单元命令：

$ sudo systemctl mask apache2.service

执行后检查所有单元文件，可见 apache2.service 被标记为“被屏蔽”：

$ systemctl list-unit-files

若尝试启动被屏蔽的服务，systemd 将拒绝并显示错误：

$ sudo systemctl start apache2.service

要恢复服务启动能力，请执行：

$ sudo systemctl unmask apache2.service

此操作将解除屏蔽状态，使单元恢复常规状态，可像其他服务一样重新启动或启用。

如何使用 systemctl 编辑单元文件？

虽然单元文件的精确结构和语法超出本指南范围，但 systemd 提供了内置工具供您直接进行修改。这些编辑功能自 systemd 218 版本起引入。

通过 systemctl 编辑

edit命令通过简洁界面实现单元文件修改。默认情况下，该命令会为待修改单元创建空白覆盖文件。例如创建nginx.service的覆盖文件：

$ sudo systemctl edit nginx.service

此操作将在/etc/systemd/system目录下创建以单元名加.d结尾的子目录（如nginx.service.d）。systemd 会在该目录下放置名为 override.conf 的文件，您可在其中添加自定义配置。

服务启动时，systemd 会将此覆盖文件与主单元文件合并，并优先应用覆盖文件中的设置。这使得无需直接编辑原始文件即可轻松调整特定选项。

编辑完整单元文件

若需修改完整单元文件而非创建小范围覆盖，可使用 --full 选项：

$ sudo systemctl edit --full nginx.service

此命令将当前完整文件加载至编辑器，便于进行全面修改。保存并关闭编辑器后，systemd 会将修改后的文件保存至 /etc/systemd/system 目录，该文件将优先于 /lib/systemd/system 中的默认文件生效。

撤销自定义修改

若需撤销修改，只需删除覆盖目录或自定义单元文件本身。

删除覆盖目录：

$ sudo rm -r /etc/systemd/system/nginx.service.d

删除完整自定义单元文件：

$ sudo rm /etc/systemd/system/nginx.service

删除文件后需重新加载 systemd 以使其忽略已删除文件并恢复使用原始系统单元文件：

sudo systemctl daemon-reload

此操作可确保 systemd 不再查找或应用您已删除的修改。

通过目标管理系统状态

在systemd中，目标代表特定系统状态，类似于传统初始化系统的运行级别。这些目标以特殊单元文件形式定义（后缀为.target），通过组合其他单元实现预期状态。

默认目标（启动目标）

系统启动时进入默认目标，该目标决定启动后的系统状态。可通过以下命令查看当前默认目标：

$ systemctl get-default

若需更改默认目标（例如切换至图形桌面环境），请执行：

$ sudo systemctl set-default graphical.target

目标列表与查看

查看系统所有可用目标：

$ systemctl list-unit-files --type=target

仅查看当前活动目标：

$ systemctl list-units --type=target

目标切换（隔离）

可通过 isolate 命令将系统切换至不同目标，停止所有无关服务并仅启动新目标所需的服务。

例如从图形桌面环境切换至纯命令行环境：

$ sudo systemctl isolate multi-user.target

隔离前建议检查目标依赖的服务：

$ systemctl list-dependencies multi-user.target

此操作可避免误停关键服务。

系统事件快捷命令

Systemd 提供专属快捷命令处理关机、重启或进入救援模式等核心系统事件。这些命令会触发相应目标并通知所有登录用户，形成额外的沟通机制。

进入救援模式（单用户模式）可执行：

$ sudo systemctl rescue

此操作与隔离 rescue.target 效果相似，但额外具备通知当前用户的优势。

停止系统（终止所有进程但不关机）：

$ sudo systemctl halt

执行完整系统关机：

$ sudo systemctl poweroff

重启机器：

$ sudo systemctl reboot

多数Linux系统同时提供直接关联systemd的传统命令，因此通常只需输入：

$ sudo reboot

这些命令与systemd无缝集成，确保系统事件的规范通信与规范处理。

利用systemd强化服务安全性

保障systemd服务安全是防范攻击、未授权访问及意外损坏的关键步骤。以下是通过systemd强化服务的简化方案：

1. 理解服务单元文件

每个由systemd管理的服务都对应一个单元文件，该文件定义了服务的运行方式，包括启动流程、访问权限和资源限制。这些文件通常存储在/etc/systemd/system/目录下，可通过定制提升安全性。

2. 限制服务权限

• 以非root用户运行：为每个服务分配专属用户和组，避免以root身份运行。这能降低服务遭入侵时的风险。

3. 运用系统内置安全选项

• 隔离临时目录：启用PrivateTmp使服务拥有独立临时空间，防止跨服务数据泄露。
• 限制系统访问：设置ProtectSystem限制服务可访问的文件系统范围，使用ProtectHome阻止访问用户主目录。
• 控制目录访问：通过ReadOnlyPaths标记只读目录，并用ReadWritePaths限定服务可写入数据的位置。

4. 设置资源限制

• 限制CPU和内存使用：使用CPUQuota限制服务CPU占用上限，MemoryLimit限制内存消耗上限。此举可防止因故意操作或程序漏洞导致的资源过度消耗。

5. 管理网络访问

• 控制网络暴露范围：使用 RestrictAddressFamilies 限制服务可使用的地址族（例如禁用 AF_INET 以防止非必要的网络访问）。
• 若服务需要通信，可通过 IPAddressAllow 和 IPAddressDeny 创建网络访问规则。

6. 文件所有权与权限

• 确保正确文件权限：服务使用的文件和目录应具备正确所有权（通过 chown 设置）及严格权限（通过 chmod 设置）。仅必要用户应拥有配置文件、日志和数据的写入权限。

7. 保持更新并监控日志

• 定期应用更新：保持系统及服务软件更新以获取最新安全补丁。
• 监控服务活动： 使用 journalctl 检查服务日志中的错误、可疑活动或安全相关信息。

总结

本文介绍了 systemctl 命令的使用方法。systemctl 是 systemd 环境中管理服务与系统状态的核心工具，作为与系统核心进程交互的主要接口。此外，systemd 还包含其他辅助工具：journalctl 用于查看日志，loginctl 用于管理用户会话。掌握这些关联工具将助您更高效地管理系统。

您的业务是否已突破VPS主机的承载极限？立即升级至BlueServers的专用服务器，体验更强劲的性能！

• 完全可定制，随业务需求灵活扩展
• 专用环境中实现完整服务器控制
• 为成长中的业务提供无限流量支持

让您的托管服务更上一层楼——立即探索BlueServers专用服务器！