☰

处理重复运行的防弹方法

tag-icon • tag-icon linux shell busybox
处理重复运行的防弹方法

我的路由器上有一个脚本，由 cron 每 30 分钟运行一次。路由器有时会运行两次，间隔几秒钟，但仅在路由器启动时运行。几周前，为了避免它同时运行两次，我使用 pidof 进行检查，故意避免任何文件锁定方法 - 以防止任何可能的问题。

for pid in $(pidof DoubleDDNS); do
  if [ $pid != $$ ]; then
    echo "DoubleDDNS [no2run] Exiting"
    exit 1
  fi
done

但。我只是遇到了问题。由于某种原因，路由器出现了故障。我的剧本显然没有完成。永远留在了记忆里。因此，上述检查阻止了我的脚本再次运行，而原始（较旧的）运行未完成其工作。这就产生了一个问题（没有向 DDNS 报告新的 WAN IP 地址）。

我不认为这是我的脚本的错，因为其中没有任何命令可能会使其卡住。该脚本在多个路由器上运行了 8 个多月，没有出现任何问题。它写得很好，处理和测试了所有可能的错误。路由器大部分工作正常，但其中的许多东西都损坏了（例如ssl）。路由器没有报告其 3 个内存已满（这可能是真的，也可能不是）。当我在自己的 WebGUI 中选择重置时，它甚至不会重置，并且必须使用开/关按钮重置！

那么，我如何确保我的支票能够进行第二次运行呢？我在想：包括检查前一个实例是否运行超过 60 秒，如果是这样，它将

  1. 尝试杀死任何旧实例
  2. 尽管重复运行仍继续。脚本在每小时的第 3 分钟和第 33 分钟运行，单次运行持续 <15 秒。

问题（最好没有任何文件生成，但也许我避免文件锁是一个糟糕的解决方案，所以建议）：

  1. 如何检测上一次运行的时间？
  2. 还有比我更好的想法吗？
  3. 有没有办法自杀脚本：如果脚本在 60 秒内没有完成，则杀死此脚本实例

请记住：router、sh 和 busybox。因此，可用的东西是有限的。华硕路由器华硕RT-AC*U路由器与Merlin固件一起使用。

答案1

这是我的工作防弹版本的模型。它被操纵以显示逻辑。它在我的路由器上运行正常。

#!/bin/sh

age_max_sec=50

LOCKFILE=lock.txt
if [ -e ${LOCKFILE} ]; then
    echo "lockfile exists"
    if kill -0 `cat ${LOCKFILE}`; then
        echo "script runs in mem" 
        lock_date=`date -r ${LOCKFILE} +%s`
        now=`date +%s`
        lock_age=$(($now-$lock_date))
        if [ $lock_ag e -gt $age_max_sec ]; then
            echo "DoubleDDNS (no2runKILL)"
            kill `cat ${LOCKFILE}`
        else
            echo "DoubleDDNS (no2runOK), age $lock_age seconds, quit this run"
            exit 1
        fi   
    else
        echo "not allready running, go ahead"
    fi
fi

echo "working on"

# overkill???? just in case, scorched earth check.
filename=${0##*/}
for pid in $(pidof $filename); do
    if [ $pid != $$ ]; then
        echo "DoubleDDNS (no3runKILL)"
        kill -9 $pid
    fi
done

# make sure the lockfile is removed when we exit and then claim it
trap "rm -f ${LOCKFILE}; exit" INT TERM EXIT
echo $$ > ${LOCKFILE}

# main program here

rm -f ${LOCKFILE}

echo "done"

我想如果我想检查上次运行的年龄，我必须使用锁文件。所以，用 pid 创建一个锁文件。如果锁定文件不早于设置的秒数限制，则退出。如果较旧，则杀死前一个实例。在我的路由器上，我没有任何更好的方法可用于进行检查。

我是否需要进行焦土检查，还是太过分了？完成合法的锁定文件检查后，我会重新检查内存中是否仍有残留但已损坏的进程，如果发现则终止。问题是：我没有办法测试它，直到最终真正的灾难再次发生并且定期清理无法清理它。如果不是杀伤力太大的话...

应该注意的是，NTP 服务的可用性可能会影响定时锁定和自杀丸。例如，我第一次运行上述脚本将在 NTP 修复时间之前大约 4 秒发生。所以，我们应该考虑这些事情。

DopeGhoti 提供的上述自杀药丸效果非常好。所以，现在只是判断使用哪个组合的问题。还是全部？锁文件、定时释放、焦土和自杀。嗯，听起来有点矫枉过正，但我​​没有看到他们中的任何一个人相互对抗，而是完美（偏执）和谐。欢迎评论。

相关内容