Linux怎么使用systemctl管理服务

P粉602998670

发布时间：2025-09-10 08:03:01

615人浏览过

来源于php中文网

原创

systemctl是Linux中管理systemd服务的核心工具，提供统一命令集来启动、停止、重启、查看服务状态及设置开机自启，支持并行启动、依赖管理与Cgroups资源控制，相比SysVinit更高效；通过创建/etc/systemd/system/下的.service文件可自定义服务，包含[Unit]、[Service]、[Install]三部分，常用命令如start、stop、status、enable、journalctl -u查看日志，故障排查需检查依赖、配置路径、权限、端口占用等问题。

linux怎么使用systemctl管理服务

systemctl

是 Linux 系统中用于管理

systemd

服务的核心工具，它统一了服务、挂载点、套接字等多种系统资源的管理，让操作变得更直观和强大，可以说，它是现代 Linux 服务管理的基石。

解决方案

在使用 Linux 系统时，我们经常需要启动、停止、重启或查看各种后台服务。

systemctl

提供了一套统一且高效的命令集来处理这些任务。我个人觉得，掌握了这些基本操作，就能应对绝大多数的服务管理场景了。

最常用的命令包括：

启动服务: 当你需要一个服务立即运行起来时，比如你刚安装了一个新的 Web 服务器，就可以用
```
systemctl start [服务名]
```
。
```
sudo systemctl start nginx
```
停止服务: 如果某个服务出了问题，或者你暂时不需要它运行，
```
systemctl stop [服务名]
```
会派上用场。
```
sudo systemctl stop apache2
```
重启服务: 这大概是日常操作中最频繁的命令之一了，尤其是在修改了服务配置文件后。
```
systemctl restart [服务名]
```
会先停止服务，再重新启动。
```
sudo systemctl restart sshd
```
重新加载配置: 有些服务支持在不中断当前连接或操作的情况下，重新加载其配置文件。如果服务支持，
```
systemctl reload [服务名]
```
会比
```
restart
```
更优雅。
```
sudo systemctl reload nginx
```
查看服务状态: 这是诊断问题的第一步，也是最重要的一步。
```
systemctl status [服务名]
```
会显示服务的当前状态、最近的日志片段、进程ID等关键信息。
```
systemctl status mysql
```
设置开机自启动: 很多服务都需要在系统启动时自动运行。
```
systemctl enable [服务名]
```
会创建必要的符号链接，让服务在下次开机时自动启动。
```
sudo systemctl enable docker
```
禁止开机自启动: 如果你不再需要某个服务随系统启动，
```
systemctl disable [服务名]
```
可以取消它的开机自启动设置。
```
sudo systemctl disable cups
```
查看所有服务单元: 想看看系统里到底跑了哪些服务？
```
systemctl list-units --type=service
```
能列出所有正在运行或尝试运行的服务单元。
```
systemctl list-units --type=service
```
查看失败的服务: 有时候系统启动后，某些服务可能因为各种原因启动失败。
```
systemctl --failed
```
能快速帮你找出这些“问题儿童”。
```
systemctl --failed
```
查看服务日志: 当服务出现异常时，详细的日志是排查问题的关键。
```
journalctl -u [服务名]
```
可以查看该服务的所有日志，非常方便。
```
sudo journalctl -u nginx
```

systemctl与传统服务管理工具（如SysVinit）有何不同？

当我第一次接触

systemd

和

systemctl

时，我记得最大的感受就是它的“统一性”。在此之前，Linux 服务管理主要依赖于

SysVinit

或

Upstart

，它们各自有自己的一套逻辑，命令也比较分散。

systemctl

的出现，可以说彻底改变了这种局面。

systemd

的设计哲学是让所有系统资源，包括服务、挂载点、套接字、设备等等，都以“单元（unit）”的形式进行管理，这与

SysVinit

主要通过

/etc/init.d/

下的 shell 脚本来管理服务形成了鲜明对比。这种统一性带来了几个显著的优势：

