1. 动手前先想清楚你要的是“开机启动”还是“登录启动”很多刚接触 Linux 的朋友搜“Linux Ubuntu 开机启动程序”时只看到一堆互相打架的教程有人说用 crontab有人说写 systemd还有人翻出祖传的 rc.local。看得越多越懵最后随便选一个照着抄结果不是起不来就是起来了却没按预期工作。这个问题的根源在于概念没拆开。在 Ubuntu 里“程序在开机时自动运行”其实分三个完全不同的时机系统启动阶段内核加载完成、服务管理器 systemd 开始拉起系统服务。这个阶段通常没有图形桌面也没有你登录进去的用户环境。用户登录会话启动你输完用户名密码进入桌面或者通过 SSH 连上服务器之后系统才会准备你的用户环境、设置环境变量、挂载你个人的配置。终端会话启动哪怕你已经登录了每次打开一个新的终端窗口也会触发一套独立的初始化流程。三种时机对应完全不同的机制。你的程序如果是一台服务器上的后台服务那它应该在“系统启动阶段”跑起来由 systemd 接管生命周期如果你的程序是桌面软件那它应该在“用户登录后”被拉起否则连图形界面都访问不到如果你只是想每次打开终端时自动执行某个命令那又是另一种玩法。做任何配置之前先问自己三个问题第一这个程序需不需要图形界面需要的话基本可以放弃纯 systemd 系统服务方案除非你额外配置 DISPLAY 等环境变量否则程序会因为没有显示设备而直接崩溃。第二它需不需要依赖网络或其他服务数据库、Docker、网络挂载这类依赖直接开机拉起通常会失败因为依赖还没就绪。你必须配置等待条件。第三如果程序挂了要不要自动重启系统服务的答案通常是“要”cron 则完全不管这回事进程死了就是死了。这三个问题决定了你最终用哪种方案。我下面会把四种主流的终端配置方式全部过一遍然后给你一张选型对照表你直接对号入座就行。2. 正统做法 systemd 服务写 Unit 文件的完整过程2.1 服务文件写到哪里以及为什么现代 Ubuntu 从 15.04 起就全面改用 systemd 作为 init 系统开机启动程序的正规方式就是写一个 service 文件。service 文件本质是一段描述“程序是什么、怎么启动、怎么停止、什么时候启动”的配置systemd 根据它来管理进程。service 文件放哪个目录有讲究。系统级服务的标准位置是/etc/systemd/system/用户级服务则放在~/.config/systemd/user/。绝大多数场景我只推荐你写系统服务因为用户服务的日志管理、开机时机的控制逻辑更复杂对新手不友好。只有一种例外你的程序需要访问图形桌面的资源比如要操作 GNOME 的剪贴板或者读取桌面环境的配置这时候写用户服务反而是更干净的选择。一个最简单的系统服务文件长这样[Unit] DescriptionMy Custom Startup Program Documentationman:systemd.service Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Useryourusername WorkingDirectory/home/yourusername EnvironmentSOME_VAR1 ExecStart/home/yourusername/bin/myscript.sh Restarton-failure RestartSec5 [Install] WantedBymulti-user.target这里每段配置都有它的含义。[Unit]段的Description是给人看的备注Wants和After用于处理依赖顺序。Afternetwork-online.target意思是“在网络服务完全就绪之后再启动我”这对需要联网的程序几乎是刚需不加的话程序可能在网卡还没配好 IP 时就跑起来了然后报连接失败。[Service]段是核心。Typesimple表示这条命令就是主进程systemd 不会等待它 fork 出子进程适合大部分脚本和普通程序。ExecStart是实际要执行的命令注意这里必须写绝对路径不能依赖 PATH 去找。Restarton-failure开启崩溃自动重启RestartSec5表示失败后等 5 秒再拉起这比任何裸奔方式都省心。[Install]段的WantedBymulti-user.target决定了服务在哪个启动目标下被启用。服务器上没有图形界面时多用户模式就是默认目标因此这句话意思是“系统进入正常运行状态时启动我”。2.2 实际操作从新建文件到开机自启新建文件的命令如下直接sudo nano打开编辑即可sudo nano /etc/systemd/system/my-startup.service把上面的模板内容粘贴进去按自己的程序路径和用户名修改然后依次执行sudo systemctl daemon-reload sudo systemctl enable my-startup.service sudo systemctl start my-startup.service顺序不要乱。daemon-reload让 systemd 重新扫描磁盘上的 service 文件列表否则它不认新文件。enable是创建开机自启的符号链接start是立即启动一次。测试服务是否正常用这个命令systemctl status my-startup.service你会看到服务的当前状态、主进程 PID、最近的内存占用和最近几条日志。如果程序没起来优先看这里不需要到处猜。看完整历史日志用journalctl这是我最常用的排查方式journalctl -u my-startup.service -b -n 50-u指定服务名-b只看本次开机以来的日志-n 50显示最后 50 行。如果程序闪退了这里一定留有原因。2.3 systemd 用户服务让图形程序也能开机自启前面提到系统级别的 systemd 服务启动时没有图形环境桌面程序直接跑会报错。但 Ubuntu 登录进桌面之后其实会创建一个和管理员权限隔离的“用户 systemd 实例”。你可以在~/.config/systemd/user/下写服务文件由这个用户实例在登录后自动拉起。操作步骤和系统服务几乎一样mkdir -p ~/.config/systemd/user nano ~/.config/systemd/user/my-gui-app.service文件内容示例[Unit] DescriptionMy GUI Application [Service] Typesimple ExecStart/home/yourusername/bin/gui-app EnvironmentDISPLAY:0 Restarton-failure [Install] WantedBydefault.target这里多了一个手动加的EnvironmentDISPLAY:0直接把显示服务器地址告诉程序解决找不到显示的报错。保存后执行systemctl --user daemon-reload systemctl --user enable --now my-gui-app.service注意命令要加--user参数否则操作的是系统服务。需要提醒的是用户服务只在用户登录后才生效。如果你这个用户从来不登录服务就不会启动。有些服务器环境为了方便传输文件建了个系统账号那就是另一个故事了。3. cron 的 reboot 陷阱短平快但别指望它当守护进程3.1 三行命令配置完毕真的有这么简单有些人嫌 systemd 那一堆配置太啰嗦想少写几个字母于是想出用 cron 的reboot字段。cron 是 Linux 里老牌的任务调度器通常用来执行“每天几点做什么”但它支持一个特殊时间宏reboot含义是系统启动时执行一次对应命令。用法非常简单crontab -e第一次执行会提示你选编辑器选 nano 即可。在文件里加一行reboot /home/yourusername/scripts/startup.sh /home/yourusername/scripts/startup.log 21保存退出完事。脚本会在每次开机时自动执行输出同时写入日志文件。如果 crontab 命令提示命令不存在需要先装 cronsudo apt update sudo apt install cron sudo systemctl enable --now cron3.2 为什么我劝你不要把鸡蛋全放这个篮子里cron 方案看着省事实际操作中坑多得很我在多台机器上踩过一遍每条都说一下。第一个坑cron 环境里几乎没环境变量。你在终端里敲命令能运行是因为终端替你加载了~/.bashrc和/etc/profile把PATH、JAVA_HOME、NVM_DIR这些全设置好了。cron 执行命令时完全不带这些它拿到的 PATH 往往只有/usr/bin:/bin。如果你的程序安装在/usr/local/bin或者用了某个自定义的环境变量开机后就会错得莫名其妙。解决方式是启动时手动 source 环境。第二个坑reboot 触发时机没有任何依赖控制。cron 在系统启动早期就尝试执行任务此时网络可能没通、磁盘可能没挂载、数据库可能没准备好。如果你的脚本是一个需要 MySQL 就绪才能做同步的程序开机大概率跑空。所以常见补救手段是脚本开头先sleep 10之类的硬延时缓冲但这是笨办法机器负载高时照样不保险。第三个坑cron 任务失败后不会有任何自动拉起。程序崩了就是崩了没有任何守护机制。想要看日志只能自己重定向输出就像上面那行的 log 21不重定向的话你连去哪儿找错误都不知道。第四个坑reboot 只在系统完全启动时触发一次。这个“完全启动”跟 systemd 定义的启动完成还不太一样某些情况下 cron 服务的启动顺序可能在其他服务之前程序就会比预期更早地跑起来。结论很直接cron 用在自己写的、不依赖外部环境的、本身足够健壮的脚本上最合适。比如写一个开机把临时目录清空的脚本或者把系统信息落到日志里的脚本这类“一次性、可失败、后果不严重”的任务交给 cron 中午都是良配。把它当作正式服务方案就是大材小用还容易出事。4. bashrc 与 profile这种情况才适合放启动命令4.1 三个配置文件的分工很多人搞反了终端用户和程序员的启发式做法通常是把启动命令往.bashrc里一塞然后那句话就开始在每次打开终端时执行。这套逻辑不完全错但你得先搞明白.bashrc、.profile、.bash_profile的区别否则会出现“明明放了命令却不生效”的现象。Linux 的 bash shell 在启动时按不同场景读取不同文件登录 shell输密码进系统、SSH 远程连接会依次读取/etc/profile、~/.profile、~/bash_profile。非登录交互 shell在桌面里打开一个终端窗口只读取~/.bashrc。而 Ubuntu 的默认设置是~/.profile里有一行代码在登录 shell 启动时主动 source~/.bashrc。所以实际操作中Ubuntu 的.bashrc无论哪种 shell 都会被执行。这也就为什么大家习惯把东西塞进.bashrc。但是注意这两个文件是给“终端 shell”做初始化的不是通用的“开机启动”位置。放在里面的命令只会在打开新终端窗口时执行每个新标签页都会触发一次。4.2 适合放 .bashrc 的程序类型和写法则什么程序适合放在.bashrc答案是它本身就依赖终端。例如我想让hello命令开箱即用每次新终端都能直接用我想把手写的一个菜单脚本做成开机提示打开终端先显示系统资源状态我想自动加载某个开发环境比如每次终端都自动进入虚拟环境。写入方式是编辑~/.bashrcnano ~/.bashrc在文件末尾加# 开机后打开终端自动执行 if [ -f /home/yourusername/bin/tmux-run.sh ]; then /home/yourusername/bin/tmux-run.sh fi加if判断是一种好习惯文件存在才执行避免脚本被误删时报错。如果你希望命令在后台跑不阻塞终端记得结尾加或者用nohup配合nohup /home/yourusername/bin/monitor.sh /dev/null 21 说三个实战坑。第一个重复执行。每次开终端都会执行一次.bashrc命令如果一遍脚本启动一个进程开多了终端就会拉起一堆重复进程。所以脚本内部要写防重复的逻辑至少要有 pid 文件检查。第二个只对一个用户生效。.bashrc是每个用户独立的如果希望这台机器上所有用户打开终端都执行就放到/etc/bash.bashrc或/etc/profile.d/下面写个脚本。第三个桌面程序放进 .bashrc 是死路。就算里面写了gedit之类的图形程序它也只能在终端打开时启动并不会在你登录桌面时响应。新手常犯这个错以为是“开机启动”其实只是“终端启动”。5. rc.local 老方法复活到底还能不能用十几年前没有 systemd 的时候想开机执行命令一般往/etc/rc.local里写这个文件是本地系统开机进入多用户模式前统一执行的脚本。systemd 时代到了之后Ubuntu 默认不再执行 rc.local但保留了兼容能力需要手动激活。如果你在旧服务器上迁过来或者看到教程里写着/etc/rc.local操作思路是这样的先检查rc-local.service是否存在systemctl status rc-local.service如果服务存在但是masked禁用伪装态要先取消禁用。如果服务不存在需要手动写一个服务文件来激活sudo nano /etc/systemd/system/rc-local.service写入[Unit] Description/etc/rc.local Compatibility ConditionPathExists/etc/rc.local [Service] Typeforking ExecStart/etc/rc.local start TimeoutSec0 RemainAfterExityes GuessMainPIDno然后确保/etc/rc.local文件存在并具有可执行权限sudo touch /etc/rc.local sudo chmod x /etc/rc.local sudo nano /etc/rc.local文件开头必须写#!/bin/bash结尾留一行exit 0中间放你要执行的东西#!/bin/bash # 开机后启动我们的程序 /opt/myapp/bin/server start exit 0最后sudo systemctl daemon-reload sudo systemctl enable rc-local sudo systemctl start rc-local.servicerc.local 的定位很尴尬它能在开机早期执行但没有细粒度的依赖控制、没有环境变量、没有日志机制进程管理更是零。现在还在用 rc.local 的情况基本是那些老系统的运维惯性没改完或者某些程序的安装文档死活不更新。新机器新服务我的判断是花十分钟读一下 systemd 的 Unit 文件带来的收益远超继续用 rc.local 节省的时间。6. 四种方案选型表对号入座别再犹豫了我已经把最常见的四种方案都铺开了最后给你一张表收个口。表里列了关键差异看完基本就不用纠结了。对比维度systemd 服务crontab reboot.bashrcrc.local推荐指数1-55321触发时机系统启动/登录会话系统启动早期打开终端时系统启动早期需要图形界面系统服务不行用户服务可以不行不行不行崩溃自动重启自带 Restart 字段无无无依赖顺序控制有After/Wants无无无环境变量可配置 EnvironmentFile几乎没有继承用户环境几乎没有日志journalctl 集中管理需手动重定向终端输出需手动重定向适合场景任何正式的后台服务、桌面应用简单的一次性脚本终端工具自动加载老系统兼容留痕我的选型建议你写的是一个长期运行的服务程序比如 Web 服务、跑批任务、守护进程那就应该用 systemd没有替代品。它能管理依赖、能自动重启、能收集日志这才是“运行一个程序”的正规姿势。你写的是一个“开机后跑一遍就不用管”的脚本比如同步时间、清理缓存、上报开机信息用 crontab 的reboot就够了别再绕一圈去写 service 文件。你只是想让自己在终端里更方便打开即用那就去改.bashrc但别把它当成开机启动工具它就是终端配置文件。至于 rc.local除非你正在维护的旧机器上有既成流程没法改否则不推荐新写。7. 实测排查程序没启动用四步锁定真凶配置写得再漂亮实操永远有意外。我见过太多用户程序启动失败最后发现是权限、路径、环境变量这三大魔王。这里给你一条完整的排查链路照着走就行。7.1 第一步确认配置有没有真正生效先做状态确认。不同的配置方式用不同命令# systemd 服务 systemctl status 你的服务名.service systemctl is-enabled 你的服务名.service # cron crontab -l | grep reboot # 检查 rc.local 是否启用 systemctl status rc-local.service如果 systemd 显示服务 inactivedead说明它压根没被拉起那问题在 enable 那一步或者是系统还没进入对应 target。这里可以先手动systemctl start 服务名看看能不能手动拉起来如果能就说明配置本身没问题问题出在启动时机。7.2 第二步看日志找程序的真实报错不同方案日志位置完全不同systemd 服务journalctl -u 服务名 -bcrontab如果没有重定向一般会通过邮件发给你或者直接丢进/var/log/syslog.bashrc直接在终端打印报错会显示在打开的那个窗口rc.local和 cron 一样不重定向就什么都没有我见过最典型的错误输出有两种Exec format error和Permission denied。第一种说明脚本没有#!/bin/bash头或者解释器不对第二种说明脚本没有可执行权限。这两种问题第一反应就是检查文件头和权限。7.3 第三步模拟你的启动环境这一步大多数人不做但它超级管用。cron 和 rc.local 的环境变量几乎为空所以你要模拟它们的环境来测试脚本。在终端里清空环境后再执行一遍env -i /home/yourusername/bin/startup.sh看到没env -i会让这个命令在一个没有继承任何环境变量的空环境里跑。如果脚本这时候报“找不到命令”或“路径不存在”原因就清楚了。你也可以用which 你的命令查一下把命令的完整路径写进脚本里不要依赖 PATH 解析。7.4 第四步给脚本加启动日志和防重这也是我坚持推荐所有启动脚本都用的一种保险写法。脚本开头加两行#!/bin/bash exec /var/log/my-startup.log 21 echo $(date) 这样每次执行时都会先把日志追加到固定文件里并且记录时间戳。排查时直接tail -f /var/log/my-startup.log就能实时看到脚本到底走没走到哪一步。同时写防重复的逻辑原理很简单启动前检查 pid 文件文件存在且进程在跑就不启动新的。PIDFILE/var/run/myapp.pid if [ -f $PIDFILE ]; then echo 已经有一个实例在运行退出 exit 0 fi echo $$ $PIDFILE这种写法对系统服务、cron 都一样适用能省去很多“为什么有八个进程”的尴尬。整套排查思路走下来其实百分之八十的问题都集中在三处路径、权限、环境。只要在这三个点上多花点工夫开机启动基本不会出大乱子。最后分享一点我的个人经验新建机器时我通常会把 systemd 服务当成默认方案然后顺手在脚本里加上日志和防重这两件事做好后面运维能省一半心。如果你今天只是在测试环境想快速验证某个想法用 crontab 无可厚非但如果这台机器要跑一年两年甚至更久花一杯咖啡的时间把 systemd 这关过了那点前期投入后面都是赚回来的。
Linux开机启动：systemd/cron/rc.local/.bashrc
1. 动手前先想清楚你要的是“开机启动”还是“登录启动”很多刚接触 Linux 的朋友搜“Linux Ubuntu 开机启动程序”时只看到一堆互相打架的教程有人说用 crontab有人说写 systemd还有人翻出祖传的 rc.local。看得越多越懵最后随便选一个照着抄结果不是起不来就是起来了却没按预期工作。这个问题的根源在于概念没拆开。在 Ubuntu 里“程序在开机时自动运行”其实分三个完全不同的时机系统启动阶段内核加载完成、服务管理器 systemd 开始拉起系统服务。这个阶段通常没有图形桌面也没有你登录进去的用户环境。用户登录会话启动你输完用户名密码进入桌面或者通过 SSH 连上服务器之后系统才会准备你的用户环境、设置环境变量、挂载你个人的配置。终端会话启动哪怕你已经登录了每次打开一个新的终端窗口也会触发一套独立的初始化流程。三种时机对应完全不同的机制。你的程序如果是一台服务器上的后台服务那它应该在“系统启动阶段”跑起来由 systemd 接管生命周期如果你的程序是桌面软件那它应该在“用户登录后”被拉起否则连图形界面都访问不到如果你只是想每次打开终端时自动执行某个命令那又是另一种玩法。做任何配置之前先问自己三个问题第一这个程序需不需要图形界面需要的话基本可以放弃纯 systemd 系统服务方案除非你额外配置 DISPLAY 等环境变量否则程序会因为没有显示设备而直接崩溃。第二它需不需要依赖网络或其他服务数据库、Docker、网络挂载这类依赖直接开机拉起通常会失败因为依赖还没就绪。你必须配置等待条件。第三如果程序挂了要不要自动重启系统服务的答案通常是“要”cron 则完全不管这回事进程死了就是死了。这三个问题决定了你最终用哪种方案。我下面会把四种主流的终端配置方式全部过一遍然后给你一张选型对照表你直接对号入座就行。2. 正统做法 systemd 服务写 Unit 文件的完整过程2.1 服务文件写到哪里以及为什么现代 Ubuntu 从 15.04 起就全面改用 systemd 作为 init 系统开机启动程序的正规方式就是写一个 service 文件。service 文件本质是一段描述“程序是什么、怎么启动、怎么停止、什么时候启动”的配置systemd 根据它来管理进程。service 文件放哪个目录有讲究。系统级服务的标准位置是/etc/systemd/system/用户级服务则放在~/.config/systemd/user/。绝大多数场景我只推荐你写系统服务因为用户服务的日志管理、开机时机的控制逻辑更复杂对新手不友好。只有一种例外你的程序需要访问图形桌面的资源比如要操作 GNOME 的剪贴板或者读取桌面环境的配置这时候写用户服务反而是更干净的选择。一个最简单的系统服务文件长这样[Unit] DescriptionMy Custom Startup Program Documentationman:systemd.service Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Useryourusername WorkingDirectory/home/yourusername EnvironmentSOME_VAR1 ExecStart/home/yourusername/bin/myscript.sh Restarton-failure RestartSec5 [Install] WantedBymulti-user.target这里每段配置都有它的含义。[Unit]段的Description是给人看的备注Wants和After用于处理依赖顺序。Afternetwork-online.target意思是“在网络服务完全就绪之后再启动我”这对需要联网的程序几乎是刚需不加的话程序可能在网卡还没配好 IP 时就跑起来了然后报连接失败。[Service]段是核心。Typesimple表示这条命令就是主进程systemd 不会等待它 fork 出子进程适合大部分脚本和普通程序。ExecStart是实际要执行的命令注意这里必须写绝对路径不能依赖 PATH 去找。Restarton-failure开启崩溃自动重启RestartSec5表示失败后等 5 秒再拉起这比任何裸奔方式都省心。[Install]段的WantedBymulti-user.target决定了服务在哪个启动目标下被启用。服务器上没有图形界面时多用户模式就是默认目标因此这句话意思是“系统进入正常运行状态时启动我”。2.2 实际操作从新建文件到开机自启新建文件的命令如下直接sudo nano打开编辑即可sudo nano /etc/systemd/system/my-startup.service把上面的模板内容粘贴进去按自己的程序路径和用户名修改然后依次执行sudo systemctl daemon-reload sudo systemctl enable my-startup.service sudo systemctl start my-startup.service顺序不要乱。daemon-reload让 systemd 重新扫描磁盘上的 service 文件列表否则它不认新文件。enable是创建开机自启的符号链接start是立即启动一次。测试服务是否正常用这个命令systemctl status my-startup.service你会看到服务的当前状态、主进程 PID、最近的内存占用和最近几条日志。如果程序没起来优先看这里不需要到处猜。看完整历史日志用journalctl这是我最常用的排查方式journalctl -u my-startup.service -b -n 50-u指定服务名-b只看本次开机以来的日志-n 50显示最后 50 行。如果程序闪退了这里一定留有原因。2.3 systemd 用户服务让图形程序也能开机自启前面提到系统级别的 systemd 服务启动时没有图形环境桌面程序直接跑会报错。但 Ubuntu 登录进桌面之后其实会创建一个和管理员权限隔离的“用户 systemd 实例”。你可以在~/.config/systemd/user/下写服务文件由这个用户实例在登录后自动拉起。操作步骤和系统服务几乎一样mkdir -p ~/.config/systemd/user nano ~/.config/systemd/user/my-gui-app.service文件内容示例[Unit] DescriptionMy GUI Application [Service] Typesimple ExecStart/home/yourusername/bin/gui-app EnvironmentDISPLAY:0 Restarton-failure [Install] WantedBydefault.target这里多了一个手动加的EnvironmentDISPLAY:0直接把显示服务器地址告诉程序解决找不到显示的报错。保存后执行systemctl --user daemon-reload systemctl --user enable --now my-gui-app.service注意命令要加--user参数否则操作的是系统服务。需要提醒的是用户服务只在用户登录后才生效。如果你这个用户从来不登录服务就不会启动。有些服务器环境为了方便传输文件建了个系统账号那就是另一个故事了。3. cron 的 reboot 陷阱短平快但别指望它当守护进程3.1 三行命令配置完毕真的有这么简单有些人嫌 systemd 那一堆配置太啰嗦想少写几个字母于是想出用 cron 的reboot字段。cron 是 Linux 里老牌的任务调度器通常用来执行“每天几点做什么”但它支持一个特殊时间宏reboot含义是系统启动时执行一次对应命令。用法非常简单crontab -e第一次执行会提示你选编辑器选 nano 即可。在文件里加一行reboot /home/yourusername/scripts/startup.sh /home/yourusername/scripts/startup.log 21保存退出完事。脚本会在每次开机时自动执行输出同时写入日志文件。如果 crontab 命令提示命令不存在需要先装 cronsudo apt update sudo apt install cron sudo systemctl enable --now cron3.2 为什么我劝你不要把鸡蛋全放这个篮子里cron 方案看着省事实际操作中坑多得很我在多台机器上踩过一遍每条都说一下。第一个坑cron 环境里几乎没环境变量。你在终端里敲命令能运行是因为终端替你加载了~/.bashrc和/etc/profile把PATH、JAVA_HOME、NVM_DIR这些全设置好了。cron 执行命令时完全不带这些它拿到的 PATH 往往只有/usr/bin:/bin。如果你的程序安装在/usr/local/bin或者用了某个自定义的环境变量开机后就会错得莫名其妙。解决方式是启动时手动 source 环境。第二个坑reboot 触发时机没有任何依赖控制。cron 在系统启动早期就尝试执行任务此时网络可能没通、磁盘可能没挂载、数据库可能没准备好。如果你的脚本是一个需要 MySQL 就绪才能做同步的程序开机大概率跑空。所以常见补救手段是脚本开头先sleep 10之类的硬延时缓冲但这是笨办法机器负载高时照样不保险。第三个坑cron 任务失败后不会有任何自动拉起。程序崩了就是崩了没有任何守护机制。想要看日志只能自己重定向输出就像上面那行的 log 21不重定向的话你连去哪儿找错误都不知道。第四个坑reboot 只在系统完全启动时触发一次。这个“完全启动”跟 systemd 定义的启动完成还不太一样某些情况下 cron 服务的启动顺序可能在其他服务之前程序就会比预期更早地跑起来。结论很直接cron 用在自己写的、不依赖外部环境的、本身足够健壮的脚本上最合适。比如写一个开机把临时目录清空的脚本或者把系统信息落到日志里的脚本这类“一次性、可失败、后果不严重”的任务交给 cron 中午都是良配。把它当作正式服务方案就是大材小用还容易出事。4. bashrc 与 profile这种情况才适合放启动命令4.1 三个配置文件的分工很多人搞反了终端用户和程序员的启发式做法通常是把启动命令往.bashrc里一塞然后那句话就开始在每次打开终端时执行。这套逻辑不完全错但你得先搞明白.bashrc、.profile、.bash_profile的区别否则会出现“明明放了命令却不生效”的现象。Linux 的 bash shell 在启动时按不同场景读取不同文件登录 shell输密码进系统、SSH 远程连接会依次读取/etc/profile、~/.profile、~/bash_profile。非登录交互 shell在桌面里打开一个终端窗口只读取~/.bashrc。而 Ubuntu 的默认设置是~/.profile里有一行代码在登录 shell 启动时主动 source~/.bashrc。所以实际操作中Ubuntu 的.bashrc无论哪种 shell 都会被执行。这也就为什么大家习惯把东西塞进.bashrc。但是注意这两个文件是给“终端 shell”做初始化的不是通用的“开机启动”位置。放在里面的命令只会在打开新终端窗口时执行每个新标签页都会触发一次。4.2 适合放 .bashrc 的程序类型和写法则什么程序适合放在.bashrc答案是它本身就依赖终端。例如我想让hello命令开箱即用每次新终端都能直接用我想把手写的一个菜单脚本做成开机提示打开终端先显示系统资源状态我想自动加载某个开发环境比如每次终端都自动进入虚拟环境。写入方式是编辑~/.bashrcnano ~/.bashrc在文件末尾加# 开机后打开终端自动执行 if [ -f /home/yourusername/bin/tmux-run.sh ]; then /home/yourusername/bin/tmux-run.sh fi加if判断是一种好习惯文件存在才执行避免脚本被误删时报错。如果你希望命令在后台跑不阻塞终端记得结尾加或者用nohup配合nohup /home/yourusername/bin/monitor.sh /dev/null 21 说三个实战坑。第一个重复执行。每次开终端都会执行一次.bashrc命令如果一遍脚本启动一个进程开多了终端就会拉起一堆重复进程。所以脚本内部要写防重复的逻辑至少要有 pid 文件检查。第二个只对一个用户生效。.bashrc是每个用户独立的如果希望这台机器上所有用户打开终端都执行就放到/etc/bash.bashrc或/etc/profile.d/下面写个脚本。第三个桌面程序放进 .bashrc 是死路。就算里面写了gedit之类的图形程序它也只能在终端打开时启动并不会在你登录桌面时响应。新手常犯这个错以为是“开机启动”其实只是“终端启动”。5. rc.local 老方法复活到底还能不能用十几年前没有 systemd 的时候想开机执行命令一般往/etc/rc.local里写这个文件是本地系统开机进入多用户模式前统一执行的脚本。systemd 时代到了之后Ubuntu 默认不再执行 rc.local但保留了兼容能力需要手动激活。如果你在旧服务器上迁过来或者看到教程里写着/etc/rc.local操作思路是这样的先检查rc-local.service是否存在systemctl status rc-local.service如果服务存在但是masked禁用伪装态要先取消禁用。如果服务不存在需要手动写一个服务文件来激活sudo nano /etc/systemd/system/rc-local.service写入[Unit] Description/etc/rc.local Compatibility ConditionPathExists/etc/rc.local [Service] Typeforking ExecStart/etc/rc.local start TimeoutSec0 RemainAfterExityes GuessMainPIDno然后确保/etc/rc.local文件存在并具有可执行权限sudo touch /etc/rc.local sudo chmod x /etc/rc.local sudo nano /etc/rc.local文件开头必须写#!/bin/bash结尾留一行exit 0中间放你要执行的东西#!/bin/bash # 开机后启动我们的程序 /opt/myapp/bin/server start exit 0最后sudo systemctl daemon-reload sudo systemctl enable rc-local sudo systemctl start rc-local.servicerc.local 的定位很尴尬它能在开机早期执行但没有细粒度的依赖控制、没有环境变量、没有日志机制进程管理更是零。现在还在用 rc.local 的情况基本是那些老系统的运维惯性没改完或者某些程序的安装文档死活不更新。新机器新服务我的判断是花十分钟读一下 systemd 的 Unit 文件带来的收益远超继续用 rc.local 节省的时间。6. 四种方案选型表对号入座别再犹豫了我已经把最常见的四种方案都铺开了最后给你一张表收个口。表里列了关键差异看完基本就不用纠结了。对比维度systemd 服务crontab reboot.bashrcrc.local推荐指数1-55321触发时机系统启动/登录会话系统启动早期打开终端时系统启动早期需要图形界面系统服务不行用户服务可以不行不行不行崩溃自动重启自带 Restart 字段无无无依赖顺序控制有After/Wants无无无环境变量可配置 EnvironmentFile几乎没有继承用户环境几乎没有日志journalctl 集中管理需手动重定向终端输出需手动重定向适合场景任何正式的后台服务、桌面应用简单的一次性脚本终端工具自动加载老系统兼容留痕我的选型建议你写的是一个长期运行的服务程序比如 Web 服务、跑批任务、守护进程那就应该用 systemd没有替代品。它能管理依赖、能自动重启、能收集日志这才是“运行一个程序”的正规姿势。你写的是一个“开机后跑一遍就不用管”的脚本比如同步时间、清理缓存、上报开机信息用 crontab 的reboot就够了别再绕一圈去写 service 文件。你只是想让自己在终端里更方便打开即用那就去改.bashrc但别把它当成开机启动工具它就是终端配置文件。至于 rc.local除非你正在维护的旧机器上有既成流程没法改否则不推荐新写。7. 实测排查程序没启动用四步锁定真凶配置写得再漂亮实操永远有意外。我见过太多用户程序启动失败最后发现是权限、路径、环境变量这三大魔王。这里给你一条完整的排查链路照着走就行。7.1 第一步确认配置有没有真正生效先做状态确认。不同的配置方式用不同命令# systemd 服务 systemctl status 你的服务名.service systemctl is-enabled 你的服务名.service # cron crontab -l | grep reboot # 检查 rc.local 是否启用 systemctl status rc-local.service如果 systemd 显示服务 inactivedead说明它压根没被拉起那问题在 enable 那一步或者是系统还没进入对应 target。这里可以先手动systemctl start 服务名看看能不能手动拉起来如果能就说明配置本身没问题问题出在启动时机。7.2 第二步看日志找程序的真实报错不同方案日志位置完全不同systemd 服务journalctl -u 服务名 -bcrontab如果没有重定向一般会通过邮件发给你或者直接丢进/var/log/syslog.bashrc直接在终端打印报错会显示在打开的那个窗口rc.local和 cron 一样不重定向就什么都没有我见过最典型的错误输出有两种Exec format error和Permission denied。第一种说明脚本没有#!/bin/bash头或者解释器不对第二种说明脚本没有可执行权限。这两种问题第一反应就是检查文件头和权限。7.3 第三步模拟你的启动环境这一步大多数人不做但它超级管用。cron 和 rc.local 的环境变量几乎为空所以你要模拟它们的环境来测试脚本。在终端里清空环境后再执行一遍env -i /home/yourusername/bin/startup.sh看到没env -i会让这个命令在一个没有继承任何环境变量的空环境里跑。如果脚本这时候报“找不到命令”或“路径不存在”原因就清楚了。你也可以用which 你的命令查一下把命令的完整路径写进脚本里不要依赖 PATH 解析。7.4 第四步给脚本加启动日志和防重这也是我坚持推荐所有启动脚本都用的一种保险写法。脚本开头加两行#!/bin/bash exec /var/log/my-startup.log 21 echo $(date) 这样每次执行时都会先把日志追加到固定文件里并且记录时间戳。排查时直接tail -f /var/log/my-startup.log就能实时看到脚本到底走没走到哪一步。同时写防重复的逻辑原理很简单启动前检查 pid 文件文件存在且进程在跑就不启动新的。PIDFILE/var/run/myapp.pid if [ -f $PIDFILE ]; then echo 已经有一个实例在运行退出 exit 0 fi echo $$ $PIDFILE这种写法对系统服务、cron 都一样适用能省去很多“为什么有八个进程”的尴尬。整套排查思路走下来其实百分之八十的问题都集中在三处路径、权限、环境。只要在这三个点上多花点工夫开机启动基本不会出大乱子。最后分享一点我的个人经验新建机器时我通常会把 systemd 服务当成默认方案然后顺手在脚本里加上日志和防重这两件事做好后面运维能省一半心。如果你今天只是在测试环境想快速验证某个想法用 crontab 无可厚非但如果这台机器要跑一年两年甚至更久花一杯咖啡的时间把 systemd 这关过了那点前期投入后面都是赚回来的。
