用测试开机脚本做了个自动任务，全过程分享给你-平芜编程栈

用测试开机脚本做了个自动任务，全过程分享给你

你有没有遇到过这样的场景：设备每次重启后，总得手动执行一串命令——比如拉起某个服务、检查网络状态、备份日志、或者定时同步配置？重复操作不仅费时，还容易遗漏。其实，只要一个轻量级的开机启动脚本，就能让这些任务在系统就绪后自动完成。

本文不是讲 Android 系统底层开发，也不是改 init.rc 或写 SELinux 策略——那些属于深度定制范畴，对大多数开发者和运维同学来说门槛高、风险大、调试难。我们聚焦一个更通用、更安全、更易落地的方案：在标准 Linux 环境（如 Ubuntu/Debian/CentOS 容器或边缘设备）中，通过 systemd 服务 + shell 脚本，实现真正可靠的开机自动任务。

这个方案不依赖特定芯片平台，无需修改系统核心配置，不触碰 SELinux 或 init 进程，所有操作都在用户空间完成，可复现、可验证、可回滚。下面我将从零开始，把整个过程拆解成你能立刻上手的步骤，包括脚本编写、服务定义、权限设置、日志排查和常见避坑点——全部基于真实部署经验，不是理论搬运。

1. 明确目标：这个“自动任务”到底要做什么？

在动手前，先想清楚：你希望开机后自动执行什么？是启动一个 Python 服务？还是定期清理临时文件？或是检测某端口是否存活并告警？不同目标，脚本写法和启动时机都不同。

本文以一个典型实用场景为例：
设备开机后，自动检查 /data 目录剩余空间，若低于 10%，向本地日志写入警告，并触发一次压缩归档
脚本需具备错误处理能力，失败时不阻塞其他服务
执行结果可查、可追溯、可监控

这个需求看似简单，但涵盖了自动任务的核心要素：条件判断、外部命令调用、日志记录、容错设计。掌握它，你就能迁移到任何类似场景。

2. 编写可执行的开机脚本

脚本是整个流程的“心脏”，必须满足三个基本要求：可独立运行、有明确退出码、不依赖交互环境。

2.1 创建脚本文件

新建文件/usr/local/bin/check-disk-space.sh（路径建议放在/usr/local/bin/，符合 FHS 标准，且无需 root 权限即可编辑）：

#!/bin/bash # 设置严格模式：遇到未定义变量或命令失败立即退出 set -euo pipefail # 日志时间戳格式化 log_time() { date '+%Y-%m-%d %H:%M:%S' } # 主逻辑函数 main() { local disk_usage local warning_threshold=10 local log_file="/var/log/disk-check.log" echo "[$(log_time)] 开始检查磁盘使用情况..." | tee -a "$log_file" # 获取 /data 分区使用率（只取数字部分） if ! disk_usage=$(df /data 2>/dev/null | tail -n1 | awk '{print $5}' | sed 's/%//'); then echo "[$(log_time)] 错误：无法获取 /data 分区信息，请确认挂载点存在" | tee -a "$log_file" return 1 fi # 判断是否超阈值 if [ "$disk_usage" -gt "$warning_threshold" ]; then echo "[$(log_time)] 警告：/data 使用率已达 ${disk_usage}%，超过 ${warning_threshold}%" | tee -a "$log_file" # 尝试压缩最近3天的 .log 文件（仅示例，可根据实际调整） if find /data/logs/ -name "*.log" -mtime -3 -print0 2>/dev/null | xargs -0 -r tar -czf "/data/logs/backup_$(date +%Y%m%d_%H%M).tar.gz" 2>/dev/null; then echo "[$(log_time)] 已生成压缩包：/data/logs/backup_$(date +%Y%m%d_%H%M).tar.gz" | tee -a "$log_file" else echo "[$(log_time)] 注意：压缩归档失败，跳过此步" | tee -a "$log_file" fi else echo "[$(log_time)] 正常：/data 使用率为 ${disk_usage}%" | tee -a "$log_file" fi } # 执行主函数，并捕获异常 if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then main "$@" fi

2.2 赋予执行权限并手动验证

sudo chmod +x /usr/local/bin/check-disk-space.sh sudo /usr/local/bin/check-disk-space.sh

预期效果：

控制台输出带时间戳的日志
/var/log/disk-check.log中有相同内容
若/data存在且使用率超限，会尝试生成.tar.gz压缩包

关键提醒：

set -euo pipefail是安全底线，避免脚本因变量未定义或命令失败而静默继续
所有外部命令（如df,find,tar）都加了2>/dev/null或显式错误处理，防止因缺失工具导致崩溃
不使用sudo或su在脚本内提权——权限应在 service 单元中统一管理

3. 定义 systemd 服务单元

Linux 现代发行版默认使用 systemd 管理服务。相比传统 rc.local，systemd 提供：
🔹 启动依赖控制（例如“等网络就绪后再运行”）
🔹 自动重启策略（崩溃后重试）
🔹 结构化日志（journalctl可查）
🔹 资源限制（CPU/内存/IO）

3.1 创建服务文件

新建/etc/systemd/system/disk-check.service：

[Unit] Description=Disk Usage Check on Boot Documentation=https://example.com/disk-check-docs After=network.target local-fs.target StartLimitIntervalSec=0 [Service] Type=oneshot ExecStart=/usr/local/bin/check-disk-space.sh RemainAfterExit=yes User=root Group=root Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" StandardOutput=journal StandardError=journal SyslogIdentifier=disk-check # 可选：限制资源，防脚本失控 # MemoryMax=50M # CPUQuota=10% [Install] WantedBy=multi-user.target

