提升 Linux 生产力的 5 个 systemctl 命令

Linux 系统几乎依赖后台服务来完成所有任务：SSH 访问、网络、日志记录、Web 服务器、数据库、计划任务和桌面登录屏幕。当其中一个服务出现问题时，systemctl 通常是您首先使用的工具。

systemctl 是 systemd 的主要命令行界面，systemd 是许多主流 Linux 发行版使用的服务管理器。您无需记住每个子命令即可高效工作。在日常工作中，一小部分命令即可覆盖大多数服务检查、重启、启动配置更改和单元文件更新。

了解 Systemd 和 systemctl

在深入命令之前，让我们简要回顾一下 systemd 和 systemctl。systemd 负责初始化系统、管理服务、处理进程等。它取代了 SysVinit 和 Upstart 等旧的 init 系统，提供更快的启动时间、并行服务启动和更强大的依赖关系管理。systemctl 是您进入 systemd 世界的窗口，允许您控制和查询服务、单元和目标的狀態。

在 systemd 术语中，“单元”指的是 systemd 知道如何管理的任何资源。服务（.service）、挂载点（.mount）、设备（.device）、套接字（.socket）和目标（.target）是常见的单元类型。在本文中，我们将主要关注服务单元，它们代表由 systemd 管理的守护进程。

提升生产力的 5 个 systemctl 命令

以下是五个 systemctl 命令，它们将显著提高您管理和监控 Linux 系统服务的能力。

1. systemctl status [SERVICE_NAME]

目的：此命令是监控任何服务健康状态和活动的第一道防线。它提供详细信息，包括服务是否正在运行、最近是否停止、是否启用自动启动，甚至包括最后几条日志条目。

为何提高生产力：快速诊断问题，确认服务启动/关闭，无需手动翻阅日志文件即可获取服务状态的快照。

示例： 要检查 Apache Web 服务器（在某些发行版上为 httpd.service，在 Debian/Ubuntu 等发行版上为 apache2.service）的状态：

systemctl status apache2.service

输出解释（示例）：

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-26 10:00:00 UTC; 1min 2s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 1234 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 1239 (apache2)
      Tasks: 6 (limit: 4639)
     Memory: 21.6M
        CPU: 184ms
     CGroup: /system.slice/apache2.service
             ├─1239 /usr/sbin/apache2 -k start
             ├─1240 /usr/sbin/apache2 -k start
             └─1241 /usr/sbin/apache2 -k start

Oct 26 10:00:00 servername systemd[1]: Starting The Apache HTTP Server...
Oct 26 10:00:00 servername systemd[1]: Started The Apache HTTP Server.

此输出告诉您：

• Loaded：单元文件的位置以及是否已启用开机启动。
• Active：当前状态（例如 active (running)、inactive (dead)、failed）。
• 来自 journalctl 的最近日志条目。

提示：按 q 退出状态视图。

status 中的两个细节很容易被忽略。首先，Loaded: 告诉您单元文件是否存在以及是否已启用开机启动。服务可以是 active (running) 但仍然是 disabled；这意味着它是手动启动或由其他依赖项启动的，但不一定会在下次启动时启动。其次，最后的日志行只是预览。如果有用的错误信息滚动了，请使用 journalctl -u apache2.service 而不是试图从 status 中获取所有信息。

对于脚本和监控检查，请优先使用机器友好的命令：

systemctl is-active --quiet apache2.service
systemctl is-enabled apache2.service

is-active --quiet 在服务活动时以状态码 0 退出。这在小型健康检查中很有用：

if ! systemctl is-active --quiet apache2.service; then
  echo "apache2 is not running"
fi

2. systemctl start|stop|restart [SERVICE_NAME]

目的：这些命令让您直接控制服务的运行时生命周期。

• start：启动服务。
• stop：停止正在运行的服务。
• restart：停止然后启动服务（用于应用配置更改）。

为何提高生产力：对于基本服务维护、故障排除和应用配置更新至关重要。无需重启整个系统，您可以精确控制单个服务。

示例： 停止 Apache Web 服务器：

sudo systemctl stop apache2.service

再次启动：

sudo systemctl start apache2.service

修改配置文件后重启：

sudo systemctl restart apache2.service

警告：这些命令通常需要 sudo 权限，因为它们会影响系统范围的服务。始终确保您针对的是正确的服务，以避免意外中断。

在生产服务上谨慎使用 restart。它会停止进程并重新启动，除非应用程序能很好地处理优雅关闭，否则可能会断开活动连接。如果单元支持重新加载，在仅更改配置后通常更好：

sudo systemctl reload nginx.service

并非所有服务都支持重新加载。在假设支持之前，请检查单元定义：

systemctl cat nginx.service | grep ExecReload

如果没有 ExecReload=，systemctl reload 通常会失败。在这种情况下，您要么重启服务，要么使用特定于应用程序的重新加载命令。

3. systemctl enable|disable [SERVICE_NAME]

目的：这些命令管理服务是否在系统启动时自动启动。

• enable：配置服务在启动时自动启动。这会从相应的 systemd 目标目录创建指向服务单元文件的符号链接。
• disable：通过删除符号链接来阻止服务在启动时自动启动。

为何提高生产力：控制资源使用，优化启动时间，并确保关键服务始终可用（或阻止不必要的服务运行）。

示例： 确保 Apache 在每次系统启动时启动：

sudo systemctl enable apache2.service

阻止不必要的服务（例如，如果您不使用打印，则阻止 cups.service）在启动时启动：

sudo systemctl disable cups.service

最佳实践：禁用您不需要的服务，但首先验证哪些服务依赖于它们。在笔记本电脑上，禁用蓝牙或打印可能无害。在服务器上，禁用网络、存储或身份验证服务而不检查依赖关系可能会导致锁定或启动失败。

