Reboot scheduler / corrupts USB drive

[kernol]

Manual webgui "Reboot" button now produces clean reboot even with Diversion 4.0.7_beta installed [the beta adds appropriate code to unmount script] - However, "Reboot Scheduler" has never worked for me and still does not when it come to clean umount of USB drives.

Surely the solution is for the same code that is called from webgui "Reboot" button to be called by the "Reboot Scheduler" option at the set reboot times? Perhaps @RMerlin can respond?

I know that AMTM's "Disk Check Script" fixes the USB corruption that occurs after "Reboot Scheduler" is called - but would really prefer a clean scheduled reboot without the data corruption in the first place.
Many thanks.

 

[kernol]

Manual webgui "Reboot" button now produces clean reboot even with Diversion 4.0.7_beta installed [the beta adds appropriate code to unmount script] - However, "Reboot Scheduler" has never worked for me and still does not when it come to clean umount of USB drives. ....

In the absence of any comments to my post [aside from the "likes" - appreciated!] it dawned on me that perhaps the webgui "Reboot" button was part of the closed source section of the stock firmware ... so maybe nobody knows" ??? .

I'm pretty sure that "Scheduled Reboot" was an option first added by Merlin - but it is ages since I was on stock firmware - so can't be sure.
In the wiki on Merlin - the code for a customised scheduled reboot was last presented in 2015 as a cron job to be placed in /jffs/scripts/init-start.
That simply invokes a shell "reboot" command.