并行启动能力:
```
SysVinit
```
在启动时是串行执行脚本的，一个服务启动完了才能轮到下一个。而
```
systemd
```
能够并行启动多个服务，大大缩短了系统的启动时间。我个人觉得，这是
```
systemd
```
最直观、最让人感到“爽”的改进之一。
按需启动与依赖管理:
```
systemd
```
对服务之间的依赖关系处理得更精妙。它可以做到按需启动，比如只有当某个服务被请求时才启动，从而节省系统资源。而
```
SysVinit
```
的依赖管理通常是基于运行级别（runlevel）和脚本中的简单判断。
Cgroups 的集成:
```
systemd
```
利用 Linux 内核的 Cgroups 功能，更好地隔离和管理服务进程。这意味着你可以更精确地控制每个服务能使用的资源，并且在服务异常时，能更彻底地清理其所有相关进程，避免“僵尸进程”的出现。
统一的日志管理:
```
systemd
```
引入了
```
journalctl
```
，将所有系统和服务的日志集中管理。这比
```
SysVinit
```
时代分散在
```
/var/log
```
下的各种日志文件要方便太多了。通过
```
journalctl
```
，你可以轻松地过滤、查看特定服务的日志，甚至进行实时跟踪。
更清晰的配置文件:
```
systemd
```
的服务单元文件（
```
.service
```
文件）结构化更强，用INI格式定义，可读性高，易于编写和理解。相比之下，
```
SysVinit
```
的 shell 脚本虽然灵活，但编写起来更复杂，也更容易出错。

总的来说，

systemctl

和

systemd

提供了一个更现代化、更高效、更统一的 Linux 服务管理框架，虽然初学者可能需要一点时间适应，但一旦掌握，你会发现它真的让很多系统管理工作变得简单和可靠。

如何创建和自定义自己的systemd服务单元？

有时候，我们需要运行一个自己编写的程序或脚本作为后台服务，并希望它能像系统自带的服务一样，通过

systemctl

来管理，甚至开机自启动。这时候，创建自定义的

systemd

服务单元就显得尤为重要了。这个过程其实并不复杂，但需要注意一些关键细节。

自定义服务单元文件通常放在

/etc/systemd/system/

目录下，文件以

.service

结尾，例如

my-app.service

。一个典型的

.service

文件包含三个主要部分：

[Unit]

、

[Service]

和

[Install]

。

我们来看一个简单的例子，假设你有一个 Python 脚本

/opt/my-app/app.py

，你想让它作为服务运行：

# /etc/systemd/system/my-app.service
[Unit]
Description=My Custom Python Application Service
After=network.target # 定义服务启动的顺序，表示在网络服务启动后才启动
Requires=mysql.service # 如果你的应用依赖MySQL，可以加上这个

[Service]
Type=simple # 最常见的类型，表示ExecStart是主进程
ExecStart=/usr/bin/python3 /opt/my-app/app.py # 服务的启动命令
WorkingDirectory=/opt/my-app/ # 设置工作目录
Restart=on-failure # 当服务意外退出时自动重启
User=myuser # 以哪个用户身份运行服务，提高安全性
Group=myuser # 以哪个用户组身份运行服务

[Install]
WantedBy=multi-user.target # 定义服务在哪个目标下启用（开机自启动）

这里面有几个关键参数：

[Unit]
部分:
- ```
Description
```
  : 对服务的简短描述。
- ```
After
```
  /
```
Requires
```
  : 定义服务之间的依赖关系和启动顺序。
```
After
```
  表示在该服务之后启动，
```
Requires
```
  表示依赖该服务，如果依赖的服务启动失败，当前服务也不会启动。
[Service]
部分:
- ```
Type
```
  : 定义服务的启动类型。
```
simple
```
  是最常见的，表示
```
ExecStart
```
  里的命令就是主进程。其他还有
```
forking
```
  (服务启动后会fork出一个子进程，父进程退出)、
```
oneshot
```
  (一次性任务，完成后退出) 等。我第一次写服务文件时，对
```
Type
```
  的选择确实纠结了一会儿，因为不同的类型会影响
```
systemd
```
  如何判断服务是否“成功启动”。
- ```
ExecStart
```
  : 启动服务的命令。这里一定要用绝对路径。
- ```
ExecStop
```
  : 停止服务的命令（可选，
```
systemd
```
  默认会发送 SIGTERM 信号）。
- ```
ExecReload
```
  : 重新加载配置的命令（可选）。
- ```
WorkingDirectory
```
  : 服务的工作目录。
- ```
restart
```
  : 定义服务退出时的重启策略。
```
on-failure
```
  是一个不错的选择，它会在服务非正常退出时自动重启。
```
always
```
  则是不管什么原因退出都会重启。
- ```
User
```
  /
```
Group
```
  : 指定服务运行的用户和用户组，这对于安全性非常重要，避免以 root 权限运行不必要的服务。
[Install]
部分:
- ```
WantedBy
```
  : 定义服务在哪个“目标（target）”下启用。
```
multi-user.target
```
  表示在多用户模式下启用，也就是我们平时登录的命令行环境。
```
graphical.target
```
  则是图形界面环境。

创建完

.service

文件后，需要执行以下命令来让

systemd

识别并管理你的服务：

