i3wm启动脚本随机执行异常 pywal换壁纸与polybar运行不稳定

核心问题特征 #

• 两个脚本连续稳定运行一年后出现随机异常：全脚本不执行、仅单脚本正常、脚本仅完成部分逻辑（如polybar完成旧进程终止但未拉起新进程、pywal完成系统配色变更但未设置壁纸）
• 两个脚本在终端手动执行时100%工作正常
• 移除change-wallpaper脚本后，polybar启动脚本可全程稳定运行
• 已尝试补全脚本全路径、调整配置内脚本执行顺序、合并为单脚本执行，均未解决问题

高概率排查方向 #

1. i3启动环境与交互式终端的环境差异 #

i3的exec_always启动的子进程，仅加载系统级有限环境变量，远少于交互式终端的加载内容。之前长期稳定不代表环境完全兼容：近期如果pywal、feh（wal实际调用的壁纸设置工具）、polybar的路径发生变动，或不在i3的默认PATH范围内，就会出现脚本半执行的状态（核心命令路径在PATH内、依赖的下游工具路径不在PATH内）。

• 验证修复方法：
  • 对脚本内所有调用的命令，全部替换为which 命令名查到的绝对路径
  • 给两个脚本追加日志输出，定位未执行的具体命令，示例：

    #!/bin/sh
    # 全量日志输出
    exec >> /tmp/change-wallpaper.log 2>&1
    echo "执行时间：$(date)"
    echo "当前环境PATH：$PATH"
    files=(/home/marlon/Pictures/Wallpapers/*)
    CURRENT_WP="${files[RANDOM % ${#files[@]}]}"
    echo "选中壁纸文件：$CURRENT_WP"
    /usr/local/bin/wal -i "$CURRENT_WP"
    # 显式指定壁纸设置工具全路径
    /usr/bin/feh --bg-scale "$CURRENT_WP"
    

    #!/usr/bin/env bash
    exec >> /tmp/polybar-launch.log 2>&1
    echo "执行时间：$(date)"
    /usr/bin/killall -q polybar
    sleep 1
    /usr/bin/polybar bar1 >>/tmp/polybar1.log 2>&1 &
    

  • 重启i3多次后观察日志，可直接定位因路径缺失未执行的命令

2. 并行启动的进程时序冲突 #

i3配置中连续书写的exec_always命令，实际是同步触发后独立fork子进程运行，不会等待前一个命令执行完成，本质是并行启动。之前尝试合并脚本失效的原因，大概率是合并后没有等待前序命令完全执行完成，直接启动了后续命令，本质还是时序冲突。
如果近期pywal更新后，缓存文件读写耗时、壁纸设置耗时增加，就会和同步启动的polybar产生资源竞争，表现为随机出现的X11连接失败、pywal缓存文件读写锁冲突，导致脚本执行中断。

• 验证修复方法：在两个脚本的执行链中增加强制间隔，打破并行状态，示例配置：

  exec_always --no-startup-id /usr/bin/change-wallpaper
  exec_always --no-startup-id sleep 2 && $HOME/.config/polybar/launch.sh
  

3. 脚本格式与权限异常 #

• 检查脚本的换行格式：如果脚本被误存为Windows CRLF换行格式，i3执行时会将shebang行识别为无效路径，随机出现执行失败。可通过file /usr/bin/change-wallpaper检查，若提示含CRLF格式，使用dos2unix转换为Unix LF格式即可
• 检查脚本执行权限：确认两个脚本对当前用户有可执行权限，排除权限变动导致的随机执行失败

4. 依赖组件更新引入的随机崩溃 #

由于脚本已长期稳定运行，问题出现时间点和近期系统更新高度重合时，需排查依赖组件的兼容问题：

• 检查pywal版本更新后的随机壁纸选择逻辑：如果壁纸目录下存在损坏的图片、带特殊字符（空格、中文、符号）的文件名，wal处理时会随机中断，出现仅修改配色、未完成壁纸设置的情况
• 给脚本内的命令追加退出码判断，定位崩溃点：

  /usr/local/bin/wal -i "$CURRENT_WP" || echo "wal执行失败，退出码：$?"
  

快速验证流程 #

1. 转换两个脚本为Unix换行格式，补全所有命令的绝对路径，追加日志输出
2. 在两个脚本的执行启动链中增加2秒延迟
3. 重启i3 5-10次观察执行稳定性，通过日志定位剩余异常点

内容的提问来源于stack exchange，提问作者xedc