本文主要是介绍太坏了，谁这么整活别人的Linux？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
（首发地址：学习日记 https://www.learndiary.com/2024/04/chmod-chattr-systemd/）
大家好，我是“学习日记小店”的店主，在淘宝网活跃着，专注于 Linux 服务。今天我要与大家分享一件之前处理过的 Linux 系统故障案例，这个案例颇具趣味性，我会通过 VirtualBox 虚拟机中的 Ubuntu 20.04 操作系统来重现问题和解决方案。视频演示：【太坏了，谁这么整活别人的Linux？】 https://www.bilibili.com/video/BV1nt421J7Tv/
太坏了，谁这么整活别人的Linux？
事情是这样的，有一次我在面对一台已经出现问题的 Linux 系统时，遇到了一个颇具挑战性的启动故障。为了让各位也能身临其境地体验一番，我先展示了一下故障现象，让大家尝试猜测问题所在。屏幕上显示出的是一个由于某种原因导致系统无法正常启动的状态，提示信息“run-init: can’t excute ‘/sbin/init’: Permission denied”。
在解决问题的过程中，我采取了直接修改内核引导参数的方法来进行修复。具体操作是在 Grub 启动菜单的内核参数选项中将原本只读的“ro”更改为可读写的“rw”，并在其后追加一条指令“init=/bin/bash”。这样一来，当按下 Ctrl+X 启动系统时，它会跳过原有的初始化流程，直接进入 Bash 环境以便于排查和修复问题。
修复步骤相当直接，只需进入 /lib/systemd 目录下，对 systemd 文件执行 “chattr -i systemd” 去除其不可更改属性，接着使用 “chmod +x systemd” 恢复其可执行权限。这两步操作迅速解决了当时所遇到的问题。
现在让我来解释一下问题的根源。原来，有人故意删除了 Linux 系统内初始化程序 systemd 的可执行权限，并给它加上了不可更改属性，这就导致了系统在启动过程中无法执行关键的 /sbin/init 指向的 systemd，从而无法完成正常的启动序列。
Debian 文档《系统初始化》章节中有提到，系统初始化分为四个阶段，其中最后一阶段便是 /sbin/init 指向的 /lib/systemd/systemd，负责启动后续的各种服务和程序，确保系统正常运作。在这个案例中，正是因为 systemd 文件权限异常，才引发了这次启动失败。
接下来讲解我在修复过程中涉及的内核启动参数修改。在 Arch Linux 的文档《内核参数》中，我提到了“rw”参数，它使得系统在启动时将根分区挂载为可读写状态，允许我们对文件系统进行必要的修改。而“init”参数则是用来指定替代的初始化程序，在本例中，我们将它设为了“init=/bin/bash”，这样便可以立即进入bash环境进行修复工作。
最后，第三个知识点涉及到使用的两个命令：“chmod”用于改变文件权限，其中“-x”标志取消了文件的可执行权限；而“chattr”命令则用于设置文件的特殊属性，如防止文件被修改或新增内容等。
通过以上所述，我已完整还原了那次有趣的Linux故障及其解决过程，希望这些知识能帮助大家更好地理解和应对类似的系统问题。再次感谢大家的关注和收看，期待下次再见！
参考链接
- The system initialization https://www.debian.org/doc/manuals/debian-reference/ch03.en.html
- Kernel parameters https://wiki.archlinux.org/title/kernel_parameters
这篇关于太坏了，谁这么整活别人的Linux？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
