systemctl是Linux中管理systemd服务的核心工具，提供统一命令集来启动、停止、重启、查看服务状态及设置开机自启，支持并行启动、依赖管理与Cgroups资源控制，相比SysVinit更高效；通过创建/etc/systemd/system/下的.service文件可自定义服务，包含[Unit]、[Service]、[Install]三部分，常用命令如start、stop、status、enable、journalctl -u查看日志，故障排查需检查依赖、配置路径、权限、端口占用等问题。
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 ServiceAfter=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
提供了一套非常强大的工具来帮助我们诊断和解决问题。我个人觉得，掌握了这些故障排除和日志查看的技巧，能让你在面对服务异常时，少走很多弯路。
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 errsudo 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
来检查端口占用情况。
我的经验是，很多时候一个服务启动不了，最后发现竟然是
ExecStart
里的脚本没有执行权限，或者配置文件路径写错了。这些看似低级的错误，通过
systemctl status
和
journalctl
都能清晰地告诉我。耐心阅读日志，往往是解决问题的金钥匙。
以上就是Linux怎么使用systemctl管理服务的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/204916.html
微信扫一扫 
支付宝扫一扫 
