1. OpenWrt服务脚本基础概念当你第一次接触OpenWrt的服务管理时可能会对/etc/init.d和/etc/rc.d这两个目录感到困惑。其实它们的关系就像图书馆和图书索引卡一样简单明了。/etc/init.d目录相当于一个完整的图书馆存放着所有可用的服务脚本而/etc/rc.d目录则像是图书索引卡只包含那些需要开机自动运行的服务链接。我刚开始接触OpenWrt时经常搞混这两个目录的作用。直到有一次在调试一个自定义服务时才发现原来enable命令的本质就是在/etc/rc.d目录下创建对应的符号链接。这个发现让我恍然大悟原来OpenWrt的服务管理机制如此巧妙。2. 创建自定义服务脚本2.1 脚本基本结构让我们从一个最简单的服务脚本开始。在/etc/init.d目录下创建一个新文件比如my_service#!/bin/sh /etc/rc.common START99 STOP10 start() { echo Starting my custom service # 这里放置你的启动命令 } stop() { echo Stopping my custom service # 这里放置你的停止命令 }这个脚本有几个关键点需要注意第一行必须包含#!/bin/sh /etc/rc.common这是OpenWrt服务脚本的标准开头START和STOP变量决定了服务的启动和停止顺序start()和stop()是必须实现的两个基本方法2.2 设置脚本权限创建完脚本后记得给它执行权限chmod x /etc/init.d/my_service我曾经遇到过脚本不执行的问题排查了半天才发现是忘记设置执行权限了。这个看似简单的步骤却经常被忽略。3. 服务管理命令详解3.1 基本操作命令OpenWrt提供了一套完整的服务管理命令/etc/init.d/my_service start # 启动服务 /etc/init.d/my_service stop # 停止服务 /etc/init.d/my_service restart # 重启服务 /etc/init.d/my_service enable # 启用开机自启 /etc/init.d/my_service disable # 禁用开机自启3.2 enable命令的奥秘enable命令实际上做了两件事在/etc/rc.d目录下创建S开头的启动链接创建K开头的停止链接例如执行enable后你会看到S99my_service - ../init.d/my_service K10my_service - ../init.d/my_service这些链接的命名规则很有讲究S后面的数字对应START值K后面的数字对应STOP值系统启动时按数字顺序执行S开头的脚本关机时按数字顺序执行K开头的脚本4. 实战实现一个完整的服务4.1 守护进程服务示例让我们实现一个更完整的服务包含守护进程管理#!/bin/sh /etc/rc.common USE_PROCD1 START99 STOP10 start_service() { procd_open_instance procd_set_param command /usr/bin/my_daemon --config /etc/my_config.conf procd_set_param respawn # 进程崩溃后自动重启 procd_set_param stdout 1 # 重定向stdout到系统日志 procd_set_param stderr 1 # 重定向stderr到系统日志 procd_close_instance } stop_service() { pid$(pgrep -f /usr/bin/my_daemon) [ -n $pid ] kill $pid }这个示例使用了OpenWrt的procd机制它提供了更强大的进程管理功能包括自动重启、日志重定向等。4.2 添加配置文件监控我们还可以让服务在配置文件修改时自动重载reload_service() { echo Reloading configuration # 发送SIGHUP信号给守护进程 pid$(pgrep -f /usr/bin/my_daemon) [ -n $pid ] kill -HUP $pid } service_triggers() { procd_add_reload_trigger /etc/my_config.conf }这样当/etc/my_config.conf文件被修改时服务会自动调用reload方法。5. 调试技巧与常见问题5.1 查看服务状态要检查服务是否正常运行/etc/init.d/my_service status或者查看进程是否存在ps | grep my_daemon5.2 日志查看服务的输出会被重定向到系统日志可以通过以下命令查看logread -e my_daemon5.3 常见问题解决服务无法启动检查脚本是否有执行权限检查脚本的第一行是否正确查看系统日志获取详细错误信息启动顺序问题调整START值确保依赖服务先启动可以使用depends声明依赖关系权限问题确保服务运行的用户有足够的权限检查文件路径是否正确6. 高级技巧与最佳实践6.1 多实例服务有时候我们需要运行同一个服务的多个实例可以这样实现start_service() { for instance in $(ls /etc/my_service/*.conf); do procd_open_instance procd_set_param command /usr/bin/my_daemon --config $instance procd_close_instance done }6.2 环境变量设置如果需要设置环境变量start_service() { procd_open_instance procd_set_param env VAR1value1 VAR2value2 procd_set_param command /usr/bin/my_daemon procd_close_instance }6.3 最佳实践建议保持脚本简洁复杂逻辑应该放在独立的程序中使用procd机制管理长时间运行的服务为服务添加详细的日志输出考虑资源限制避免服务占用过多系统资源测试各种边界情况确保服务稳定可靠在实际项目中我曾经遇到过因为服务启动顺序不当导致的问题。后来通过合理设置START值和明确声明依赖关系解决了这个问题。这也让我深刻理解了OpenWrt服务管理机制的设计哲学。
OpenWrt 自定义服务脚本开发指南：从零实现开机自启
1. OpenWrt服务脚本基础概念当你第一次接触OpenWrt的服务管理时可能会对/etc/init.d和/etc/rc.d这两个目录感到困惑。其实它们的关系就像图书馆和图书索引卡一样简单明了。/etc/init.d目录相当于一个完整的图书馆存放着所有可用的服务脚本而/etc/rc.d目录则像是图书索引卡只包含那些需要开机自动运行的服务链接。我刚开始接触OpenWrt时经常搞混这两个目录的作用。直到有一次在调试一个自定义服务时才发现原来enable命令的本质就是在/etc/rc.d目录下创建对应的符号链接。这个发现让我恍然大悟原来OpenWrt的服务管理机制如此巧妙。2. 创建自定义服务脚本2.1 脚本基本结构让我们从一个最简单的服务脚本开始。在/etc/init.d目录下创建一个新文件比如my_service#!/bin/sh /etc/rc.common START99 STOP10 start() { echo Starting my custom service # 这里放置你的启动命令 } stop() { echo Stopping my custom service # 这里放置你的停止命令 }这个脚本有几个关键点需要注意第一行必须包含#!/bin/sh /etc/rc.common这是OpenWrt服务脚本的标准开头START和STOP变量决定了服务的启动和停止顺序start()和stop()是必须实现的两个基本方法2.2 设置脚本权限创建完脚本后记得给它执行权限chmod x /etc/init.d/my_service我曾经遇到过脚本不执行的问题排查了半天才发现是忘记设置执行权限了。这个看似简单的步骤却经常被忽略。3. 服务管理命令详解3.1 基本操作命令OpenWrt提供了一套完整的服务管理命令/etc/init.d/my_service start # 启动服务 /etc/init.d/my_service stop # 停止服务 /etc/init.d/my_service restart # 重启服务 /etc/init.d/my_service enable # 启用开机自启 /etc/init.d/my_service disable # 禁用开机自启3.2 enable命令的奥秘enable命令实际上做了两件事在/etc/rc.d目录下创建S开头的启动链接创建K开头的停止链接例如执行enable后你会看到S99my_service - ../init.d/my_service K10my_service - ../init.d/my_service这些链接的命名规则很有讲究S后面的数字对应START值K后面的数字对应STOP值系统启动时按数字顺序执行S开头的脚本关机时按数字顺序执行K开头的脚本4. 实战实现一个完整的服务4.1 守护进程服务示例让我们实现一个更完整的服务包含守护进程管理#!/bin/sh /etc/rc.common USE_PROCD1 START99 STOP10 start_service() { procd_open_instance procd_set_param command /usr/bin/my_daemon --config /etc/my_config.conf procd_set_param respawn # 进程崩溃后自动重启 procd_set_param stdout 1 # 重定向stdout到系统日志 procd_set_param stderr 1 # 重定向stderr到系统日志 procd_close_instance } stop_service() { pid$(pgrep -f /usr/bin/my_daemon) [ -n $pid ] kill $pid }这个示例使用了OpenWrt的procd机制它提供了更强大的进程管理功能包括自动重启、日志重定向等。4.2 添加配置文件监控我们还可以让服务在配置文件修改时自动重载reload_service() { echo Reloading configuration # 发送SIGHUP信号给守护进程 pid$(pgrep -f /usr/bin/my_daemon) [ -n $pid ] kill -HUP $pid } service_triggers() { procd_add_reload_trigger /etc/my_config.conf }这样当/etc/my_config.conf文件被修改时服务会自动调用reload方法。5. 调试技巧与常见问题5.1 查看服务状态要检查服务是否正常运行/etc/init.d/my_service status或者查看进程是否存在ps | grep my_daemon5.2 日志查看服务的输出会被重定向到系统日志可以通过以下命令查看logread -e my_daemon5.3 常见问题解决服务无法启动检查脚本是否有执行权限检查脚本的第一行是否正确查看系统日志获取详细错误信息启动顺序问题调整START值确保依赖服务先启动可以使用depends声明依赖关系权限问题确保服务运行的用户有足够的权限检查文件路径是否正确6. 高级技巧与最佳实践6.1 多实例服务有时候我们需要运行同一个服务的多个实例可以这样实现start_service() { for instance in $(ls /etc/my_service/*.conf); do procd_open_instance procd_set_param command /usr/bin/my_daemon --config $instance procd_close_instance done }6.2 环境变量设置如果需要设置环境变量start_service() { procd_open_instance procd_set_param env VAR1value1 VAR2value2 procd_set_param command /usr/bin/my_daemon procd_close_instance }6.3 最佳实践建议保持脚本简洁复杂逻辑应该放在独立的程序中使用procd机制管理长时间运行的服务为服务添加详细的日志输出考虑资源限制避免服务占用过多系统资源测试各种边界情况确保服务稳定可靠在实际项目中我曾经遇到过因为服务启动顺序不当导致的问题。后来通过合理设置START值和明确声明依赖关系解决了这个问题。这也让我深刻理解了OpenWrt服务管理机制的设计哲学。