The webgui "Reboot" button must be doing more than that - because it certainly graciously umounts the USB's before restarting.
Perhaps someone can offer a better cron job script for use instead of the "Scheduled reboot" menu option in Merlin-ware [assuming the latter can't be fixed?]

 

[thelonelycoder]

My tests confirm your suspicion that only /jffs/scripts/services-stop is run during the scheduled reboot. /jffs/scripts/unmount is never called.
This is on a RT-AC1900P with 384.9_alpha2 firmware.

Edit: I was wrong, both are run, I had a copy paste error.
Here is the sequence for a scheduled reboot of the two files:

services-stop, Wed Jan 23 18:56:08 MEZ 2019
unmount, Wed Jan 23 18:56:17 MEZ 2019

And same sequence for a WebUI reboot:

services-stop, Wed Jan 23 19:02:07 MEZ 2019
unmount, Wed Jan 23 19:02:11 MEZ 2019

 

[kernol]

My tests confirm your suspicion that only /jffs/scripts/services-stop is run during the scheduled reboot. /jffs/scripts/unmount is never called.
This is on a RT-AC1900P with 384.9_alpha2 firmware.

Edit: I was wrong, both are run, I had a copy paste error.
Here is the sequence for a scheduled reboot of the two files:

services-stop, Wed Jan 23 18:56:08 MEZ 2019
unmount, Wed Jan 23 18:56:17 MEZ 2019

And same sequence for a WebUI reboot:

services-stop, Wed Jan 23 19:02:07 MEZ 2019
unmount, Wed Jan 23 19:02:11 MEZ 2019

That leaves me wondering why webgui Reboot button works without USB data corruption - but scheduled reboot always end with data corruption ??? Any ideas on where to look to trace the issue?

 

[thelonelycoder]

I may have the reason why reboot scheduler is corrupting attached USB file systems.
When issuing a normal reboot through the WebUI, the time given after the unmount script runs is somewhere in the region of 2 minutes.
This is vastly different when a scheduled reboot runs, 10 seconds in this test on my RT-AC1900P on 384.9_beta1:

# WebUI reboot
services-stop, Sun Jan 27 08:55:10 MEZ 2019
unmount, Sun Jan 27 08:55:13 MEZ 2019
unmount 1 sec ping, Sun Jan 27 08:55:14 MEZ 2019
unmount 1 sec ping, Sun Jan 27 08:55:15 MEZ 2019
...
<pings continue in one second steps until final ping at:>
unmount 1 sec ping, Sun Jan 27 08:57:12 MEZ 2019

# Scheduled reboot
services-stop, Sun Jan 27 09:02:19 MEZ 2019
unmount, Sun Jan 27 09:02:28 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:29 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:30 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:31 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:32 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:33 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:34 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:35 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:36 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:37 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:38 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:39 MEZ 2019

I have code in /jffs/scripts/unmount and services-stop that log to a file while rebooting. The unmount 1 sec ping writes to the file every second until shutdown of router services kills the task.

 

[kernol]

I may have the reason why reboot scheduler is corrupting attached USB file systems.
When issuing a normal reboot through the WebUI, the time given after the unmount script runs is somewhere in the region of 2 minutes.
This is vastly different when a scheduled reboot runs, 10 seconds in this test on my RT-AC1900P on 384.9_beta1:

# WebUI reboot
services-stop, Sun Jan 27 08:55:10 MEZ 2019
unmount, Sun Jan 27 08:55:13 MEZ 2019
unmount 1 sec ping, Sun Jan 27 08:55:14 MEZ 2019
unmount 1 sec ping, Sun Jan 27 08:55:15 MEZ 2019
...
<pings continue in one second steps until final ping at:>
unmount 1 sec ping, Sun Jan 27 08:57:12 MEZ 2019

# Scheduled reboot
services-stop, Sun Jan 27 09:02:19 MEZ 2019
unmount, Sun Jan 27 09:02:28 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:29 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:30 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:31 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:32 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:33 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:34 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:35 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:36 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:37 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:38 MEZ 2019
unmount 1 sec ping, Sun Jan 27 09:02:39 MEZ 2019

I have code in /jffs/scripts/unmount and services-stop that log to a file while rebooting. The unmount 1 sec ping writes to the file every second until shutdown of router services kills the task.

Many thanks once again ... I believe you know how much I prefer "clean reboots" ... hopefully @RMerlin can fix in the final release of 384.9?
I can't see any harm in increasing the delay time in Scheduled reboot by 2 minutes - after all it is normally run unattended late at night or early in the morning.

 

[RMerlin]

I have code in /jffs/scripts/unmount and services-stop that log to a file while rebooting. The unmount 1 sec ping writes to the file every second until shutdown of router services kills the task.

All calls to run_custom_script_blocking() for unmount share the same default limit of 120 seconds. If it terminates earlier than that then it means something else is killing its process while it's still running - not much I can do about that.

 

[john9527]

This is vastly different when a scheduled reboot runs, 10 seconds in this test on my RT-AC1900P on 384.9_beta1:

I may have an idea of what's going on. Since your post was from January, what level/platform are you running now if I were to gen a test build?

 

[thelonelycoder]

I may have an idea of what's going on. Since your post was from January, what level/platform are you running now if I were to gen a test build?

The 1900P so 68U build.

 

[clvk07]

Had the same problem with AC88U and Merlin firmware 384.X.
Had Skynet, diversion, transmission installed. It was working fine for a week or so and then corrupting the USB (file systems lock) Only solution was wipe and reinstall, but was keep happening.
Never figured out why.. Now this might explain.. Had reboot scheduler myself....

 

[john9527]

@thelonelycoder

When you get a chance, can you try
RT-AC68U_384.9_0-g1cf15ffb7d.zip
https://1drv.ms/f/s!Ainhp1nBLzMJg2PrW8jAxmtmBfvu

 

[thelonelycoder]

@thelonelycoder

When you get a chance, can you try
RT-AC68U_384.9_0-g1cf15ffb7d.zip
https://1drv.ms/f/s!Ainhp1nBLzMJg2PrW8jAxmtmBfvu

This bit of code is in the respective files:

echo "$(date -R) services-stop">>/jffs/reboot.log

echo "$(date -R) unmount for $1">>/jffs/reboot.log
onesecping(){
    echo "unmount 1 sec ping, $(date -R)">>/jffs/reboot.log
    sleep 1
    onesecping
}
onesecping

The results look similar between 384.9 Merlin and yours. The noticeable difference is that the former seems to unmount the device twice while yours does not with the (amtm) reboot command.
https://pastebin.com/aXWk9uiv

 

[john9527]

The noticeable difference is that the former seems to unmount the device twice while yours does not with the (amtm) reboot command.

Interesting....the change I made should have no effect on command reboots (unless the reboot scheduler fired at the same time you were issuing the amtm reboot...the change prevented the reboot scheduler from firing if there was already a reboot in progress).

Can you give this build a try? Same download location.
RT-AC68U_384.9_0-ga3135cbb25.zip

 

[thelonelycoder]

Interesting....the change I made should have no effect on command reboots (unless the reboot scheduler fired at the same time you were issuing the amtm reboot...the change prevented the reboot scheduler from firing if there was already a reboot in progress).

Can you give this build a try? Same download location.
RT-AC68U_384.9_0-ga3135cbb25.zip

Now that looks different. WebUI reboot and reboot scheduler allow about 2 minutes to unmount.
A reboot command (/sbin/reboot) about 10 seconds.
This is a vast improvement.
https://pastebin.com/RkEv720k

 

[john9527]

Now that looks different. WebUI reboot and reboot scheduler allow about 2 minutes to unmount.
A reboot command (/sbin/reboot) about 10 seconds.
This is a vast improvement.
https://pastebin.com/RkEv720k

More interesting results....the latest change uses rc to do the reboot instead of the system.

For the amtm case, try using "service reboot" instead of "/sbin/reboot"

 

[thelonelycoder]

More interesting results....the latest change uses rc to do the reboot instead of the system.

For the amtm case, try using "service reboot" instead of "/sbin/reboot"

"service reboot" produces the same proper unmount as the "Reboot" and Reboot scheduler in the WebUI. I would call that a success extraordinaire!
Now, for Merlin's older Firmware versions like 380.70 where no script run timeout is set, my extra code prevents a proper reboot but that is my "error".

I haven't checked but does your 374.43_38E4j9527 or older have a max timeout of 120 secs as 384.xx does?
Any chance your reboot changes make it into Merlin's FW?

Edit: You do not have a timeout in your latest LTS release, apparently.