字段说明：

After=network.target local-fs.target：确保网络和文件系统已就绪再执行
Type=oneshot：脚本执行完即退出，不常驻进程
RemainAfterExit=yes：即使脚本退出，服务状态仍显示为 active，便于状态查询
User=root：因需检查系统级路径（如/data），需 root 权限；如仅操作用户目录，可设为普通用户
StandardOutput=journal：所有输出自动进入 journal，无需手动重定向

3.2 启用并测试服务

# 重载 systemd 配置 sudo systemctl daemon-reload # 启用开机自启 sudo systemctl enable disk-check.service # 立即运行一次（模拟开机） sudo systemctl start disk-check.service # 查看执行结果 sudo systemctl status disk-check.service sudo journalctl -u disk-check.service -n 20 --no-pager

预期输出：

systemctl status显示active (exited)
journalctl输出与手动执行一致，含完整时间戳和日志内容

4. 处理常见问题与避坑指南

即便脚本和服务定义正确，实际部署中仍可能失败。以下是高频问题及解决方法，均来自真实踩坑记录：

4.1 “脚本找不到命令” —— PATH 环境变量丢失

现象：journalctl报错command not found: df或tar
原因：systemd 服务默认 PATH 极简（通常只有/usr/bin:/bin），而某些发行版将df放在/bin/，tar在/usr/bin/，但脚本中未指定绝对路径

解决：

方案一（推荐）：在 service 文件中显式设置Environment="PATH=..."（如上文所示）
方案二：脚本内用绝对路径，如/bin/df、/usr/bin/tar
方案三：在脚本开头添加source /etc/environment（不推荐，耦合系统配置）

4.2 “脚本执行但无日志” —— 输出未被捕获

现象：systemctl status显示成功，但journalctl空空如也
原因：脚本内部用了echo > /dev/stdout或重定向到文件，绕过了 systemd 的 stdout/stderr 捕获

解决：

删除脚本中所有> file或>> file重定向（日志统一由tee -a "$log_file"处理）
确保StandardOutput=journal和StandardError=journal在 service 中启用
如需额外落盘日志，保留tee，但不要屏蔽 stdout

4.3 “开机没执行” —— 启动时机不当

现象：重启后systemctl status disk-check.service显示inactive (dead)
原因：服务被标记为WantedBy=multi-user.target，但实际依赖的挂载点（如/data）尚未就绪

解决：

在[Unit]中添加RequiresMountsFor=/data
或改用After=local-fs.target+Wants=local-fs.target（更稳妥）
验证：systemctl list-dependencies --after disk-check.service查看依赖顺序

4.4 “反复执行失败” —— 缺少失败抑制机制

现象：脚本因/data未挂载失败，systemd 不断重试，刷爆日志
原因：未配置StartLimitIntervalSec和StartLimitBurst

解决：

在[Unit]中添加：
```
StartLimitIntervalSec=600 StartLimitBurst=3
```
表示 10 分钟内最多启动 3 次，超限则暂停

5. 进阶技巧：让自动任务更健壮、更可控

基础功能跑通后，可按需增强：

5.1 添加健康检查与通知

在脚本末尾加入简易 HTTP 告警（需curl）：

# 若磁盘超限，向企业微信机器人发送文本 if [ "$disk_usage" -gt "$warning_threshold" ]; then curl -X POST "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" \ -H 'Content-Type: application/json' \ -d '{"msgtype": "text", "text": {"content": " 磁盘告警：/data 使用率 ${disk_usage}%"}}' >/dev/null 2>&1 fi

5.2 支持参数化配置

将阈值、日志路径等抽离为配置文件/etc/disk-check.conf：

# /etc/disk-check.conf DISK_PATH="/data" WARNING_THRESHOLD=10 LOG_FILE="/var/log/disk-check.log"

脚本中用source /etc/disk-check.conf加载，便于多环境复用。

5.3 定时+开机双保险

若需每日检查，可同时启用 timer：

# /etc/systemd/system/disk-check.timer [Unit] Description=Run disk check daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target

启用：sudo systemctl enable --now disk-check.timer
这样既保证开机必检，又支持周期性巡检。

6. 总结：为什么这个方案值得你采用

回顾整个过程，我们没有修改任何系统核心文件，没有编译代码，没有配置 SELinux，甚至不需要重启系统——所有操作均可在运行中完成、验证、回滚。

这套方案的价值在于：
🔹极简可靠：仅需一个 shell 脚本 + 一个 service 文件，无外部依赖
🔹开箱即用：适配 Ubuntu/Debian/CentOS/Rocky 等主流发行版
🔹可观测性强：所有输出直连journalctl，支持--since "1 hour ago"快速定位
🔹易于扩展：从单次检查，到定时任务、告警集成、配置中心，平滑演进
🔹团队友好：脚本逻辑清晰，service 配置标准化，新人可快速接手

真正的自动化，不在于技术多炫酷，而在于：它能稳定运行三年，而你几乎忘记它的存在。

现在，你可以把本文的脚本复制过去，改几行路径，加两行业务逻辑，然后systemctl enable && reboot—— 你的第一个生产级自动任务，就此诞生。