请记住，enable 和 disable 仅影响启动行为。它们不会立即启动或停止服务。如果您希望同时执行这两个操作，请使用：

sudo systemctl enable --now apache2.service
sudo systemctl disable --now cups.service

--now 很有用，因为它消除了一个常见错误：启用服务并假设它已经在运行。

4. systemctl list-unit-files --type=service

目的：此命令列出系统已知的所有 systemd 服务单元文件及其 enabled 或 disabled 状态。这对于了解系统上配置了哪些服务非常有用。

为何提高生产力：帮助您发现已安装的服务，识别不必要的服务，并审计系统的启动配置。这是系统侦察和清理的强大工具。

示例：

systemctl list-unit-files --type=service

部分输出（示例）：

UNIT FILE                                  STATE
acpid.service                              enabled
aptd-auto-update.service                   static
apt-daily.service                          static
apache2.service                            enabled
avahi-daemon.service                       enabled
bluetooth.service                          enabled
cups.service                               enabled
... (many more services)

78 unit files listed.

提示：STATE 列指示服务是否配置为在启动时启动（enabled）、明确阻止（disabled）或 static（无法通过 systemctl enable/disable 直接启用/禁用，通常是依赖项或内部 systemd 单元）。

过滤：您可以将输出通过管道传递给 grep 以查找特定服务：

systemctl list-unit-files --type=service | grep ssh

当您关心正在运行的服务而不是已安装的单元文件时，请改用 list-units：

systemctl list-units --type=service --state=running
systemctl list-units --type=service --state=failed

这种区别在清理时很重要。list-unit-files 告诉您 systemd 知道如何启动什么。list-units 告诉您 systemd 在当前运行时状态中加载了什么。

5. systemctl daemon-reload

目的：修改 systemd 单元文件后（例如，在 /etc/systemd/system/ 中创建新服务文件或编辑现有文件），systemd 不会自动识别这些更改。systemctl daemon-reload 指示 systemd 重新扫描所有单元文件并重新加载其配置。

为何提高生产力：避免仅为了应用服务配置更改而完全重启系统。对于经常修改服务配置的开发人员和管理员来说至关重要。

示例： 假设您为自定义应用程序创建了一个新的服务单元文件 mywebapp.service。

1. 创建 /etc/systemd/system/mywebapp.service。

2. 重新加载 systemd 的配置：

sudo systemctl daemon-reload ```

1. 现在，systemd 知道 mywebapp.service，您可以 start、enable、status 它：

sudo systemctl start mywebapp.service sudo systemctl enable mywebapp.service systemctl status mywebapp.service ```

重要：daemon-reload 仅重新加载单元定义。如果服务已经在运行，对其单元文件的更改在服务重启（systemctl restart [SERVICE_NAME]）之前不会生效。

简单的日常工作流程

当我登录到一台不熟悉的服务器时，我通常按以下顺序操作：

systemctl status sshd.service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service | grep enabled
systemctl get-default

这可以快速了解主机：远程访问是否正常，是否有任何单元失败，配置了哪些服务在启动时启动，以及机器是否期望启动到服务器风格或图形目标。

对于服务更改，工作流程同样简短：

sudo systemctl edit myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

该序列使更改可见，重新加载 systemd 的单元缓存，仅重启受影响的服务，并在您离开之前检查日志。它避免了许多可避免的重启和猜测。

一些有用的变体

一旦核心命令变得自然，添加一些变体可以在不改变基本工作流程的情况下节省时间。

仅查看失败的单元：

systemctl --failed

这是重启后最快的检查之一。如果软件包升级更改了单元、挂载超时或自定义服务在启动期间崩溃，通常会在用户报告问题之前显示在这里。

检查 systemd 加载的确切单元内容：

systemctl cat docker.service

这很重要，因为您记得编辑的文件可能不是全部。/usr/lib/systemd/system/ 中的软件包单元可以通过 /etc/systemd/system/docker.service.d/ 下的一个或多个插入文件进行修改。systemctl cat 显示组合视图，这样您就不会调试错误的文件。

查看服务为何在启动时启动：

systemctl list-dependencies multi-user.target
systemctl list-dependencies graphical.target

当有人问“为什么这个在运行？”时，这很有帮助。服务可能直接启用、由目标拉入、通过套接字激活或由另一个单元启动。启动行为通常是一个依赖关系问题，而不仅仅是启用或禁用的问题。

检查最近的日志而不打开分页器：

journalctl -u sshd.service -n 50 --no-pager

systemctl status 提供一个小型日志预览，但 journalctl 让您控制时间范围、启动、行数和输出格式。例如：

journalctl -u sshd.service --since "today" --no-pager
journalctl -u sshd.service -b -1 --no-pager

第二个命令检查上一次启动，这在崩溃或意外重启后很有用。

使用最长的 systemctl 命令没有奖励。生产力来自于知道哪个小命令能回答当前问题：它是否在运行，是否应该在启动时启动，什么失败了，什么改变了，以及 systemd 是否重新加载了我编辑的定义？

最后一个习惯在共享机器上很有帮助：留下您更改的证据。如果您禁用了某个服务，请在您的工单、运行手册或更改日志中注明原因。六个月后，有人可能会看到 disabled 并认为这是一个错误。命令很简单：

sudo systemctl disable --now old-worker.service

操作上下文是人们丢失的部分。它被定时器取代了吗？它是否导致了重复作业？它是否仅在迁移期间需要？systemctl 可以显示状态，但无法解释意图。在更改旁边添加简短注释可以防止下一个人撤销一个好的决定。