|
|
本帖最后由 q948171624 于 2018-4-25 17:59 编辑
@hiboyhiboyhiboy h大，发现一个定时重启的隐含bug：
机子不断电，仅执行reboot，开机后ntp对时有时提前于关机时间，有时拖后（已开启设置的保存当前系统时间）
而定时重启的命令仅仅是cron执行reboot，而openwrt的wiki里写过：
A simple solution for some hard-to-solve problems (memory leak, performance degradation, …) is to reboot the router periodically, for instance every night.
However, this is not as simple as it seems, becomes router usually have no real-time clock. This could lead to a never-ending loop of reboot.
In the boot process the clock is initially set by sysfixtime to the most recent timestamp of any file found in /etc. The most recent file is possibly a status file or config file, modified maybe 30 seconds before the reboot initiated by cron. So, in the boot process the clock gets set backwards a few seconds to that file's timestamp. Then cron starts and notices a few seconds later that the required boot moment has again arrived and reboots again… (At the end of the boot process ntpd starts, and it may also take a while before ntpd gets and sets the correct time, so cron may start the reboot in between.)
One solution for cron is to use a delay and touch a file in /etc before reboot:
# Reboot at 4:30am every day
# Note: To avoid infinite reboot loop, wait 70 seconds
# and touch a file in /etc so clock will be set
# properly to 4:31 on reboot before cron starts.
30 4 * * * sleep 70 && touch /etc/banner && reboot
我知道您的固件没有sysfixtime这个脚本，但是暂不清楚软重启的逻辑是如何读取 /etc/storage/system_time的。因此，如果重启后读取这个文件导致时间又回到定时的时间之前，那么就会无限循环重启。
尽管我的每周重启脚本从没出过bug，但是不清楚特殊情况下回怎样。请您讲解一下目前固件是如何防范这种情况的。如果没有防范，请您考虑加入类似op的sysfixtime的脚本并且定时重启的crontab里也做一下校正时间。
谢谢，永远支持h大
更新：
新发现，此固件软重启是沿用上次关机的时间，偏差约＜±30s，所以，我把cron的定时重启脚本前面加了sleep 70 &&。
这样即使发生循环，也会因为第二次循环的sleep70跳出了整分钟，继而不再执行第三次循环。
理论上即使断电也能跳出循环。
|
|
简体中文
繁體中文
English
日本語
Deutsch
한국 사람
بالعربية
TÜRKÇE
português
คนไทย
IP卡
狗仔卡
发表于 2018-4-24 01:33
显身卡