Trace log for update email notifications #354
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added code to have some trace log for the post-reboot update email notifications (debugging purposes).
Approved! Sorry for the delay, I was just having dinner when all these notifications came in. |
ExtremeFiretop
approved these changes
Nov 14, 2024
No worries. I will be called for dinner in about 10 minutes so be warned >:) LOL |
|
Of course; the one time I test with this script with the additional logging it all worked the first time. I'll try again, maybe just a fluke? |
|
And the verdict is.... My theory was right!!!! :D o.O HOW?!? |
|
Just tested again by downgrading to beta1: |
|
Not to say I have a skill.... But I have a skill.... ;) |
Your theory was that the Lock file is essentially surviving a reboot even though it's stored in a temporary virtual filesystem (i.e. created in volatile RAM) and after the reboot, the file is still there not allowing another instance of the script to execute. Well, that simply cannot happen - it's impossible because of the physics of the volatile RAM chips which (as opposed to non-volatile RAM) cannot retain data stored on it once power is cut off. Now, if the reboot after the F/W update is not occurring at all... That would be a separate problem to figure out. |
It has to be occuring, we have a reboot in the script, the router logs indicate a reboot and my network goes down, the RGB lights flash of a firmware upgrade in progress and it comes back online with the new firmware version flashed. How can it possibly not be rebooting?
I still hold that my theory was lock file related and this is lock file related hehehehahaha :P |
|
MERLINAU UPGRADE STARTING: DISCONNECT FROM SSH LOGS: UPGRADE SIGNAL STARTING: STOPPING LOGS: MORE STOPPING LOGS: DONE STARTING: |
Yes, that's my initial thought as well. The reboot must be happening as it's also coded in the script.
This would mean that there is more than one instance of the script being launched, one right after the other. |
|
I got the solution; you pointed me there! |
I don't know what I'm supposed to look for in all these logs. Is there a specific issue? |
No issue; just confirming that it did infact reboot as per the logs. :) |
Ah OK. I noticed your router doesn't show the "default initial time" during the reboot process (usually May 4 2018 or May 5 2018). |
I thought that was due to the router date keeper addon tbh. You'll notice in the logs above the following line:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added code to have some trace log for the post-reboot update email notifications (debugging purposes).