做运维这些年被问得最多的问题之一就是“机器重启之后我那个脚本怎么又不跑了”——开机自启动这四个字听着简单做起来的坑却一点都不少。手工在终端里敲一条命令进程跑得好好的写进系统里让它自己起来结果重启一看active (failed)日志里一堆看不懂的输出。我用systemd的服务单元来做开机自启动前后踩过的坑能写满两页纸路径不对、环境变量丢了、网络还没起来就去连数据库、进程fork到后台之后 systemd 以为它挂了、反复重启把机器拖死……这些问题都有明确的成因也都有干净的解法。这篇文章就聊这个Linux 系统使用服务实现开机自启动。它适合刚接手服务器、需要把自研程序常驻的开发者适合手工起进程起烦了、想一次配好长期省心的运维也适合那些被“为什么enable了还是没起来”卡住半天的人。下面我按“选方案—写单元—调依赖—查故障”的顺序把每一步的理由和实操都摊开讲代码可以直接抄。1. 开机自启动的几条路先搞清楚各走哪条1.1 四种常见做法与它们的真实适用边界Linux 上让程序跟着系统起来常见的就是四种方式systemd服务单元、/etc/rc.local、crontab里的reboot、以及桌面环境的~/.config/autostart/*.desktop。这四个东西并不是“新老替代”的关系它们的定位差别很大。systemd服务单元是现在的正路。它管的是进程的生命周期起、停、重启、看状态、收集日志、失败重试、依赖排序全都归它。你写一个.service文件等于把“这个程序该怎么活”告诉系统之后系统按这套规则管它。/etc/rc.local是历史遗留。它本质上是系统启动后期执行的一个脚本里面写什么就干什么没有进程管理。启动脚本执行完就退出了程序在不在、挂没挂系统一概不知。它适合的场景很窄一次性、跑完就结束、不需要守护的初始化动作比如挂载某个特殊设备、改一个内核参数。crontab的reboot更粗糙。它在 cron 守护进程启动时触发一次执行你写的那行命令。问题在于它不等网络、不等其他服务触发时机比systemd靠前且不可控而且 cron 的环境极其干净PATH往往只有/usr/bin:/bin你在终端里能跑的命令在这里大概率报“命令找不到”。它适合做什么适合那些“晚一点起来也没关系、失败一次也无所谓”的辅助任务比如清一下临时目录、给某个监控端点发个心跳。桌面环境的.desktop自启动文件只对图形登录会话有效服务器上根本用不上。它的价值在办公机、开发机上——开机登录后自动开个终端、拉个笔记工具、起个本地服务。如果目标机器没有图形界面这条路直接划掉。1.2 为什么我把 systemd 服务单元当成默认答案判断标准其实就一条这个程序需不需要被“管”。需要长期驻留、需要崩了自动拉起、需要看它到底活着没活着、需要开机后按正确顺序等别的服务就绪——只要占一条就该用systemd。我见过太多“用 rc.local 起一个常驻进程”的写法短期能跑长期一定出问题。进程因为内存泄漏被内核 OOM 杀掉rc.local 不知道也不会重启它机器上跑着两个实例手动起了一个、开机又起了一个端口冲突出故障了想看日志程序自己的输出要么丢了要么写到某个没人记得的文件里。这些都是“没有守护”的直接后果。systemd把这些问题一次性解决掉Restarton-failure处理崩溃拉起systemctl status一眼看状态journalctl -u把所有标准输出和错误收归一处After/Wants处理启动顺序。代价是你得学一套不算复杂的配置语法一次性投入长期受益。方案是否守护进程启动时机可控日志归集依赖排序推荐场景systemd 服务单元是强有journal有常驻服务、需自动拉起/etc/rc.local否弱无无一次性初始化动作crontab reboot否很弱无无失败也无所谓的辅助任务.desktop 自启动否弱无无桌面登录后的用户程序有一点需要说清楚rc.local和reboot并不是“不能用”而是不要拿它们去承担守护职责。用错了工具后面所有的排查都会变成玄学。2. 服务单元的三段结构字段别乱填2.1 [Unit]、[Service]、[Install] 各管什么一个.service文件由三个段组成分工非常明确很多人写错就是因为把该放 A 段的写进了 B 段。[Unit]段描述“这个单元是谁、和谁有关系”。常用的就四个Description写人话描述After声明在谁之后启动Wants/Requires声明想要/强依赖谁ConditionPathExists做条件判断路径不存在就不启动。这一段不涉及具体怎么执行程序。[Service]段是核心描述“怎么跑这个程序”。Type决定 systemd 怎么判断启动成功ExecStart是启动命令ExecStop/ExecReload是配套动作User/Group/WorkingDirectory/Environment是运行环境Restart系列是重试策略。[Install]段只在你执行systemctl enable的时候被读取它决定“这个单元挂到哪个 target 上”。最常用的就是WantedBymulti-user.target。这里有个高频误解[Install]段的内容在正常运行时不生效你改完之后如果只restart不重新enable改动是不落地的。2.2 Type 参数怎么选选错就是“启动成功但其实没起来”Type是这套配置里最容易填错的一个字段它的本质是回答一个问题systemd 怎么知道你的程序已经启动完成了。Typesimple是默认值意思是“ExecStart一执行就算启动成功”。绝大多数前台运行的程序自己不会跑到后台的都用这个。注意simple下 systemd 不等任何东西你的程序如果启动要花 30 秒初始化systemd 在第 0 秒就认为它起来了后续依赖它的服务可能过早启动。Typeforking用于那些自己会fork到后台的老式守护进程。用这个类型必须配PIDFile告诉 systemd 主进程号写在哪否则它没法跟踪。老式的 Nginx、部分 Java 服务的启动脚本走这条路。Typeoneshot用于“跑完就结束”的任务systemd 会等它执行完才算启动成功。适合初始化脚本、数据迁移那种一次性动作。配RemainAfterExityes可以让它在执行完之后仍然显示为active。Typenotify需要程序自己调用sd_notify()告诉 systemd “我准备好了”最精确但要求程序配合。Typeexec是较新版本才有的和simple类似但要等execve()成功才判定能更早发现“命令根本不存在”这种错误。实操建议除非你在移植一个明确会自己后台化的老程序否则一律先试simple。用simple出问题多半是程序自己 daemonize 了那就换成forking加PIDFile两分钟能解决。2.3 环境变量和工作目录这两个坑几乎人人踩手工在终端里cd /opt/app ./run.sh跑得通。写成服务之后起不来八成就是这两个原因。工作目录systemd启动服务时默认工作目录是/不是你的程序目录。程序里所有相对路径——读配置、写日志、加载模型文件——全部会跑到根目录下去找自然找不到。必须显式写WorkingDirectory/opt/app。这一条我在早期项目里栽过程序日志文件被创建到了/下面权限还不对最后是ls -l /看到多出来的文件才反应过来。环境变量systemd给服务进程的环境变量是一个极简集合PATH通常只有/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin你在~/.bashrc里配的那些统统不存在。所以要么在ExecStart里用绝对路径要么在单元里补Environment要么用EnvironmentFile从一个文件加载一批。我倾向于用EnvironmentFile/etc/sysconfig/myapp把变量集中在一个文件里单元文件保持干净改配置不用动单元、不用daemon-reload。这个文件的格式是KEYvalue一行一个不支持export不支持引号包裹整行的 shell 语法值里有空格的话用双引号包住。注意Environment里写多组变量时可以用空格分隔但值本身含空格就必须加引号否则会被拆成两个变量报错信息还很不友好。3. 从零写一个能直接用的服务单元3.1 目录放哪里优先级要搞清楚服务单元的搜索路径有三个优先级从高到低/etc/systemd/system/管理员自定义优先级最高。你自己写的服务放这里。/run/systemd/system/运行时生成重启即失效。/usr/lib/systemd/system/软件包安装的默认位置升级包时会被覆盖。自己写的服务一律放/etc/systemd/system/文件名用服务名.service权限644属主root。不要放/usr/lib下面那是在跟包管理器抢地盘一次yum upgrade就可能把你的配置冲掉。写完文件后必须执行systemctl daemon-reload否则 systemd 用的还是内存里的旧配置。这个动作很多人忘症状是“我明明改了怎么还是老行为”然后开始怀疑人生。3.2 三份可抄的模板脚本型、编译型、Java 型先看最常见的脚本型Python / Shell / Node 这类解释型程序[Unit] DescriptionMy Python Worker Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userappuser Groupappuser WorkingDirectory/opt/myapp EnvironmentFile/etc/sysconfig/myapp ExecStart/opt/myapp/venv/bin/python /opt/myapp/worker.py ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec5 StartLimitIntervalSec60 StartLimitBurst5 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target几个字段值得单独说。ExecReload里用了$MAINPID这是 systemd 提供的变量指向主进程号kill -HUP给进程发重载信号。Restarton-failure表示只有异常退出才重启正常退出返回码 0不重启——这个区分很重要oneshot类任务如果用always会无限循环。RestartSec5是每次重启前等 5 秒给系统一点缓冲。StandardOutputjournal和StandardErrorjournal其实默认就是这样写出来是为了提醒程序的标准输出会被journalctl收走你可以放心地print不用担心日志散落。再看编译型程序Go、Rust、C 编译出来的单文件二进制[Unit] DescriptionMy Gateway Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typeexec Usersvcuser WorkingDirectory/opt/gateway ExecStart/opt/gateway/bin/gateway --config /etc/gateway/config.yaml Restartalways RestartSec3 LimitNOFILE65535 LimitNPROC4096 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target这里多了几个东西。LimitNOFILE65535是文件句柄上限网络服务跑一段时间报 “too many open files” 基本都是这个没设。PrivateTmptrue给进程一个独立的/tmp好处是不和其他服务抢文件名坏处是你在/tmp里放的、想跨服务共享的文件它看不见了——设之前想清楚。NoNewPrivilegestrue禁止进程提权是个低成本的安全加固。Restartalways和前面的on-failure区别在于正常退出也重启。什么时候用用在那种“进程生命周期应该和系统一样长”的常驻服务上即使它因为某种原因正常退出了你也希望它回来。第三个是 Java 型坑最多[Unit] DescriptionMy Java API Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userappuser WorkingDirectory/opt/myjava EnvironmentJAVA_HOME/usr/lib/jvm/java-17-openjdk EnvironmentJAVA_OPTS-Xms512m -Xmx2g -Dfile.encodingUTF-8 ExecStart/bin/bash -c exec $JAVA_HOME/bin/java $JAVA_OPTS -jar /opt/myjava/app.jar --spring.profiles.activeprod Restarton-failure RestartSec10 SuccessExitStatus143 TimeoutStopSec30 [Install] WantedBymulti-user.target三个要点。第一ExecStart里为了让$JAVA_HOME和$JAVA_OPTS被 shell 展开用了/bin/bash -c ...展开失败的话java路径会变成空的报“找不到命令”。第二SuccessExitStatus143是因为 JVM 收到SIGTERM信号 15退出时返回码是 12815143不写这一条正常停止也会被判定为“失败”然后被Restart拉起来你一停它就重启形成拉锯。第三TimeoutStopSec30给 JVM 够时间做优雅关闭默认值可能不够JVM 被杀的时候正在处理的请求会断。提示ExecStart不支持管道、重定向、通配符也不支持。这些必须靠bash -c包一层或者在程序侧解决。用bash -c时注意单双引号$MAINPID这类 systemd 变量在双引号里会被 systemd 提前展开。3.3 enable 和 start 不是一回事WantedBy 到底干了什么systemctl start mysvc是现在就起。systemctl enable mysvc是“登记开机自启”它做的事其实特别朴素在/etc/systemd/system/multi-user.target.wants/目录下建一个符号链接指向你的单元文件。multi-user.target是系统启动到“多用户命令行可用”的状态可以理解成传统的运行级别 3。系统启动进入这个 target 时会把.wants目录下所有链接对应的单元都拉起来。所以WantedBymulti-user.target翻译成人话就是“把我挂到 multi-user 这个 target 的启动清单里”。搞明白这一点很多困惑自然消解为什么改了[Install]段要重新enable因为符号链接已经建好了不重新建立就不会反映新配置。为什么systemctl disable之后程序还在跑因为disable只是删链接不动当前进程。所以完整的“下线”是systemctl disable --now mysvc。顺便说一个诊断小技巧systemctl is-enabled mysvc看是否已登记systemctl is-active mysvc看当前是否在跑两个是独立维度能组合出四种状态别混。3.4 落地四步顺序不能乱写完单元文件之后我固定走这四步# 1. 重新加载单元配置 sudo systemctl daemon-reload # 2. 登记开机自启 sudo systemctl enable mysvc.service # 3. 立刻启动一次 sudo systemctl start mysvc.service # 4. 看状态和日志 sudo systemctl status mysvc.service sudo journalctl -u mysvc.service -n 50 --no-pager第一步不能省。第二步和第三步可以合成systemctl enable --now mysvc.service很省事。第四步的status输出会告诉你三件关键信息Loaded行里的单元文件路径确认读的是你写的那份、Active行里的状态和启动时间、以及最后 10 行日志。验证开机自启是否真的生效只有一种可靠办法真的重启一次。systemctl enable成功不代表启动时不会失败。想少重启一次的话可以用systemctl start multi-user.target之类的方式模拟但依赖关系复杂时结果不准老老实实reboot最靠谱。4. 依赖、顺序、重试让服务真的能自己起来4.1 After 和 Wants 是两件不同的事别写一个就完事这两个字段经常被混用效果差很远。AfterB只描述时序如果 A 和 B 都要启动先起 B 再起 A。它不表示“我要 B”如果 B 没被任何东西拉起After完全不起作用。WantsB描述依赖意愿我要 B把它也拉起来。如果 B 起失败了A 照常启动。RequiresB是强依赖我要 B它起不来我就也不起。所以“等网络就绪再启动”正确写法是两条一起Afternetwork-online.target Wantsnetwork-online.target只写After的话如果系统里没人拉network-online.target这个 target 可能根本不激活你的等待就落空了。这个组合我几乎是条件反射地写尤其是任何需要对外通信的服务。还有一个高频误区很多人写Afternetwork.target以为这样就是“等网络好了”。不是的。network.target只表示“网络配置子系统已经启动”网卡可能还没拿到 IPDNS 可能还不能用。真正表示“网络可用”的是network-online.target。这两个名字差一个词行为差一个数量级。4.2 数据库连不上就退出那要处理好重试的节奏服务依赖数据库开机时数据库可能比你起得还慢。如果程序的设计是“连不上就退出”配合Restarton-failure其实也能work——它退出systemd 等 5 秒再拉直到数据库就绪。但要小心两件事。第一重启风暴。如果你的RestartSec是 1 秒程序启动到失败只要 0.5 秒那一分钟能重启几十次日志刷屏CPU 也被吃掉。这就是StartLimitIntervalSec和StartLimitBurst的用武之地StartLimitIntervalSec60 StartLimitBurst5含义是在 60 秒的窗口内最多允许启动 5 次。超过之后 systemd 会放弃单元进入failed状态并停止重试。这既是保护也是信号——它明确告诉你“这个服务不是偶发失败是真起不来”该去查日志了。这两个参数的值怎么定我的经验是RestartSec设 5 到 10 秒StartLimitIntervalSec设 60StartLimitBurst设 5。这样最坏情况下 60 秒内尝试 5 次总共给了一分钟左右的恢复窗口对“依赖服务慢启动”这个场景够用又不会把机器拖死。如果依赖的服务启动特别慢比如要做数据恢复的数据库把RestartSec拉到 15 秒、StartLimitBurst提到 10。第二进程内重试优先。如果程序本身能处理“连不上就等一会再试”那就在程序里做比让 systemd 反复重启进程代价小得多。每一次重启都意味着重新加载、重新初始化成本远高于在进程内 sleep 后重连。4.3 时间预算启动超时和停止超时默认情况下systemd给每个服务的启动时间是 90 秒DefaultTimeoutStartSec停止时间是 90 秒。超过就强制SIGKILL。如果你的程序启动就要两分钟加载大模型、预热缓存、跑数据校验会碰到“启动到 90 秒被杀然后重启再被杀”的循环。解决方法是显式放宽TimeoutStartSec300 TimeoutStopSec60注意Typeoneshot的服务默认没有启动超时限制无限等这点和其他类型不一样别搞混。停止超时这件事更微妙。程序收到SIGTERM之后如果 60 秒还没退会被SIGKILL强杀。所以你的程序必须正确处理SIGTERM停止接收新请求、等手上的活干完、释放资源、退出。很多程序只处理了CtrlC的SIGINT没处理SIGTERM结果systemctl stop永远是“等 90 秒然后强杀”日志里全是诡异的截断。5. 排查实录起不来的十有八九是这几个原因5.1 先看状态再看日志顺序别反遇到“服务起不来”我的固定动作是两条命令systemctl status mysvc.service --no-pager -l journalctl -u mysvc.service -b --no-pager -n 100status的输出里Loaded行告诉你读的是哪个文件、是否enabledActive行告诉你当前状态和退出码Process行显示主进程 PID 和退出码最后是最近日志。-l参数让长行不被截断这个必须加不然关键的报错信息正好被省略号吃掉。journalctl -u加-b是只看本次启动的日志避免翻到上次重启前的旧记录。加-n 100限制行数。想看更早的就去掉-b想看实时刷新的用-f想按时间过滤用--since 2024-01-01 10:00。退出码是最有价值的信息。exit code 203意味着ExecStart指定的可执行文件找不到或不可执行exit code 1一般是程序自己报错退出status143是被SIGTERM结束status137是SIGKILL通常是被 OOM 或者启动超时干掉。5.2 典型故障速查表下面这张表是我这些年整理出来的基本覆盖了九成的情况现象退出码/日志特征根因处理启动即失败status203/EXECExecStart路径错或无执行权限用绝对路径chmod x提示命令不存在No such file or directoryPATH里缺目录写绝对路径或补EnvironmentPATH程序自己找不到配置FileNotFoundError工作目录是/加WorkingDirectory起来了但立刻重启循环反复Started/Stopped程序 daemonize 了改Typeforking加PIDFile网络相关报错连接超时没等网络就绪加AfterWants的network-online.target端口被占用Address already in use旧进程没退干净ss -lntp查kill -9权限不足Permission deniedUser选错或文件属主不对检查目录属主和User一致性正常停止被判失败status143JVM 信号退出码SuccessExitStatus143内存占用不断上涨OOM killed内存限制或泄漏MemoryMax限制或查代码改了配置没效果行为不变没daemon-reload执行systemctl daemon-reload5.3 三个容易被忽略的细节权限的传递问题。你配了Userappuser程序能以该身份启动但它要写的目录可能属于root。症状是程序启动成功一写日志就Permission denied然后退出。所以配完User之后记得把工作目录、日志目录、数据目录的属主改成同一个用户chown -R appuser:appuser /opt/myapp。SELinux 或 AppArmor 的拦截。在某些开启了强制访问控制的发行版上你的自定义路径可能不在策略允许范围内表现为“手动跑没问题systemd 起不来”。判断方法是dmesg | grep -i denied或者临时设成宽容模式再试。这属于我自己踩过但很少在文档里被提及的一类。单元文件里的 % 要转义。ExecStart里如果包含%systemd 会把它当成变量展开符%i、%n都是它认识的。日志里出现莫名的截断检查一下是不是有未转义的%需要写成%%。注意排查时不要一上来就改配置。先看清status和日志说了什么再决定改哪一行。我看到太多人一遇到失败就凭感觉在单元里加东西最后加了五六个字段问题还在只是被掩盖了。6. 几个进阶场景顺手记一下6.1 用户级服务与 lingering有些程序只需要在某个用户登录后运行不需要系统级常驻。这时候可以写用户级单元放在~/.config/systemd/user/用systemctl --user enable --now mysvc管理。好处是不需要 root、环境变量继承用户会话、权限天然隔离。陷阱在于用户级服务默认随用户会话启动和退出用户一登出服务就停了。想让它脱离会话长期运行需要开启lingeringsudo loginctl enable-linger appuser这条命令的效果是即使用户不登录系统也会为该用户启动并维持用户级服务。如果你发现“我--user起的服务SSH 断开就没了”就是缺这一步。6.2 rc.local 和 reboot 的正确用法前面说了它们不适合守护进程但作为兜底手段还是要知道怎么用。rc.local现在在多数发行版里是被rc-local.service包着跑的需要满足两个条件/etc/rc.local文件存在且具有执行权限。内容以#!/bin/bash开头末尾必须exit 0否则服务会被判定失败。它适合做那种“必须在多用户启动之后、但不需要守护”的动作。reboot就一行reboot /opt/scripts/warmup.sh /var/log/warmup.log 21。注意重定向必须写否则输出进mail队列或者直接丢掉。它最大的问题是执行时机不可控某些情况下网络还没起来脚本里如果依赖网络就会失败。适合放“失败了也无所谓”的任务。6.3 容器化服务的启动别硬塞进宿主机单元现在很多服务跑在容器里有人图省事写一个systemd单元ExecStart/usr/bin/docker start mycontainer。这种写法能跑但有个隐患docker start是“让已有容器继续跑”容器如果被删了、镜像更新了这条命令就失效了。更稳妥的做法有两种。一是直接用docker run作为ExecStart把容器当普通进程管理Restartalways交给 systemd 而不是 docker 的--restart——两套重启策略同时开着容易出现“谁都在拉、谁都在等”的混乱。二是让容器运行时的守护进程自己负责宿主机上只保证那个守护进程被 systemd 拉起。关键是别让两套机制同时管一件事。要么 systemd 管容器进程要么容器的守护进程管容器选一个另一个关掉对应对接。6.4 配置备份与版本化单元文件是配置配置就该进版本库。我的习惯是在仓库里放一个deploy/systemd/目录每个.service文件都在里面配一个install.sh负责 cp 到/etc/systemd/system/、daemon-reload、enable。这样换机器、重装系统、交接给同事都只是跑一遍脚本的事。顺带一句/etc/sysconfig/下的环境变量文件也应该一起版本化。这两类文件共同构成“服务怎么跑”的完整定义只存一半没有意义。我在实际操作中的体会是开机自启动这件事真正的难点不在语法而在把运行环境想清楚。你在终端里能跑起来是因为你带着一整套隐式的上下文当前目录、你的PATH、你export的变量、你登录时的ulimit。写进服务单元等于要把这套上下文显式地重建一遍。所以每次写完单元文件我都会对着终端里跑通的那条命令逐项核对三件事工作目录对不对、环境变量缺不缺、执行用户的权限够不够。这三个对齐了剩下的大多是时序问题加两行依赖声明就能解决。最后再分享一个我常用的调试小技巧如果实在定位不了问题把ExecStart临时改成一个脚本脚本第一行写set -x然后把当时的环境变量、pwd、id全部打印到文件里。跑一次之后看那个文件比对着文档猜快十倍。