MerlinAU MerlinAU v1.2.6 - The Ultimate Firmware Auto-Updater (AVAILABLE IN AMTM) **Thread closed due to age**

[ExtremeFiretop]

Updated one of the APs without any issue. Worked great.

I am seeing this message Cron job hook already exists in ‘/jffs/scripts/services-start’ script repeatedly on both the AP devices. On my main router, I’m not seeing any MerlinAU notices.

View attachment 57310
View attachment 57311

Hi @vlord FYI I think we found the bug for your case, the code used to say:

if [ "$((currentTimeSecs - notifyTimeSecs))" -gt "$postponeTimeSecs" ]

So basically it had to be greater, "equal too" was not valid.
After the updates, it will be:

"if [ "$((currentTimeSecs - notifyTimeSecs))" -ge "$postponeTimeSecs" ]"

The sneaky thing went right over my eyes. This will allow equal values, and this will be addressed in PR 168 and be in release 1.0.9 along with better messaging around the cron jobs to clarify the timing expectations.
(For things like time changes that happened on the 10th, etc)

Thanks for reporting!

 

[ExtremeFiretop]

I just installed this script via amtm, then tried to change the update schedule. It failed. See the attached screenshot.

Can you also send me the output of:

which crontab

When you send me your system logs and screenshots of the merlinAU settings?

Thank you!

 

[vlord]

Perfect, so we know the postpone period does not cause any issues when running interactively. This cron job hook already exists message is normal. You will see it everytime the script runs, both interactively in the SSH session or by cron job.

The last one seems to be happening pretty often, did you turn up the cron job schedule? Or run MerlinAU multiple times by chance over SSH?

Can I please have a screenshot of the MerlinAU notification date, in the Addon GUI over SSH please as requested above? Actually can I have a screenshot of all your settings to replicate.

Also, if you haven't tried, can you try to turn the cron schedule up to something soon? Like every 10 minutes, and monitor to see if the cron has the issue again?

For your reference:

Do you still want me to change Cron to every 10 minutes?

 

[ExtremeFiretop]

For your reference:

View attachment 57339View attachment 57340

View attachment 57341View attachment 57342

View attachment 57344

Do you still want me to change Cron to every 10 minutes?

Do you really have 2 more routers? If so we can just do it progressively
I'd say next node try to turn up the cron to every 10 and monitor, let us know the results.

If you end up still having issues we can provide you an early copy of v1.0.9 which you can test.

Thanks!

 

[vlord]

Do you really have 2 more routers? If so we can just do it progressively
I'd say next node try to turn up the cron to every 10 and monitor, let us know the results.

If you end up still having issues we can provide you an early copy of v1.0.9 which you can test.

Thanks!

I’ll try on one of my APs. Thanks.

 

[ExtremeFiretop]

I’ll try on one of my APs. Thanks.

I'll be around for a while so feel free to pass on the results! Thanks .

 

[vlord]

I'll be around for a while so feel free to pass on the results! Thanks .

Not sure what I should be expecting but nothing is really happening:

 

[vlord]

Not sure what I should be expecting but nothing is really happening:

View attachment 57349View attachment 57350

View attachment 57351

Also:

admin@RT-AX86U-AP2:/jffs/addons/MerlinAU.d/logs# crontab -l
0/10 * * * * sh /jffs/scripts/MerlinAU.sh run_now #MerlinAU#
admin@RT-AX86U-AP2:/jffs/addons/MerlinAU.d/logs#

 

[ExtremeFiretop]

Not sure what I should be expecting but nothing is really happening:

View attachment 57349View attachment 57350

View attachment 57351

Your not running MerlinAU at the same time as the cron job right?

Okay I think I understand the problem. Testing now.

 

[vlord]

Your not running MerlinAU at the same time as the cron job right?

Okay I think I understand the problem. Testing now.

Generally, no. Those locks from earlier are from me trying to get a single screenshot of both the main and advanced menu settings at the same time in two different term windows since the forums has a 5 file attachment limit and I had burned through 2 for my main router, 2 for my first AP, which left me one for this AP. I did inadvertantly keep Merlin AU up and running while I was waiting for the 10 minute mark to pass but I’ve now exited. I’ll give it another 10 mins and report back.

 

[vlord]

I think you are right that the lock being in MerlinAU while it was trying to update it prevented it from updating. It’s now updating.

 

[ExtremeFiretop]

Generally, no. Those locks from earlier are from me trying to get a single screenshot of both the main and advanced menu settings at the same time in two different term windows since the forums has a 5 file attachment limit and I had burned through 2 for my main router, 2 for my first AP, which left me one for this AP. I did inadvertantly keep Merlin AU up and running while I was waiting for the 10 minute mark to pass but I’ve now exited. I’ll give it another 10 mins and report back.

It for sure should of gone through if you didn't have the lock going. I'm testing now with my own cron set to 10 minutes on my node and it seems I was able to replicate the problem.

Reviewing now...

Edit: the lock file could be part of the issue. At least that's what I was testing.

 

[vlord]

Exiting out (clearing the lock) resolved the issue.

 

[ExtremeFiretop]

Exiting out (clearing the lock) resolved the issue.

View attachment 57352

Thank you for your detailed testing and results. This is extremely valuable so I know how to replicate the issues.

Will give an update shortly.

 

[ExtremeFiretop]

I’ll try on one of my APs. Thanks.

View attachment 57348

So the issue reported here above seems to stem from how this cron is configured.
Every 10 minutes should be either:

