systemctl是Linux下systemd系统的服务管理命令，统一管理服务生命周期。通过start、stop、restart、reload控制服务启停，enable/disable设置开机自启，status查看状态，配合journalctl排查日志。systemd优势在于统一接口、并行启动、按需激活、依赖管理、cgroups资源隔离和集中日志。创建自定义服务需编写.service文件，包含[Unit]、[Service]、[Install]三部分，设置描述、启动命令、用户权限、重启策略等，并执行daemon-reload加载配置。排查问题用status和journalctl -xeu查看详细日志，检查路径、权限、环境变量和Type类型匹配。Target替代传统运行级别，如multi-user.target、graphical.target，通过get-default查看默认目标，isolate切换目标，set-default设置默认。list-units和list-unit-files列出所有单元及其状态，show查看单元属性，list-dependencies展示依赖关系。masked状态可彻底禁用服务，防止启动。
说起Linux下的服务管理，现在的主流选择无疑是
systemctl
。无论是想让一个应用跑起来、停下来，还是设置它随系统启动，这个命令都提供了统一且高效的接口，它是systemd系统和服务的管理器，几乎涵盖了所有服务生命周期的操作。
对于一个Linux系统管理员或者开发者来说，掌握
systemctl
几乎是必备技能。它取代了过去那些分散的
service
命令和
/etc/init.d/
脚本，将系统中的各类资源（服务、挂载点、设备等）都统一抽象为“单元”（unit），极大地简化了操作。
核心操作示例：
启动服务：
systemctl start
比如，要启动Nginx Web服务器，就用
systemctl start nginx
。这就像给一个程序发了个“跑起来”的信号。停止服务：
systemctl stop
要让它停下来，自然是
systemctl stop nginx
。简单直接，立即生效。重启服务：
systemctl restart
如果修改了配置，通常需要重启服务来加载新设置：
systemctl restart nginx
。它会先停再启，确保配置刷新。重新加载配置（不中断服务）：
systemctl reload
有些服务支持不中断连接的情况下重新加载配置，这比重启更优雅：
systemctl reload nginx
。但不是所有服务都支持这种模式，如果不支持，它会回退到重启操作。查看服务状态：
systemctl status
查看服务的当前状态，比如是否正在运行、有没有报错，这是我最常用的命令之一：
systemctl status nginx
。它会显示服务的运行日志片段、PID等信息，非常有助于快速诊断问题。设置开机自启：
systemctl enable
想让服务在系统启动时自动运行？
systemctl enable nginx
。这会在
/etc/systemd/system/multi-user.target.wants/
下创建一个符号链接，指向服务的
.service
文件。禁用开机自启：
systemctl disable
反之，不希望它开机自启，就用
systemctl disable nginx
。检查是否开机自启：
systemctl is-enabled
快速检查服务是否已启用开机自启，返回
enabled
或
disabled
。列出所有服务单元：
systemctl list-units --type=service
查看系统上所有已加载的服务单元及其状态。查看所有服务单元文件状态：
systemctl list-unit-files --type=service
这会显示所有服务单元文件的默认状态（enabled, disabled, static等）。
有时候，你会发现服务启动失败，
systemctl status
给出的信息可能不够详细。这时候，
journalctl -xeu
往往能提供更深层次的错误日志，这是我排查问题时的杀手锏，能看到完整的服务输出和错误堆栈。
为什么现代Linux发行版普遍采用Systemd和Systemctl？
我记得刚接触Linux那会儿，不同发行版的服务启动脚本写法都不太一样，排查问题简直是噩梦。Systemd出现后，虽然初期有些争议，但它带来的统一性、并行启动的效率提升，以及更完善的依赖管理，确实让系统管理变得省心多了。尤其是开机速度，那真是肉眼可见的快。
Systemd作为Linux系统的初始化系统和服务管理器，与传统的SysVinit或Upstart相比，带来了以下显著优势：
统一管理接口： Systemd将系统中的所有资源（服务、设备、挂载点、socket等）都抽象为“单元”（Unit），并提供
systemctl
这个统一的命令行工具进行管理。这大大降低了学习成本和管理复杂性。并行启动服务： SysVinit是串行启动服务的，一个服务启动完成才能启动下一个，导致开机速度较慢。Systemd则能通过Socket激活、D-Bus激活等机制，实现服务的并行启动，显著缩短系统启动时间。它能智能地识别服务间的依赖关系，并尽可能地并行处理。按需启动（On-demand activation）： 很多服务只有在被需要时才启动，而不是一开机就全部运行。例如，一个网络服务只有在接收到连接请求时才启动，这能有效节省系统资源。更强大的依赖管理： Systemd提供了更精细和强大的依赖管理机制。通过在单元文件中定义
Requires
、
Wants
、
Before
、
After
等指令，可以精确控制服务间的启动顺序和依赖关系，避免了“鸡生蛋，蛋生鸡”的问题。Cgroups支持： Systemd原生支持Linux的Cgroups（Control Groups）技术，能够更好地隔离和管理进程资源。这意味着每个服务都可以运行在自己的资源沙箱中，防止一个失控的服务影响整个系统。统一的日志管理（Journald）： Systemd集成了
journald
日志系统，所有系统和服务的日志都汇聚到这里，并通过
journalctl
命令进行统一查询和分析。这解决了传统日志分散、难以聚合的问题，让故障排查变得更加高效。配置简化与标准化： Systemd的
.service
单元文件采用INI风格的配置格式，相比SysVinit复杂的shell脚本，更易读、易写、易于维护。这使得创建和自定义服务变得更加简单直观。
如何创建自定义服务或排查Systemctl服务启动问题？
我曾经遇到过一个服务，在命令行下运行得好好的，一写成
.service
文件就各种报错。后来才发现是
ExecStart
里的路径没写对，或者是服务依赖的某个环境变量没在
[Service]
段里设置。这种小细节，往往最磨人。学会看
journalctl
的输出，真的能少走很多弯路。
创建自定义Systemd服务
创建一个自定义服务通常涉及到编写一个
.service
单元文件，并将其放置在正确的位置。
编写
.service
文件：通常放在
/etc/systemd/system/
目录下。例如，创建一个名为
my_app.service
的文件：
# /etc/systemd/system/my_app.service[Unit]Description=My Custom Python ApplicationAfter=network.target # 定义服务在哪个目标（Target）之后启动[Service]ExecStart=/usr/bin/python3 /opt/my_app/app.py # 启动服务的命令WorkingDirectory=/opt/my_app # 服务的工作目录Restart=always # 定义服务退出后如何重启 (no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, always)User=myuser # 以哪个用户身份运行服务Group=myuser # 以哪个用户组身份运行服务StandardOutput=journal # 将标准输出重定向到journaldStandardError=journal # 将标准错误重定向到journald[Install]WantedBy=multi-user.target # 定义服务被哪个目标（Target）“需要”，从而实现开机自启
[Unit]
部分： 包含服务的描述、依赖关系等。
After=network.target
表示该服务在网络服务启动后才尝试启动。
[Service]
部分： 定义服务的具体行为，如启动命令(
ExecStart
)、工作目录(
WorkingDirectory
)、重启策略(
Restart
)、运行用户(
User
)等。
Type
字段也很重要，常见的有
simple
（默认，主进程是服务本身）、
forking
（服务启动后会fork出一个子进程，父进程退出）、
oneshot
（一次性任务）、
notify
等。
[Install]
部分： 定义服务如何被安装（即如何实现开机自启）。
WantedBy=multi-user.target
表示当
multi-user.target
被激活时，该服务也会被激活。
重新加载Systemd配置：
sudo systemctl daemon-reload
这会通知Systemd重新扫描所有单元文件，加载新的或修改过的配置。
启动服务并设置开机自启：
sudo systemctl start my_app.servicesudo systemctl enable my_app.service
排查Systemctl服务启动问题
当服务无法按预期启动时，以下是一些常用的排查步骤：
查看服务状态：
systemctl status my_app.service
这是最直接的诊断工具，它会显示服务当前状态、最近的日志片段、PID、CGroup信息等。留意
Active:
字段是否为
active (running)
，以及是否有
failed
或
exited
等状态。
检查详细日志：
journalctl -xeu my_app.service
这是排查问题的杀手锏。
-x
会提供额外解释，
-e
会跳转到日志末尾，
-u
指定单元。它会显示服务启动和运行过程中所有的标准输出和标准错误日志，往往能直接指出错误原因，比如文件找不到、权限问题、代码异常等。
JoinMC智能客服
JoinMC智能客服，帮您熬夜加班，7X24小时全天候智能回复用户消息，自动维护媒体主页，全平台渠道集成管理，电商物流平台一键绑定，让您出海轻松无忧！
23 查看详情 
验证
ExecStart
命令和路径：确保
ExecStart
中指定的程序路径是正确的，并且该程序具有执行权限。一个常见的错误就是路径写错或者没有给脚本
+x
权限。尝试在命令行直接运行
ExecStart
中的命令，看看是否能正常工作。
检查文件和目录权限：确保服务运行的用户（在
User=
字段中指定）对
WorkingDirectory
以及服务需要访问的所有文件和目录都有足够的读写权限。
检查依赖关系：如果服务依赖于其他服务或资源（如网络、数据库），确保这些依赖项已经正确启动。
systemctl list-dependencies my_app.service
可以帮助你查看服务的依赖树。
环境变量问题：有时候服务在命令行下能跑，但通过
systemctl
启动就不行，这可能是因为环境变量不同。可以在
.service
文件的
[Service]
段中添加
Environment=
或
EnvironmentFile=
来设置或加载环境变量。
Type
字段的正确性：如果服务是
forking
类型（即主进程启动后会fork出子进程并退出），但
Type=simple
，Systemd可能会误判服务已退出。确保
Type
字段与服务的实际行为匹配。
Systemd中的目标（Target）是什么，以及如何列出和管理单元？
刚开始接触Systemd的Target时，我有点懵，感觉就是把运行级别换了个名字。但深入了解后，发现它比运行级别更灵活，可以自定义，也可以动态切换。特别是
mask
命令，虽然不常用，但在某些特殊场景下，比如要彻底阻止一个顽固服务启动，它简直是神器。当然，用的时候要格外小心，别把自己系统搞崩了。
Systemd Targets（目标）
Systemd中的“目标”（Target）是用来替代传统SysVinit运行级别（runlevel）的概念。它不是一个单一的服务，而是一组要启动的服务或一个特定的系统状态。每个Target都代表了系统可能达到的一种状态或模式。
核心概念： Target文件以
.target
为后缀，它们通过
Wants=
、
Requires=
等指令来定义需要启动哪些服务或激活哪些其他Target。常见Target示例：
multi-user.target
: 相当于传统的多用户文本模式（运行级别3），不带图形界面。
graphical.target
: 相当于带图形界面的多用户模式（运行级别5），它通常会“需要”
multi-user.target
。
reboot.target
: 用于系统重启。
poweroff.target
: 用于系统关机。
rescue.target
: 用于单用户救援模式。查看当前默认Target：
systemctl get-default
这会显示系统启动时默认进入的Target。
切换到不同的Target：
systemctl isolate
例如，
systemctl isolate multi-user.target
可以让你在不重启的情况下从图形界面切换到文本模式。
isolate
命令会停止所有与新Target不兼容的服务，并启动新Target所需的服务。
设置默认Target：
sudo systemctl set-default
例如，
sudo systemctl set-default graphical.target
会将图形界面设置为默认启动模式。
列出和管理Systemd单元
除了服务（
.service
）和目标（
.target
），Systemd还管理着其他类型的单元，如设备（
.device
）、挂载点（
.mount
）、socket（
.socket
）、定时任务（
.timer
）等。
列出所有已加载的单元：
systemctl list-units
这会显示所有当前Systemd进程已知的单元，包括活动的、不活动的、加载的、未加载的等。
列出所有单元文件的状态：
systemctl list-unit-files
这个命令会显示所有可用的单元文件及其是否被
enabled
、
disabled
、
static
（静态，不能被启用或禁用）、
masked
（被遮蔽）等状态。
查看特定单元的详细属性：
systemctl show
例如，
systemctl show nginx.service
会显示Nginx服务的所有配置属性，包括运行时状态、CGroup信息、依赖关系等，非常详细。
查看单元的依赖关系树：
systemctl list-dependencies
这个命令可以帮助你理解一个服务或目标所依赖的其他单元，以及哪些单元依赖于它
以上就是如何在Linux中管理服务 Linux systemctl启停服务的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/437929.html
微信扫一扫 
支付宝扫一扫 
