答案：使用systemd创建.service文件并启用服务。具体步骤包括：在/etc/systemd/system/下创建服务文件，定义[Unit]、[Service]、[Install]三部分，设置Description、ExecStart、User、WantedBy等关键参数，确保脚本有执行权限；修改后运行sudo systemctl daemon-reload；通过sudo systemctl enable my_app.service设置开机自启，sudo systemctl start测试启动，sudo systemctl status和journalctl -u查看状态和日志。排查失败常见原因：路径错误、权限不足、依赖未满足、环境变量缺失、未执行daemon-reload。替代方案如rc.local适用于简单任务，cron@reboot用于一次性命令，但均缺乏服务管理能力。推荐始终使用systemd进行服务管理，并通过systemctl命令监控状态、依赖和日志，结合外部工具实现告警和资源监控，确保服务稳定运行。
在Linux系统上设置服务开机自启，最核心的思路就是让操作系统在启动时知道并执行你想要运行的程序或脚本。对于现代Linux发行版，这几乎都围绕着
systemd
展开，它是一个强大的系统和服务管理器，负责在系统启动时初始化所有服务、管理它们的运行状态以及在关机时正确地终止它们。简单来说，就是通过配置
systemd
的单元文件（
.service
文件），告诉系统你的服务是什么、如何启动、何时启动，然后启用它。
解决方案
要让一个服务在Linux开机时自动启动，我们通常会创建一个
systemd
服务单元文件，并将其放置在正确的位置，然后通过
systemctl
命令来启用它。这比以前的
SysVinit
或
Upstart
要规范和强大得多。
我记得刚开始接触Linux那会儿，最头疼的就是怎么让我的小脚本开机就跑起来，各种
rc.local
、
cron
的
@reboot
都试过，但对于真正的服务管理，
systemd
才是正解。
核心步骤如下：
创建服务单元文件：在
/etc/systemd/system/
目录下创建一个
.service
文件，比如
my_app.service
。这个文件定义了你的服务如何运行。
sudo vim /etc/systemd/system/my_app.service
文件内容通常包含三个主要部分：
[Unit]
、
[Service]
和
[Install]
。
[Unit]Description=我的自定义应用程序服务After=network.target # 定义服务启动的顺序，表示在网络服务启动后才启动# Wants=mysql.service # 如果你的服务依赖于MySQL，可以这样声明[Service]Type=simple # 服务类型，simple表示ExecStart是主进程ExecStart=/usr/local/bin/my_app_script.sh # 服务的启动命令或脚本路径# ExecStop=/usr/local/bin/my_app_stop.sh # 停止命令（可选）Restart=on-failure # 定义服务在失败时如何重启，例如：always, on-failure, noUser=myuser # 运行服务的用户（可选，建议非root用户）Group=myuser # 运行服务的用户组（可选）WorkingDirectory=/opt/my_app # 服务的工作目录（可选）[Install]WantedBy=multi-user.target # 定义服务在哪个运行级别（target）下启用# 通常是multi-user.target，表示在多用户模式下启用（不带图形界面）# 如果是桌面应用，可能是graphical.target
Description
: 对服务的简短描述。
After
: 定义服务启动的顺序。
network.target
表示在网络服务启动后。
Type
:
simple
是最常见的，表示
ExecStart
定义的命令是主进程。其他类型如
forking
（后台进程）、
oneshot
（一次性任务）。
ExecStart
: 启动服务的实际命令或脚本。确保脚本有执行权限（
chmod +x /usr/local/bin/my_app_script.sh
）。
Restart
: 服务崩溃或异常退出时，
systemd
如何处理。
on-failure
是一个不错的选择。
User
/
Group
: 建议为服务指定一个非root用户和组，以增强安全性。
WantedBy
:
multi-user.target
是标准的多用户命令行环境。
重新加载
systemd
配置：每次修改或添加服务单元文件后，都需要让
systemd
重新加载其配置。
sudo systemctl daemon-reload
启用服务：将服务设置为开机自启。这会在
/etc/systemd/system/multi-user.target.wants/
（或你
WantedBy
指定的target的
wants
目录）下创建一个指向你的服务文件的软链接。
sudo systemctl enable my_app.service
启动服务（可选，立即测试）：如果你想立即启动服务而无需重启系统，可以使用：
sudo systemctl start my_app.service
检查服务状态：确认服务是否正在运行，以及是否有任何错误。
sudo systemctl status my_app.service
查看日志：
journalctl -u my_app.service
至此，你的服务就应该能在系统重启后自动运行了。
为什么我的Linux服务开机自启失败了？如何排查？
这绝对是新手甚至老手都会遇到的坑。我曾经为了一个简单的Python脚本开机自启，查了一下午的日志才发现是路径问题。当服务没有按预期启动时，通常是以下几个原因：
服务文件路径或命名错误： 确保
.service
文件位于
/etc/systemd/system/
，并且文件名与你
enable
时使用的名称一致。
ExecStart
命令不正确或无执行权限：检查
ExecStart
中指定的命令或脚本路径是否正确。确认该脚本或程序有执行权限（
chmod +x /path/to/script.sh
）。命令中使用的路径应该是绝对路径，环境变量可能在服务启动时还未加载。依赖问题：服务可能依赖于其他尚未启动的服务。例如，如果你的服务需要数据库，但
After=mysql.service
没有正确配置，或者MySQL服务本身启动失败。检查
After=
或
Requires=
字段是否正确，并确保它们依赖的服务也正常运行。日志输出错误：服务启动失败时，
systemd
通常会将错误信息记录到日志中。使用
sudo systemctl status your_service.service
查看服务的当前状态，它会显示最近的错误信息。更详细的日志可以通过
journalctl -u your_service.service
查看。如果服务有自己的日志文件，也要检查那些日志。权限问题：如果
User
和
Group
字段配置不当，或者服务需要访问某个文件但没有相应权限，也会导致启动失败。尝试以
root
用户运行服务（仅用于排查，不建议生产环境），如果成功，那很可能就是权限问题。
WantedBy
配置错误：确保
WantedBy
指向正确的target，例如
multi-user.target
。如果指向了一个系统不会进入的target，服务自然不会自启。
daemon-reload
未执行：每次修改
.service
文件后，务必运行
sudo systemctl daemon-reload
，否则
systemd
不会加载新的配置。
排查流程建议：
查看状态：
sudo systemctl status your_service.service
，这是第一步，通常能提供关键线索。查看日志：
sudo journalctl -xeu your_service.service
，
-x
会提供额外解释，
-e
会跳到日志末尾。仔细阅读日志中的错误信息。手动运行： 尝试在命令行中直接运行
ExecStart
中指定的命令，看看能否成功，并观察是否有错误输出。逐步简化： 如果服务很复杂，可以先用一个简单的脚本（例如只输出一行文字到文件）来替换
ExecStart
，确保
systemd
配置本身没问题。
除了systemd，还有其他方法可以实现开机自启吗？各自适用于什么场景？
我个人觉得，对于大多数现代Linux发行版，
systemd
是唯一的正解。它提供了最完善的服务管理功能，包括依赖管理、日志集成、资源限制等。但如果你还在维护一些老旧系统，或者有特定的轻量级需求，了解一下其他方法也无妨。
/etc/rc.local
(或
/etc/rc.d/rc.local
)：
启科网络PHP商城系统
启科网络商城系统由启科网络技术开发团队完全自主开发，使用国内最流行高效的PHP程序语言，并用小巧的MySql作为数据库服务器，并且使用Smarty引擎来分离网站程序与前端设计代码，让建立的网站可以自由制作个性化的页面。 系统使用标签作为数据调用格式，网站前台开发人员只要简单学习系统标签功能和使用方法，将标签设置在制作的HTML模板中进行对网站数据、内容、信息等的调用，即可建设出美观、个性的网站。
0 查看详情 原理： 这是一个在系统启动末期执行的脚本。通常，在
systemd
接管之前，
SysVinit
系统会在所有其他初始化完成后执行它。在现代
systemd
系统中，
rc-local.service
会专门调用它。优点： 简单粗暴，直接把命令或脚本写进去就行，对于一些简单的一次性任务非常方便。缺点： 缺乏服务管理能力（无法查看状态、重启、依赖等），不适合管理复杂的、需要持续运行的服务。如果脚本执行失败，系统不会有明确的提示。许多新版发行版默认可能不再启用或提供此文件。适用场景： 执行一些非常简单的、一次性的系统初始化命令，例如挂载特定的文件系统、设置环境变量，或者启动一个不需要
systemd
严格管理的小工具。
cron
的
@reboot
：
原理：
cron
是Linux下的定时任务工具。
@reboot
是一个特殊的语法，表示在系统启动后执行一次任务。优点： 简单，适合在系统启动后只运行一次的任务。缺点： 同样缺乏服务管理能力，无法监控任务的运行状态。如果任务是一个需要持续运行的服务，它只会在启动时运行一次，之后如果崩溃就不会自动重启。适用场景： 在系统启动后发送一次通知邮件、清理临时文件、或者运行一次数据同步脚本等。不适合作为常驻服务的启动方式。
SysVinit
脚本 (
/etc/init.d/
)：
原理： 这是
systemd
之前的标准服务管理方式。每个服务都有一个独立的启动脚本，放置在
/etc/init.d/
目录下。通过
chkconfig
或
update-rc.d
工具创建软链接到
/etc/rcX.d/
目录（
X
代表运行级别），从而控制服务在不同运行级别的启动和停止。优点： 在老旧系统上是标准方法，提供基本的启动、停止、重启功能。缺点： 配置复杂，依赖关系处理不便，启动速度较慢（串行启动），缺乏现代服务管理器的很多高级功能。适用场景： 维护基于
SysVinit
的老旧Linux系统，或者在一些嵌入式设备上（它们可能为了轻量化而没有
systemd
）。
Upstart
：
原理： 曾是Ubuntu在
SysVinit
和
systemd
之间的一个过渡方案。它基于事件驱动，通过配置文件（通常在
/etc/init/
下）来定义服务。优点： 比
SysVinit
更灵活，支持事件触发。缺点： 已被
systemd
取代，不再是主流。适用场景： 仅限于维护那些还在使用
Upstart
的旧版Ubuntu系统。
总结来说，除非有非常特殊的需求或是在维护老旧系统，否则
systemd
是实现Linux服务开机自启的首选，也是唯一推荐的方式。它提供了最健壮、最灵活、最易于管理的服务生命周期控制。
如何管理和监控开机自启的服务？
仅仅设置好自启还不够，我们还需要一套方法来确保它们真的运行良好，并且在出问题时能及时发现。毕竟，谁也不想服务默默挂掉却一无所知。
systemd
提供了一整套工具来帮助我们管理和监控这些服务。
列出所有已启用的服务：要查看哪些服务被设置为开机自启，可以使用：
systemctl list-unit-files --type=service --state=enabled
这会列出所有处于
enabled
状态的服务单元文件。
查看特定服务的状态和日志：这是最常用的监控手段。
systemctl status my_app.service
它会显示服务是否正在运行、PID、内存占用、最近的日志行等关键信息。要查看更详细的历史日志，可以使用
journalctl
：
journalctl -u my_app.service
如果想实时跟踪日志输出，可以加上
-f
参数：
journalctl -f -u my_app.service
手动控制服务：即使服务是开机自启的，我们仍然需要手动启动、停止、重启或重新加载它。
sudo systemctl start my_app.service # 启动服务sudo systemctl stop my_app.service # 停止服务sudo systemctl restart my_app.service # 重启服务sudo systemctl reload my_app.service # 重新加载服务配置（如果服务支持）sudo systemctl disable my_app.service # 取消开机自启
检查服务依赖关系：如果服务启动失败，了解它的依赖关系可能很有用。
systemctl list-dependencies my_app.service
这会显示你的服务所依赖的其他服务或目标。
资源监控：虽然
systemd
本身不直接提供高级资源监控功能，但你可以结合其他工具：
top
或
htop
：查看系统整体的CPU、内存占用，并找到你的服务进程。
ps -ef | grep my_app
：查找特定服务的进程。
systemd-cgtop
：查看
cgroup
（控制组）中服务的资源使用情况，这在
systemd
中非常有用。日志轮转： 如果你的服务有自己的日志文件（而不是全部输出到
journald
），考虑使用
logrotate
来管理日志文件的大小和数量，防止磁盘空间耗尽。
健康检查和告警：对于生产环境中的关键服务，仅仅靠
systemctl status
是不够的。可以考虑集成更高级的监控系统（如Prometheus、Grafana、Zabbix等），它们可以定期检查服务的HTTP端口、进程状态，并在服务异常时发送告警。在
systemd
服务文件中，也可以定义
ExecStartPre
、
ExecStartPost
等钩子，或者
HealthCheck
指令（如果服务支持），来执行一些健康检查。
通过这些管理和监控手段，我们不仅能确保服务能够开机自启，还能持续地了解它的运行状况，并在问题发生时快速响应。这对于维护一个稳定可靠的Linux系统至关重要。
以上就是Linux如何设置服务开机自启的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/723111.html
微信扫一扫 
支付宝扫一扫 