重新加载 systemd 配置:
```
sudo systemctl daemon-reload
```
这一步是告诉
```
systemd
```
有新的或修改过的服务单元文件。
设置开机自启动:
```
sudo systemctl enable my-app.service
```
立即启动服务:
```
sudo systemctl start my-app.service
```
查看服务状态:
```
systemctl status my-app.service
```

通过这些步骤，你的自定义应用就能像一个专业的系统服务一样被

systemctl

管理起来了。我的经验是，确保

ExecStart

中的命令是可执行的，并且路径正确，这是最容易出错的地方。

systemctl服务常见故障排除与日志查看技巧

在实际运维中，服务出问题是家常便饭。

systemctl

提供了一套非常强大的工具来帮助我们诊断和解决问题。我个人觉得，掌握了这些故障排除和日志查看的技巧，能让你在面对服务异常时，少走很多弯路。

SmartB2B行业电子商务

SmartB2B 是一款基于PHP、MySQL、Smarty的B2B行业电子商务网站管理系统，系统提供了供求模型、企业模型、产品模型、人才招聘模型、资讯模型等模块，适用于想在行业里取得领先地位的企业快速假设B2B网站，可以运行于Linux与Windows等多重服务器环境，安装方便，使用灵活。系统使用当前流行的PHP语言开发，以MySQL为数据库，采用B/S架构，MVC模式开发。融入了模型化、模板

下载

1. 初步诊断：

systemctl status

当一个服务表现异常或者无法启动时，我的第一反应总是

systemctl status [服务名]

。这个命令会给你一个快速的概览：

systemctl status nginx

它会告诉你服务是否正在运行、最近的日志片段、进程ID、内存占用等信息。如果服务启动失败，这里通常会显示红色的错误信息，并给出最近几行的日志，这往往能提供初步的线索。

2. 深入挖掘：

journalctl

如果

status

命令给出的信息不足以解决问题，那么就该请出

journalctl

了。

journalctl

是

systemd

的统一日志管理工具，它能查看所有系统和服务的日志。

查看特定服务的完整日志:
```
sudo journalctl -u [服务名]
```
这会显示该服务自启动以来的所有日志。
实时跟踪日志:
```
sudo journalctl -u [服务名] -f
```
```
-f
```
(follow) 选项非常有用，它会实时显示服务生成的新日志，就像
```
tail -f
```
一样，对于调试正在运行的服务或观察启动过程中的错误非常有帮助。

查看特定时间段的日志:

sudo journalctl -u [服务名] --since "2 hours ago" --until "now"
sudo journalctl -u [服务名] --since "2023-01-01 10:00:00"

当你需要回顾某个时间点发生的问题时，这个功能简直是救星。

只查看错误或警告日志:
```
sudo journalctl -u [服务名] -p err
sudo journalctl -u [服务名] -p warning
```
```
-p
```
选项可以按优先级过滤日志，快速定位关键问题。我特别喜欢用
```
-p err
```
，能把那些无关紧要的调试信息都过滤掉，直击问题核心。
结合
-x
选项获取更多上下文:
```
sudo journalctl -xeu [服务名]
```
```
-x
```
选项可以提供一些额外的解释和建议，这在某些情况下能帮你省去不少搜索时间。我经常用这个组合，因为它能在关键时刻给出意想不到的提示。

3. 常见故障排查点：

依赖问题: 服务可能因为其依赖的服务没有启动而失败。你可以使用
```
systemctl list-dependencies [服务名]
```
来查看服务的所有依赖项。确保所有前置服务都已正常运行。
配置文件错误:
```
.service
```
文件或服务自身的配置文件中可能存在语法错误、路径错误或权限问题。
- 使用
```
systemctl cat [服务名]
```
  可以查看实际生效的服务单元文件内容，包括任何覆盖文件。
- 仔细检查
```
ExecStart
```
  中的命令是否正确，路径是否是绝对路径，以及脚本是否有执行权限 (
```
chmod +x
```
  )。
权限问题: 服务通常以非 root 用户运行，确保该用户对服务所需的文件、目录有正确的读写执行权限。例如，Web 服务器可能无法写入日志文件或访问网站根目录。
资源限制: 检查
```
.service
```
文件中是否有
```
LimitNOFILE
```
(最大文件描述符数)、
```
LimitNPROC
```
(最大进程数) 等参数。如果这些限制过低，服务在高负载下可能会崩溃。
端口占用: 如果服务需要监听某个端口，而该端口已经被其他进程占用，服务将无法启动。可以使用
```
netstat -tulnp
```
或
```
ss -tulnp
```
来检查端口占用情况。