CentOS服务管理核心是systemctl命令，它统一了服务的启动、停止、重启、状态查看和开机自启设置，取代了传统的service和chkconfig命令，提升了效率与标准化程度。通过systemctl start/stop/restart/status可控制服务运行状态，enable/disable用于管理开机自启，mask可屏蔽服务阻止启动，修改服务文件后需执行systemctl daemon-reload刷新配置。排查服务失败时，首先使用systemctl status查看状态，结合journalctl -u 分析日志，检查配置文件语法、端口占用、权限、SELinux策略及依赖关系。自定义服务需在/etc/systemd/system/下创建.service文件，包含[Unit]（描述和依赖）、[Service]（运行参数、用户、命令等）和[Install]（启用目标）三部分，编写后需重载配置并启用启动服务，实现对脚本或应用的标准化管理。
CentOS上的服务管理，说白了，就是围绕着
systemctl这个命令来打转。它统一了服务的启动、停止、重启、查看状态以及设置开机自启动等所有操作，是日常系统维护的核心工具，掌握它，基本就能搞定绝大多数服务管理的需求。
解决方案
在CentOS上，服务的启动、停止和设置主要通过
systemctl命令来完成。以下是一些常用的操作：
启动服务： 要让一个服务跑起来，比如
httpd(Apache web服务器)，你只需要输入：
systemctl start httpd
这个命令会尝试启动
httpd服务。如果一切顺利，服务就会运行。
停止服务： 当你想让一个正在运行的服务停下来时，比如
nginx，命令是：
systemctl stop nginx
这会安全地关闭
nginx进程。
重启服务： 如果你修改了服务的配置文件，或者只是想刷新一下服务状态，通常会选择重启。例如，重启
php-fpm：
systemctl restart php-fpm
这个操作会先停止服务，然后再启动它。
查看服务状态： 这是排查问题和确认服务运行情况最常用的命令。比如，想知道
mariadb现在怎么样了：
systemctl status mariadb
它会显示服务是否正在运行、最近的日志输出、进程ID等详细信息。我个人觉得
systemctl status比起以前的
service命令，输出的信息量和可读性真是好了太多，一眼就能看出问题所在。
设置开机自启动（启用服务）： 很多时候，我们希望服务在系统启动后自动运行，避免每次重启服务器后手动启动。启用
sshd服务开机自启：
systemctl enable sshd
这个命令会在系统启动时创建一个符号链接，让
systemd在开机时启动该服务。
取消开机自启动（禁用服务）： 如果一个服务你不再需要它在开机时自动运行，或者想手动控制，可以禁用它：
systemctl disable firewalld
这会移除之前创建的符号链接，阻止
firewalld在下次开机时自动启动。
屏蔽服务（阻止任何形式的启动）： 有时候，你可能想彻底阻止某个服务被启动，即使是其他服务依赖它也不行。这时可以使用
mask：
systemctl mask postfix
它会创建一个指向
/dev/null的符号链接，让
postfix变得“不可用”。解除屏蔽则用
unmask。
重新加载 systemd 配置： 当你创建或修改了服务单元文件（
.service文件）后，
systemd需要重新加载配置才能识别这些更改：
systemctl daemon-reload
这是个很关键的步骤，常常有人会忘记。
CentOS服务管理中，systemctl和传统service/chkconfig命令有什么区别？
从我个人经验来看，从旧的SysVinit/Upstart系统迁移到以
systemd为核心的CentOS 7+，最大的感触就是命令的统一性和效率的提升。以前我们管理服务，得用
service命令来启动停止，用
chkconfig来设置开机自启，这本身就是两个不同的工具，学习和记忆成本稍微高一点。更别提，
service命令背后其实是执行
/etc/init.d/下的脚本，这些脚本的写法各异，有时候排查起来也挺费劲的。
systemctl的出现，彻底改变了这种局面。它不仅将服务管理、开机自启设置等功能整合到一个命令下，而且背后的
systemd架构也带来了诸多优势。比如，
systemd能够实现服务的并行启动，大大缩短了系统启动时间。它还深度集成了Cgroups，对服务资源的管理和隔离做得更好。更重要的是，它提供了统一的单元文件（
.service文件）格式，让服务配置标准化，无论是什么服务，其配置文件结构都大致相同，这让管理和排错变得简单直观。
虽然在CentOS 7+上，你可能偶尔还能用
service httpd start这样的命令，但那通常只是为了兼容性而做的软链接，最终还是会调用
systemctl。所以，直接拥抱
systemctl才是王道，它是现代Linux服务管理的基石。
如何排查CentOS服务启动失败的常见问题？
服务启动失败，这简直是运维日常。我遇到过太多次了，一开始可能有点手足无措，但久而久之就总结出了一套自己的排查流程。
第一步，也是最重要的一步，就是查看服务状态：
systemctl status
这个命令的输出至关重要，它会告诉你服务是
active (running)还是
inactive (dead)，或者
failed。如果
failed了，通常会在输出的最后几行显示具体的错误信息。比如，Nginx启动失败，我首先会看
systemctl status nginx，如果提示
bind() to 0.0.0.0:80 failed (98: Address already in use)，那多半是端口冲突了，可能是Apache还在跑，或者有其他进程占用了80端口。这时候
netstat -tulpn | grep :80就能帮我定位哪个进程占用了端口。
如果
status命令给出的信息不够详细，我会深入查看日志。
journalctl是
systemd的日志查看工具，非常强大：
journalctl -xe # 查看所有系统日志，-x 显示解释，-e 跳到最后 journalctl -u# 只看特定服务的日志
通过
journalctl -u nginx，我可以详细看到Nginx启动时到底发生了什么，比如配置文件解析错误、权限问题、依赖的服务未启动等。
除了日志，还有几个常见点需要检查：
-
配置文件错误： 很多服务启动失败都是因为配置文件写错了。比如Nginx的
nginx.conf
，Apache的httpd.conf
。一些服务会有配置语法检查命令，比如nginx -t
或apachectl configtest
，先跑一下能省不少事。 - 权限问题： 服务运行时需要访问文件或目录，如果权限不对，也可能导致启动失败。比如，服务用户对日志目录没有写入权限。
- 依赖问题： 某些服务依赖于其他服务。比如，很多Web应用依赖数据库。如果数据库没启动，Web应用自然也起不来。
- 资源限制： 偶尔也会遇到内存不足或文件句柄数不够导致服务启动失败的情况，特别是大型应用。
-
SELinux： 这玩意儿有时候真是个“惊喜”。如果你开启了SELinux，它可能会阻止服务执行某些操作，即使文件权限看起来是正确的。这时候可以暂时禁用SELinux (
setenforce 0
) 测试一下，如果服务能启动，那问题就出在SELinux策略上，需要定制策略或者永久禁用（不推荐）。
排查过程其实就是个侦探游戏，根据线索一步步缩小范围，最终找到真凶。
CentOS中如何自定义服务单元文件（.service）？
有时候，系统自带的服务单元文件不能满足我们的需求，或者我们需要将一个自定义的脚本、应用程序包装成一个可管理的
systemd服务。这时，我们就需要自己动手编写
.service文件了。我记得有一次需要跑一个自定义的Python数据处理脚本，用
crontab总是感觉不够优雅，也难以管理。后来学着用
systemd写了个
.service文件，把脚本包装成一个服务，不仅能用
systemctl统一管理，还能设置重启策略，简直完美。虽然初次上手有点门槛，但掌握了之后，系统管理的灵活性大大增强。
自定义服务单元文件通常放在
/etc/systemd/system/目录下，文件名以
.service结尾，比如
my_app.service。一个典型的
.service文件包含三个主要部分：
[Unit]、
[Service]和
[Install]。
1. [Unit]
部分：
这部分描述了服务的通用信息，以及它与其他单元的关系。
Description
: 服务的简短描述。After
: 定义本服务在哪些服务之后启动。比如After=network.target
表示网络就绪后才启动。Requires
: 定义本服务启动前必须启动的服务。如果Requires
的服务启动失败，本服务也会启动失败。
2. [Service]
部分：
这是核心部分，定义了服务的具体行为。
Type
: 服务的启动类型。常见的有simple
(默认，ExecStart
执行的进程就是主进程)、forking
(ExecStart
启动的进程会fork出一个子进程，父进程退出)、oneshot
(执行一次性任务，完成后退出)。ExecStart
: 启动服务时执行的命令或脚本。这是最重要的指令。ExecStop
: 停止服务时执行的命令。ExecReload
: 重载服务时执行的命令。WorkingDirectory
: 服务的工作目录。User
和Group
: 指定服务运行的用户和组，这对于安全很重要。Restart
: 定义服务在何种情况下自动重启。比如on-failure
(失败时重启)、always
(总是重启)。Environment
: 为服务进程设置环境变量。
3. [Install]
部分：
这部分定义了服务如何被
systemctl enable命令启用。
WantedBy
: 定义了当本服务被启用时，它应该被添加到哪个target
下。最常见的是multi-user.target
，表示在多用户模式下启动。
一个简单的自定义服务示例 (/etc/systemd/system/my_script.service
)：
假设你有一个Python脚本
/opt/my_script/run.py，你想让它作为一个服务运行。
[Unit] Description=My Custom Python Script Service After=network.target [Service] Type=simple User=your_user # 替换为实际的用户 Group=your_group # 替换为实际的组 WorkingDirectory=/opt/my_script ExecStart=/usr/bin/python3 /opt/my_script/run.py Restart=on-failure # 如果脚本运行失败，systemd会自动重启它 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
创建并启用自定义服务的步骤：
-
创建服务文件： 将上述内容保存为
/etc/systemd/system/my_script.service
。 -
重新加载 systemd 配置：
systemctl daemon-reload
这一步是告诉
systemd
有新的服务单元文件了。 -
启用服务：
systemctl enable my_script.service
这会设置
my_script
服务在系统启动时自动运行。 -
启动服务：
systemctl start my_script.service
-
检查服务状态：
systemctl status my_script.service
你可以看到脚本是否正在运行，以及最近的日志输出。
通过这种方式，你可以将任何需要长时间运行的程序或脚本，或者需要开机自启的任务，都纳入
systemd的统一管理之下，这对于系统维护和自动化来说，是非常高效和规范的做法。
