Linux 系统的启动过程

2 02 2 年，我参与了某城市的一个项目，需要深入了解Linux系统启动流程。
我当时很困惑，看到那些条款和步骤感到有点困惑。
后来我才知道，这个最初的过程其实就像一场接力赛。
每个阶段都有自己的任务，一个都不能错过。

首先出现BIOS。
这就像一个总司令。
它首先执行硬件自检，查看CPU、内存、硬盘等硬件是否处于良好状态。
如果检测到问题，它将通过蜂鸣声或错误代码通知您。
我当时也特地查了一下。
2 02 2 年特定城市的BIOS通常会提供硬件信息，以便操作系统可以了解硬件的详细信息。

然后是MBR，它就像一个指南针，告诉操作系统引导加载程序在哪里。
我记得2 02 2 年某城市的一些系统上，MBR通常存放在硬盘的第一个扇区。
那个地方就像是一个特殊的标记，告诉系统从这里开始。

接下来是 GRUB。
这家伙的实力更加强大。
它不仅可以选择启动哪个操作系统，还可以加载内核。
我记得2 02 2 年某个城市有一个GRUB，它会显示一个菜单，让用户选择要启动的系统。
如果用户没有运行，它会自动加载默认内核。

一旦内核被加载，Init进程就开始发挥作用。
该进程负责启动系统服务并管理执行级别。
我记得2 02 2 年某城市的Init进程，它会读取/etc/inittab文件，判断系统的运行级别，然后启动相应的服务。

最后是执行水平。
该阶段决定了系统启动后的状态。
我记得2 02 2 年某个城市的系统，通常的运行级别是0次关机、1 次单用户模式、3 次多用户模式、5 次GUI模式和6 次重新启动。
用户还可以自定义服务并调整每个运行级别的启动服务。

整个过程就像一场大型游戏。
每个演员都有自己独特的角色和任务，谁都不能缺席。
通过这个过程，我了解了Linux系统的启动是如何从硬件自检开始到用户界面的显示的。
这也让我能够更好的解决启动失败的问题，优化后续项目的启动速度。

linux如何设置程序开机启动后台运行?

当谈到在Linux系统中设置启动和后台程序时，我在这方面有一些经验。
话虽如此，这些方法我都用过，而且每种方法都有自己的方法。

先说第一种方法，这是我早期实现自动化脚本时经常使用的方法。
我记得有一次我编写了一个程序，使用 nohup 命令来监视服务器负载。
在终端中输入 nohup ./your_program & ，程序将在后台运行。
我记得当时默认情况下输出被重定向到 nohup.out 文件，但我认为该文件占用了太多空间，所以我将它直接重定向到 /dev/null，这样就不会创建该文件。
nohup ./your_program > /dev/null 2 >&1 &，就这么简单。

方法2 更简单。
只需在命令末尾添加 & 符号即可，例如 ./your_program &。
这个东西在后台运行没有问题，但缺点是如果关闭终端，程序可能会崩溃。
当我早期测试小脚本时，这很好，但作为一项成熟的服务，它仍然没什么意思。

还有第三种方法。
这必须与工单结合使用。
例如，首先启动一个程序，./your_program &，那么后台作业的ID将显示在终端中。
此时，您可以使用 disown %job_id 从终端运行程序，从而降低崩溃的可能性。
但是，该命令仅对已经启动的后台作业有效，因此需要一定的技巧才能使用它。

至于第四种方法，配置系统服务，我对这种方法比较熟悉。
我记得有一次，我们公司的服务器上有一个日志分析服务，我使用systemd为其配置该服务。
创建一个systemd服务单元文件并将其放置在/etc/systemd/system/目录下，然后定义服务名称、描述、可执行文件等。
使用systemctl Enable your_service命令启用该服务，使其在启动时自动启动，然后使用systemctl start your_service进行测试。
这种方法相当系统化，适合长期运行的服务。

最后一种方法是第五种方法，使用crontab的@reboot选项。
编辑用户的crontab文件，添加一行@reboot /path/to/your_program &，这样程序就会在每次系统重启时自动运行。
此方法适用于不需要复杂依赖管理的简单脚本或服务。

一般情况下，可以使用nohup或者&符号来进行简单的后台操作。
如果您想要稳定性和可靠性，请使用 systemd 或 crontab 的 @reboot 选项。
使用哪一种取决于您的具体需求和系统环境。
这件事没有绝对的好坏，一定要根据实际情况来决定 được.

Linux中如何设置进程开机自启动？systemctl管理服务方法

说实话，用systemctl来管理服务，刚开始做的时候让我很头疼，但是了解之后，发现确实好用。
就拿我之前给公司的爬虫项目来说，它自动启动了。

想一想，这种项目最烦人的是什么？服务器一重启就崩溃。
在使用systemd之前，我尝试过使用rc.local，但是那个东西早已退役了。
后来我改了systemctl，直接在/etc/systemd/system/下创建了一个文件。
例如，我将项目命名为my_crawler.service。

关键是[服务]。
ExecStart应该写绝对路径，不要写相对路径。
有一次我忘记添加绝对路径。
结果服务器扩容，盘符改了，立马就停止启动了。
经过长时间的调试，我差点掉头发了。
所以你要记住：所有路径都必须以/开头。

说到用户，我在这里掉进了一个大洞。
有一次我想让一个低权限用户运行一个脚本，但是我没有在[Service]中写User。
Systemd 默认为 root，它直接填充用户的主目录。
后来发现必须这样写：User=restricted_user，然后sudo chown给予对齐权限。
这确实需要多次确认。

我还建议单独编写环境变量，不要将它们混合在 ExecStart 后面。
我有一个使用第三方库的项目，但是该库的环境变量很奇怪。
最后我在【Service】中添加了Environment=“API_KEY=abc1 2 3 ”，否则启动时会报错。

还有一个细节很容易被忽视，那就是WorkingDirectory。
想一想，如果脚本在临时挂载磁盘上，重启后磁盘消失，脚本肯定无法运行。
当时我为一个项目挂载了NAS，但是重启后无法启动。
更改工作目录后一切正常。

最有趣的部分是检查状态。
我曾经查看过日志，systemctl status直接报错说找不到服务。
结果我丢失了.service - 我花了很长时间才检查并发现它是systemctl status my_crawler。
说实话，每个人都会犯这样的低级错误。

不过说实话，比supervisor好多了。
Supervisor的配置文件非常复杂，而且systemctl逐行阅读时还带有说明，对新手特别友好。
我现在所有新项目都直接使用systemd，甚至配置模板都已经创建好了。
不要忘记给予适当的权限，不要忘记 sudo chmod 6 4 4