Reboot scheduler / corrupts USB drive

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.

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. ....

Click to expand...

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?]

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:

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:

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.

Click to expand...

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.