根文件系统相关2:rootfs/etc目录的简单分析

本文详细解析了BusyBox中inittab与rcS脚本的工作原理及配置细节,包括环境变量设置、文件系统挂载、设备文件生成等关键步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

rootfs/etc目录结构:包含:fstab   inittab  profile init.d文件夹;rootfs/etc/init.d文件夹包含rcS文件。

1.inittab脚本文件的分析:    

(1)被/linuxrc执行时调用,是一个文本格式的运行时配置文件,内容是由一系列的遵照一个格式组织的字符组成的。实际工作的时候busybox会(按照一定的格式)解析这个inittab文本文件,然后根据解析的内容来决定要怎么工作。

(2)基本的格式:id:runlevels:action:process (值得注意得是有些配置值可以空缺,空缺后冒号不能空缺)

id:id号  runlevels:运行的级别   action:条件/状态  process:可被执行的程序的pathname。

合起来的意思就是:当满足action的条件时就会执行process这个程序
而busybox最终是进入一个死循环,不断的去反复检测各个action条件,满足时就执行对应的process。

(3)几个常见的action:

sysinit:控制台在被初始化之前被执行
askfirst:控制台提示用户输入
ctrlaltdel:按下这三个键重启.

2.rcS脚本文件的分析:

(1)被inittab中引用执行:

::sysinit:/etc/init.d/rcS 

(2)是linux的运行时配置文件中最重要的一个,其他的一些配置都是由这个文件引出来的,里面可以有很多的配置项。

(3)设置环境参数PATH:

PATH=/sbin:/bin:/usr/sbin:/usr/bin			

(4)将用户设置为单用户模式:

runlevel=S

(5)设置linux系统的umask值:

	umask 022

umask值决定当前用户在创建文件时的默认权限。
umask是022的时候,默认touch创建一个文件的权限是644;
umask是444的时候,默认touch创建一个文件的权限是222;    
总结:umask的规律就是:umask值和默认创建文件的权限值加起来是666.

(6)挂载文件系统:

	mount -a

挂载所有的应该被挂载的文件系统.
 去查找一个/etc/fstab文件,这个文件按照一定的格式列出来所有应该被挂载的文件系统(包括了虚拟文件系统)

(7)mdev相关的:

echo /sbin/mdev > /proc/sys/kernel/hotplug

mdev是udev的嵌入式简化版本,用来配合linux驱动生成相应的/dev目录下的设备文件。再次启动时在/dev目录中生成了很多的驱动文件。

(8)系统主机名的确定:

/bin/hostname -F /etc/sysconfig/HOSTNAME

/bin/hostname是一个脚本,而具体配置的主机名在/etc/sysconfig/HOSTNAME中存储。

(9)开发板ip的设置:

ifconfig eth0 192.168.1.10

3.profile文件分析:

主要用于做用户的登录。被busybox(init进程)自动调用的,文件内是有关Linux环境变量的东西,其中和根文件系统最直观的是:配置hostname必须有此文件才能工作。

 

End。。。。。。

<think>嗯,用户遇到了rc-local.service启动失败的问题,状态码为209/STDOUT。这个问题确实比较棘手。用户提供的系统配置线索很重要,可以看到:-用户通过修改init.rc来设置开机启动脚本[^2]-系统环境似乎是基于Debian的自定义rootfs[^3]-当前使用的是systemd管理服务注意到这个209状态码很特殊。在systemd文档中查不到具体解释,这通常表示服务在输出到标准输出时发生了意外情况。深入思考可能的故障点:1.脚本权限问题可能最容易被忽略,特别是在交叉编译环境下2.用户用init.rc传统方式配置自启动,可能与systemd产生冲突3./app路径是否在fstab挂载?如果挂载延迟可能导致服务启动时脚本"消失"用户的环境很特殊:-基于Debian但使用定制rootfs-可能是嵌入式设备-存在/app这样非常规路径排查时需要重点关注:1.检查journalctl日志的时间戳,看是否与其他服务启动时间冲突2.确认根文件系统是否已完全挂载可写3.测试直接执行脚本时的输出是否正常最关键的诊断步骤其实是让用户尝试手动运行服务配置文件中指定的脚本。这个简单的测试能立即区分是脚本问题还是系统配置问题。</think> 根据报错特征和系统配置分析,解决`rc-local.service`启动失败问题需依次排查以下环节: --- ### **故障诊断与解决方案** #### 1. **检查脚本执行权限** ```bash sudo chmod +x /app/app_start.sh # 确保执行权限[^2] ls -l /app/app_start.sh # 验证权限输出应为 -rwxr-xr-x ``` #### 2. **验证脚本输出行为** ```bash sudo /app/app_start.sh # 手动运行观察输出 ``` - **关键检查**: ⚠️ 若脚本向**标准输出(STDOUT)**写入内容(如`echo`或命令输出),需重定向到文件或`/dev/null`: ```bash # 修改启动脚本(示例) echo "Starting service..." > /var/log/app_start.log # 替代直接输出到终端 /path/to/your_command >> /dev/null 2>&1 # 屏蔽所有输出 ``` #### 3. **排查路径依赖问题** ```bash # 检查关键路径是否存在 ls -d /app /sys /proc # 若/app为挂载点,需确认fstab配置 systemctl cat rc-local.service | grep WorkingDirectory # 确认工作目录 ``` #### 4. **检查服务文件配置** ```ini # 编辑服务单元文件(通常位于/lib/systemd/system/rc-local.service) [Service] Type=oneshot ExecStart=/app/app_start.sh StandardOutput=null # ✨ 关键修复:禁止输出到STDOUT RemainAfterExit=yes TimeoutSec=0 # 禁用超时机制 ``` #### 5. **重载服务配置** ```bash sudo systemctl daemon-reload sudo systemctl restart rc-local.service journalctl -u rc-local.service -b # 检查最新日志 ``` --- ### **根本原因分析** 状态码`209/STDOUT`表明: - systemd严格限制**oneshot类型服务**输出内容到标准输出[^1] - 初始化脚本(`app_start.sh`)中的命令产生了终端输出 - 特殊环境(如嵌入式Debian)可能存在路径挂载时序问题[^3] --- ### **典型修复案例** 某嵌入式设备日志显示: ```log rc-local.service: Failed with result 'exit-code' rc-local.service: Main process exited, code=exited, status=209/STDOUT ``` 👉 **解决过程**: 1. 在脚本顶部添加 `exec > /dev/null 2>&1` 屏蔽输出 2. 增加挂载等待逻辑:`while [ ! -d /app ]; do sleep 1; done` 3. 服务文件增加 `After=local-fs.target` 依赖项 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值