答案：CentOS系统中通过systemctl命令管理服务启停与自启，使用enable/disable控制开机启动，start/stop/restart控制运行状态，status查看服务详情，老版本则用chkconfig和service命令。
CentOS系统下，更改启动服务主要通过
systemctl
命令来完成，这是现代CentOS版本（如CentOS 7、8、9）管理系统服务的主流方式。它允许你启用（
enable
）或禁用（
disable
）服务，从而控制它们是否在系统启动时自动运行。同时，你也可以即时启动（
start
）、停止（
stop
）或重启（
restart
）服务，并查看它们的运行状态。对于更老的CentOS版本（如CentOS 6），则主要依赖
chkconfig
和
service
命令。
解决方案
在CentOS中管理系统服务启动项的核心就是熟练运用
systemctl
命令。这不仅仅是敲几个命令那么简单，它背后反映的是对系统资源和应用生命周期的掌控。
首先，要启用一个服务使其在系统启动时自动运行，你会用到
enable
子命令：
sudo systemctl enable
例如，如果你想让Nginx在每次开机后都自动启动，就是
sudo systemctl enable nginx
。执行这个命令后，
systemctl
会在
/etc/systemd/system/multi-user.target.wants/
目录下创建一个指向服务单元文件（通常在
/usr/lib/systemd/system/
）的符号链接。这只是设置了开机自启，服务本身并不会立即启动。
如果想禁用一个服务的开机自启，使其不再随系统启动：
sudo systemctl disable
这会移除前面提到的符号链接。
要立即启动一个服务，无论它是否设置为开机自启：
sudo systemctl start
要停止一个正在运行的服务：
sudo systemctl stop
有时候，服务配置修改后，需要重启来加载新配置：
sudo systemctl restart
如果你不确定服务是否支持
restart
，或者只是想让它重新加载配置而不中断服务（如果服务支持），可以使用
reload
：
sudo systemctl reload
查看服务的当前状态，包括是否正在运行、是否开机自启、最近的日志等，这是排查问题时最常用的：
systemctl status
我个人觉得，
status
命令是排查问题的第一步，它能给出很多有用的线索，比如服务是否真的启动了，有没有报错，以及最近的日志输出。
对于那些仍在维护的老旧CentOS 6系统，服务管理则依赖于
chkconfig
和
service
。启用开机自启：
sudo chkconfig on
禁用开机自启：
sudo chkconfig off
启动服务：
sudo service start
停止服务：
sudo service stop
查看状态：
sudo service status
但说实话，现在大部分生产环境都转向了Systemd，所以掌握
systemctl
是更具前瞻性的选择。
CentOS中如何查看和管理当前运行及开机自启的服务？
在CentOS系统里，了解当前服务状态和它们的自启配置，是系统管理员日常工作的重中之重。这不仅仅是为了知道什么在跑，更是为了优化系统资源、确保关键应用稳定运行，以及及时发现潜在的安全隐患。
要查看系统上所有已安装的服务单元文件（无论是否启用或运行），你可以使用：
systemctl list-unit-files --type=service
这个命令会列出所有以
.service
结尾的单元文件，并显示它们的状态，比如
enabled
（已启用开机自启）、
disabled
（已禁用开机自启）、
static
（静态服务，通常是依赖项，不能直接启用或禁用）或
masked
（被屏蔽，无法启动）。我发现这个列表非常有用，尤其是在你接手一台新服务器，想快速了解上面都装了些什么服务的时候。
如果你只想看那些当前正在运行的服务，可以这样：
systemctl list-units --type=service --state=running
这个命令会筛选出状态为
running
的服务。结合
--all
或
--state=failed
，你也能看到那些启动失败的服务，这对于快速定位问题非常有帮助。
当然，最常用的还是查看特定服务的详细状态：
systemctl status
这个命令会显示服务的运行状态、进程ID、内存占用、最近的日志条目等等。我通常会仔细查看
Active:
这一行，看看是
active (running)
还是
inactive (dead)
，以及
Loaded:
这一行，确认服务单元文件是否被正确加载。如果服务启动失败，这里会显示错误信息，并给出最近的日志路径，比如
journalctl -xeu
，这简直是排查问题的金钥匙。
管理服务启动项时，除了前面提到的
enable
和
disable
，还有个
mask
操作值得一提。如果你想彻底阻止某个服务启动，甚至是被其他服务依赖时也无法启动，可以使用
mask
：
乾坤圈新媒体矩阵管家
新媒体账号、门店矩阵智能管理系统
17 查看详情
sudo systemctl mask
这会在
/etc/systemd/system/
下创建一个指向
/dev/null
的符号链接，从而“屏蔽”掉这个服务。解除屏蔽则用
unmask
：
sudo systemctl unmask
我个人觉得
mask
功能在某些特定场景下非常有用，比如当你确定某个服务绝不应该启动，或者有安全隐患需要暂时禁用时，它比
disable
更彻底。
Systemd服务单元文件（.service）的结构是怎样的，以及如何自定义？
Systemd的服务单元文件，通常以
.service
结尾，是Systemd管理服务行为的核心。它们通常位于
/usr/lib/systemd/system/
（系统默认服务）或
/etc/systemd/system/
（管理员自定义或覆盖服务）目录下。理解这些文件的结构，对于我们自定义服务、调整现有服务行为至关重要。
一个典型的
.service
文件包含几个主要的段落，每个段落用方括号
[]
括起来，比如
[Unit]
、
[Service]
和
[Install]
。
[Unit]
段落：这个段落主要定义了服务的通用信息和依赖关系。
Description
: 对服务的简短描述。
Documentation
: 指向服务文档的URL。
After
: 定义了服务应该在哪些其他服务启动之后才启动。例如，
After=network.target
表示服务在网络可用后才启动。
Before
: 定义了服务应该在哪些其他服务启动之前启动。
Requires
: 定义了服务必须依赖的其他服务，如果依赖的服务启动失败，当前服务也不会启动。
Wants
: 类似于
Requires
，但依赖的服务启动失败不会阻止当前服务启动。这是一种“弱依赖”。
Conflicts
: 定义了与当前服务冲突的服务，如果冲突的服务正在运行，当前服务将无法启动，反之亦然。
我通常会在这里仔细配置
After
和
Wants
，确保我的应用在数据库、消息队列等依赖服务就绪后才启动，避免启动失败。
[Service]
段落：这是最核心的段落，定义了服务的具体执行方式。
Type
: 定义了服务的启动类型，常见的有
simple
（默认，主进程是服务本身）、
forking
（服务启动后会fork出一个子进程作为主进程，父进程退出）、
oneshot
（只执行一次命令就退出，Systemd会等待其完成）、
notify
（服务会向Systemd发送通知表示启动完成）等。
ExecStart
: 定义了启动服务时要执行的命令。这是服务启动的入口。
ExecStop
: 定义了停止服务时要执行的命令。
ExecReload
: 定义了重新加载服务配置时要执行的命令。
WorkingDirectory
: 服务进程的工作目录。
User
/
Group
: 指定服务运行的用户和组。出于安全考虑，我总是建议为服务创建一个专用的低权限用户。
Environment
: 为服务进程设置环境变量。
restart
: 定义了服务在什么情况下会自动重启，比如
on-failure
（失败时重启）、
always
（总是重启）等。
LimitNOFILE
: 限制服务进程可以打开的文件句柄数量。对于高并发服务，这个参数非常重要。
自定义服务时，
ExecStart
、
User
、
WorkingDirectory
和
restart
是我最常修改的几个参数。例如，我可能会创建一个Go语言应用程序的服务单元文件，
ExecStart
指向我的编译后的二进制文件，
User
设置为
goapp
，
WorkingDirectory
指向应用根目录。
[Install]
段落：这个段落定义了服务在启用（
enable
）时应该如何被链接到Systemd的启动目标。
WantedBy
: 定义了服务应该被哪个Systemd目标（target）所“想要”。最常见的是
multi-user.target
，表示服务在多用户模式下启动。
当执行
systemctl enable
时，Systemd会根据
WantedBy
字段在相应的
.target.wants/
目录下创建符号链接。
如何自定义或覆盖服务：如果你想修改一个系统自带服务的行为，不建议直接编辑
/usr/lib/systemd/system/
下的文件，因为系统更新可能会覆盖你的修改。更好的做法是在
/etc/systemd/system/
目录下创建同名的
.service
文件来覆盖，或者创建
override.conf
文件来增量修改。
例如，要修改
nginx.service
：
创建目录：
sudo mkdir -p /etc/systemd/system/nginx.service.d
创建配置文件：
sudo vim /etc/systemd/system/nginx.service.d/custom.conf
在
custom.conf
中，你可以只写你想要修改的段落和参数。例如，如果你只想修改Nginx的启动用户：
[Service]User=mynginxuserGroup=mynginxuser
保存后，需要重新加载Systemd配置：
sudo systemctl daemon-reload
然后重启服务：
sudo systemctl restart nginx
这种方式非常优雅，既保留了系统原有的服务文件，又实现了定制化，避免了升级冲突。
CentOS服务启动失败时，如何进行高效的故障排查？
服务启动失败，是系统管理员经常会遇到的头疼问题。面对一个“服务启动失败”的提示，如果只是干等着，那肯定解决不了问题。我总结了一套自己的排查思路，希望能帮助大家高效定位并解决问题。
第一步：查看服务状态和日志（
systemctl status
&
journalctl
）这是最直接、最有效的第一步。
systemctl status
仔细阅读输出信息。通常，如果服务启动失败，
Active:
行会显示
inactive (dead)
或
failed
，并且下方会有一两行关键的错误提示。更重要的是，它会告诉你查看更详细日志的命令，比如
journalctl -xeu
。
执行
journalctl -xeu
，这个命令会显示服务相关的系统日志，
-x
会提供额外解释，
-e
会跳转到日志末尾，
-u
指定服务单元。我通常会把输出翻到最底部，寻找
Error
、
failed
、
Permission denied
、
No such file or directory
等关键词。日志是服务排障的“黑匣子”，几乎所有的问题根源都能在这里找到线索。
第二步：检查服务单元文件配置（
.service
文件）如果日志信息不够明确，或者提示是配置问题，那么就需要检查服务单元文件了。定位服务单元文件：
systemctl cat
这个命令会直接打印出服务单元文件的内容，包括原始文件和所有覆盖文件。重点检查
[Service]
段落：
ExecStart
命令是否正确？路径是否正确？参数是否正确？
User
和
Group
是否设置了正确的用户和组，并且这些用户组是否存在？
WorkingDirectory
是否指向了正确的目录，并且该目录是否存在且权限正确？
Environment
变量是否正确设置？
Type
是否与服务的实际行为匹配？例如，如果服务是后台运行的，
Type=forking
可能更合适。
我遇到过很多次因为
ExecStart
中的路径写错，或者
User
没有权限访问特定文件而导致服务启动失败的情况。
第三步：手动执行启动命令进行测试有时候，直接通过
systemctl
启动服务会屏蔽掉一些错误信息。我们可以尝试以服务单元文件中
ExecStart
指定的命令，手动在终端中执行，并以服务所配置的用户身份执行。
首先，找到
ExecStart
中的完整命令。切换到服务配置的用户：
sudo -u bash
在切换后的用户shell中，手动运行
ExecStart
的命令。这样通常能看到更详细的错误输出，比如程序本身的语法错误、端口冲突、配置文件缺失或权限问题等。
第四步：检查依赖关系和端口冲突
依赖服务是否启动？ 回到
[Unit]
段落，检查
Requires
和
After
中列出的依赖服务是否都已正常启动。例如，一个Web应用服务可能依赖于数据库服务，如果数据库没启动，Web应用自然也起不来。
systemctl status
端口是否被占用？ 如果服务是一个网络服务，它可能因为监听的端口被其他进程占用而启动失败。
sudo netstat -tulnp | grep
或者使用
ss
命令：
sudo ss -tulnp | grep
如果发现端口被占用，你需要找出占用端口的进程并停止它，或者修改服务的监听端口。
第五步：检查文件权限和SELinux
文件权限： 确保服务要访问的配置文件、数据目录、日志目录等，对于服务运行的用户和组具有正确的读写权限。
ls -l
通常，
chown
和
chmod
是解决权限问题的利器。
SELinux： CentOS默认开启SELinux，它可能会阻止服务访问某些文件或端口，即使文件权限看起来是正确的。检查SELinux状态：
sestatus
如果SELinux处于
enforcing
模式，并且日志中出现了
AVC denied
相关的错误，那么很可能是SELinux阻止了服务。你可以暂时将SELinux设置为
permissive
模式进行测试：
sudo setenforce 0
。如果服务能正常启动，那么就需要为该服务配置SELinux策略，或者永久禁用SELinux（不推荐，除非你非常清楚风险）。查看SELinux审计日志：
sudo tail -f /var/log/audit/audit.log
。
通过这几步，基本上能定位到绝大多数服务启动失败的原因。关键在于系统性地思考，而不是盲目尝试。
以上就是CentOS怎么更改启动服务_CentOS管理系统服务启动项教程的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/585114.html
微信扫一扫 
支付宝扫一扫 
