哎哟喂，今天又要跟大家唠唠这个Linux的事儿了。说实话，这玩意儿真是让人头大，但是没办法，工作需要，还得硬着头皮学。最近我就碰到个事儿，就是想让服务器重启了以后我的那个小脚本自己跑起来不用我每次都手动去敲命令。你说这要求过分吗？不过分吧？但是Linux这系统吧，它不像Windows那么傻瓜式，你得折腾半天。

有时候我们需要Linux系统在开机的时候自动加载某些脚本或系统服务 主要用三种方式进行这一操作: ln -s 在/etc/rc.d/rc*.d目录...... 哎呀， 反正以前那些老方法什么rc.local的，现在好像都不太好使了大家都说用systemd，用systemctl。行吧，那就学学这个systemctl怎么弄。

不错。 如果您希望某个服务在Linux系统启动时自动运行，可以通过systemctl管理的systemd服务单元实现。 第一步：先把你那个破脚本写好放那儿 先说说啊，你得有个脚本。没有脚本你搞个毛线啊？这个脚本呢，最好是你自己测试过的，能跑的。别到时候服务起不来是主要原因是你脚本本身写错了那就尴尬了。我就干过这事儿，折腾半天发现是脚本里少了个分号，气死个人。 1、 将实际运行的脚本保存至固定路径，比方说：/opt/scripts/ 这个路径你自己定，反正别乱放，放个你自己能找到的地方。/opt这个目录一般就是放这种第三方软件或者脚本的，挺好的。 然后呢，这个脚本得能施行啊。Linux这玩意儿最烦的就是权限了。你明明有文件，就是不让你跑。 2、 赋予施行权限：sudo chmod +x /opt/scripts/ 记得加上sudo，不然你权限不够，它又给你报错。这个+x就是给它加上施行的权力，跟发通行证似的。 还有个事儿特别重要，就是脚本的第一行。很多人写脚本忘了写这个，后来啊systemd根本不知道用什么来跑它。 3、 在脚本首行添加shell解释器声明，比方说：#!/bin/bash 这一行必须得在第一行，前面不能有空行，不然它就不认了。这就好比你进门得先敲门，直接闯进去是不行的。 第二步：写那个什么.service文件， 听着挺高级 脚本有了现在得告诉systemd怎么管这个脚本。这就需要写个配置文件，后缀名是.service。这个文件是关键，写错了就全完蛋。 systemd通过.service文件定义服务行为， 需明确指定施行路径、用户权限及启动依赖关系。该文件必须放置在标准目录下并具备正确权限，才能被systemd识别。 这句话听着挺官方吧？其实就是说你得按它的规矩来不能瞎写。 那这文件放哪儿呢？一般放在/etc/systemd/system/这个目录下面。这个目录是系统管理员自己放服务文件的地方。 1、 使用文本编辑器创建服务文件，比方说：sudo nano /etc/systemd/system/ nano这个编辑器比较简单，适合我这种小白。你要是vi大神，那也随你。记得文件名最好跟你的脚本有点关系，别叫test.service，到时候多了你自己都分不清是谁。 打开文件以后就得往里面填东西了。这东西看着挺吓人，其实也就那么几块。 2、 在文件中写入标准单元配置，包括、和三部分，其中Type=oneshot适用于一次性脚本，RemainAfterExit=yes确保服务状态在脚本施行后仍保持激活。 这几个参数挺关键的。Type=oneshot就是说这脚本跑一遍就完事了不是一直驻留在内存里的那种服务。RemainAfterExit=yes就是说 虽然脚本跑完了但是systemd还得认为这个服务是“开着的”，不然下次你想查状态的时候，它显示是failed或者dead，你会以为没跑成功呢。 写完了以后记得保存啊。nano是Ctrl+X然后Y再回车。别写了一半天忘了保存，关了终端全没了哭都没地儿哭。 3、保存并退出编辑器，确保文件 名为.service且无拼写错误。 拼写错误这事儿太常见了少个字母多个字母，systemd都不认你。 第三步：让systemd知道你改了东西 文件写好了不是马上就能用的。systemd这玩意儿有点懒，它启动的时候把配置都读到内存里去了你后面改了文件，它不知道啊。你得告诉它，“喂，我改东西了你赶紧重新读一下”。 1、 施行重载命令：sudo systemctl daemon-reload 这个命令每次改了.service文件以后都得跑一遍，养成习惯，不然怎么启用都不好使。 有时候呢， 有些脚本或者服务它本来就在那儿了但是它不符合systemd的规范，或者你不想动原来的文件，怕把系统搞坏了。这时候可以用个取巧的办法，叫符号链接。 对于已存在但未遵循systemd规范的脚本， 可通过创建符号链接绕过直接修改原文件，适用于多环境复用场景。 听着是不是挺绕？简单说就是做个快捷方式，指到那个.service文件上。 1、 在/etc/systemd/system/multi-/目录下创建指向服务文件的软链接：sudo ln -sf /etc/systemd/system/ /etc/systemd/system/multi-/ 这个multi-user.target就是多用户模式，也就是我们平时服务器开机进的那个模式。把链接扔这儿，系统启动的时候就会去跑它。 链接做好了也别忘了重载一下。 3、 施行sudo systemctl daemon-reload使链接生效。 哎，这命令是不是跟上面一样？对，就是它，老重要了。 第四步：开启开机自启， 见证奇迹的时刻 前面铺垫了那么多，终于要到这一步了。这一步就是告诉systemd，“下次开机的时候把哥们儿带上”。 2、启用开机自启：sudo systemctl enable 这个enable就是启用的意思。施行完这个命令，它其实就是在那些开机启动的目录里给你建好了软链接。这样下次重启，它就能自动跑起来了。 但是啊，这里有个坑。你改了.service文件，或者建了链接，如果没重载，这enable操作可能会失败，或者没效果。 修改或新增.service文件后 必须通知systemd重新读取配置，否则启用操作会失败。 所以说daemon-reload一定要记在心里！ 还有啊，在enable之前，你最好先看看这文件到底对不对，别瞎enable。 就这？ 2、确保目标.service文件已存在且语法正确。 怎么确保？后面会说怎么查。 第五步：赶紧试试看， 别等重启了才发现不行 真重启服务器来测试吧？万一不行呢？服务器重启多慢啊，而且万一还有别的服务在跑，重启影响多不好。我们可以先手动启动一下看看能不能跑起来。 3、 马上启动服务：sudo systemctl start 这个start就是马上让它跑，不用重启。 跑完了以后得看看它活没活着，是不是正常退出了。 2、检查当前运行状态：sudo systemctl status 这个命令会给你输出一堆信息。如果你看到绿色的Active: active 那就说明成功了。如果是红色的failed，那就赶紧去看日志吧。 启用后需确认服务是否处于enabled状态， 并检查其实际运行后来啊是否符合预期，避免因路径错误或权限问题导致静默失败。 静默失败最可怕，就是它没报错，但是也没干事儿，就像个木头一样。 怎么看是不是enabled了呢？有个专门的命令。 1、查看服务启用状态：sudo systemctl is-enabled 这会直接返回enabled或者disabled。简单粗暴。 服务单元调用的脚本必须具有可施行权限， 并以正确解释器开头，否则systemd将无法启动它。 这句话又强调了一遍权限和解释器，可见这俩事儿多容易出错。大家一定要检查检查再检查！ 第六步：出错了咋办？看日志啊！ 要是按照上面的步骤做了还是不行，那肯定是有问题。Linux下出了问题别瞎猜，看日志是最准的。systemd有个专门的日志系统叫journald，比看那个/var/log/messages要方便点。 3、 查阅最近输出日志：sudo journalctl -u -n 20 --no-pager 这个命令里的-u就是指定看哪个服务的日志，-n 20就是看再说说20行，--no-pager就是直接显示完，别让我按空格翻页，有时候我只想看一眼。 看日志的时候，重点看Error啊、Fail啊这种红色的字。有时候提示很清楚， 比如“No such file or directory”，那就是路径错了；有时候是“Permission denied”，那就是权限不够。照着改就行了。 一下别再踩坑了 说了这么多，其实步骤也就那么几步。写脚本、写service文件、重载、启用、启动、看状态。看着简单，里面的坑真不少。我刚开始弄的时候， 那个service文件里的路径写错了怎么都起不来查了半天日志才发现，原来我把/opt写成了/otp，你说这手残的。 还有那个权限问题，chmod +x千万别忘了。还有那个#!/bin/bash，也别忘了。这些都是细节，但是细节决定成败啊。 总之呢，Linux这东西就是熟能生巧。多弄几次多失败几次也就知道怎么回事儿了。希望这篇烂文章能帮到大家，虽然我写得挺乱的，但是核心意思应该都到了。要是还有不明白的，那就去Google或者百度吧，别光问我，我也是个半吊子。哈哈，祝大家的服务都能顺利开机自启，别半夜被叫起来重启服务器！