0-59/10 * * * *

Or

*/10 * * * *

While "0/10 * * * *" might work on some Linux systems, the router's embedded system is likely even more restrictive about what the cron daemon accepts or how it may interpret such syntax.
If you check crontab.guru here: https://crontab.guru/#*/10_*_*_*_* you'll find that it does consider */10 * * * * valid but mentions how 0/10 * * * * is considered non-standard: https://crontab.guru/#0/10_*_*_*_*

Now for your case specifically, the original report was valid, and as mentioned above we adjusted the logic be more forgiving to allow equal values, and also added some logic for DTS time correction (in PR 169 tonight, thanks @Martinski!), as well as clearer messaging around the time expectations, that should solve your original report.
As for your latest report when we asked you to re-test via cron, that is actually due to the entered cron schedule, we can try best-effort attempt to catch syntax errors, but it's a bit of an endless "rabbit hole" we don't want to go down.

We will most likely ask you simply adjust your cron schedule to something more standard like */15 * * * * next time we need to quickly test the cron.

 

[ExtremeFiretop]

Exiting out (clearing the lock) resolved the issue.

View attachment 57352

Added question number 21 in the FAQ in regards to this report
Thanks again!

 

[vlord]

So the issue reported here above seems to stem from how this cron is configured.
Every 10 minutes should be either:


Or


While "0/10 * * * *" might work on some Linux systems, the router's embedded system is likely even more restrictive about what the cron daemon accepts or how it may interpret such syntax.
If you check crontab.guru here: https://crontab.guru/#*/10_*_*_*_* you'll find that it does consider */10 * * * * valid but mentions how 0/10 * * * * is considered non-standard: https://crontab.guru/#0/10_*_*_*_*

View attachment 57356

Now for your case specifically, the original report was valid, and as mentioned above we adjusted the logic be more forgiving to allow equal values, and also added some logic for DTS time correction (in PR 169 tonight, thanks @Martinski!), as well as clearer messaging around the time expectations, that should solve your original report.
As for your latest report when we asked you to re-test via cron, that is actually due to the entered cron schedule, we can try best-effort attempt to catch syntax errors, but it's a bit of an endless "rabbit hole" we don't want to go down.

We will most likely ask you simply adjust your cron schedule to something more standard like */15 * * * * next time we need to quickly test the cron.

Good news is that it did work fine configured as 0/10 * * * * once I exited the SSH GUI, which cleared the lock. Thanks again for all your help.

 

[ExtremeFiretop]

Good news is that it did work fine configured as 0/10 * * * * once I exited the SSH GUI, which cleared the lock. Thanks again for all your help.

That falls in line with my expectations. If you were still having issues after the latest test I would have to keep investigating, but considering it worked once the lock file was released it all makes sense and my theory holds true. I'm hoping the answer above should hopefully address those situations going forwards.

Happy to help and to hear everything is working, I'll have those mentioned enhancements in the next release.

Still testing and validating the PR from some pages ago related to memory management before the next release hopefully this weekend.

 

[Martinski]

Good news is that it did work fine configured as 0/10 * * * * once I exited the SSH GUI, ...

Yes, your cron job worked when it was run at the top of the hour (23:00:00) because that's how the syntax "0/10 * * * *" is parsed & interpreted by the cron daemon; but that syntax may *not* run the script (or any cron job) every 10 minutes.

You can test & verify it for yourself with these simple cron jobs:

cru a cronTEST1 "*/5 * * * * (echo 'Cron TEST1:' ; date) >> /tmp/var/tmp/cronTEST1.log"

cru a cronTEST2 "0/5 * * * * (echo 'Cron TEST2:' ; date) >> /tmp/var/tmp/cronTEST2.log"

Now, let the cron jobs run for at least one hour, then delete both jobs and check the contents of the files:

cat /tmp/var/tmp/cronTEST1.log
cat /tmp/var/tmp/cronTEST2.log

I bet you 10 Quatloos that the "cronTEST1.log" file has an entry every 5 minutes, but the "cronTEST2.log" file has an entry only when the job runs at the top of the hour.

Bottom line: the advice is to use the proper syntax when you intend to run a cron job every X number of minutes.

My 2 cents.

 

[ExtremeFiretop]

Yes, your cron job worked when it was run at the top of the hour (23:00:00) because that's how the syntax "0/10 * * * *" is parsed & interpreted by the cron daemon; but that syntax may *not* run the script (or any cron job) every 10 minutes.

You can test & verify it for yourself with these simple cron jobs:

cru a cronTEST1 "*/5 * * * * (echo 'Cron TEST1:' ; date) >> /tmp/var/tmp/cronTEST1.log"

cru a cronTEST2 "0/5 * * * * (echo 'Cron TEST2:' ; date) >> /tmp/var/tmp/cronTEST2.log"

Now, let the cron jobs run for at least one hour, then delete both jobs and check the contents of the files:

cat /tmp/var/tmp/cronTEST1.log
cat /tmp/var/tmp/cronTEST2.log

I bet you 10 Quatloos that the "cronTEST1.log" file has an entry every 5 minutes, but the "cronTEST2.log" file has an entry only when the job runs at the top of the hour.

Bottom line: the advice is to use the proper syntax when you intend to run a cron job every X number of minutes.

My 2 cents.

Thanks for the clarification @Martinski !
Looking back at my previous responses, I mentioned the cron was problematic and non-standard, but I totally missed and glanced over the details on how often it actually triggers/fires off a job with that syntax