Unraid OS version 6.12.4 available

[JorgeB]

33 minutes ago, hawihoney said:

I don't see IPVLAN, MACVLAN or MACVTAB anywhere within the settings:

 

Macvlan/ipvlan is only an option if you are using a bridge, with bridging disabled it automatically uses macvtap.

[JorgeB]

18 minutes ago, Viking said:

Just "Fix Common Problems" reporting "macvlan call traces found".

If you are getting call traces better to switch to ipvlan, if ipvlan doesn't work for you use the new option with bridging disabled.

[Viking]

1 hour ago, JorgeB said:

If you are getting call traces better to switch to ipvlan, if ipvlan doesn't work for you use the new option with bridging disabled.

 thx @JorgeB
I've switched my dockers to ipvlan and everything's working fine. 👍
I only use custom networks and custom VPN networks. I don't know if that helps!

On the other hand, Fix Common Problems leaves me with the error "macvlan call traces found", despite my rescan. Is it a question of cache or do I still have a problem?

Edited September 4, 2023 by Viking

[itimpi]

6 minutes ago, Viking said:

On the other hand, Fix Common Problems leaves me with the error "macvlan call traces found"

Have you rebooted.   Until you do you may still have (old) log entries that mention macvlan.

[Frank1940]

I upgraded this morning and got this message after I rebooted:

Before I upgrading, I stopped all of the Dockers and stopped the array.  I then started the upgrade.  After seeing that I had this message (Within ten minutes after the server came back.  I checked on MAIN and there was no Parity Check running.  I spun all the disks down and they stayed spun down.  I am attaching the Diagnostics file. 

 

elsie1-diagnostics-20230904-1228.zip

[itimpi]

3 minutes ago, Frank1940 said:

I upgraded this morning and got this message after I rebooted:

Before I upgrading, I stopped all of the Dockers and stopped the array.  I then started the upgrade.  After seeing that I had this message (Within ten minutes after the server came back.  I checked on MAIN and there was no Parity Check running.  I spun all the disks down and they stayed spun down.  I am attaching the Diagnostics file. 

 

elsie1-diagnostics-20230904-1228.zip 116.32 kB · 0 downloads

You can ignore that message as the plugin can generate it spuriously.    This is being worked on.

[AgentXXL]

2 hours ago, itimpi said:

You can ignore that message as the plugin can generate it spuriously.    This is being worked on.

 

I'm also seeing this message. I did a few test reboots and it occurred everytime the array was started, but did not start an actual parity check. I know I had proper shutdowns - I'm pretty OCD driven to manually stop the running containers and then disable the Docker service. My VM service is also disabled as I don't run any VMs on unRAID at this time. I then manually unmount all UD-mounted shares, stop the array and then perform the reboot.

 

I tried manually deleting the file /config/forcesync but I still got the notification on the next array start. I'll wait to see if an upcoming update to the parity check tuning plugin fixes it. Worst case is I wait until my next scheduled parity check and see if that clears it up.

 

Edited September 4, 2023 by AgentXXL
clarification

[JustOverride]

I updated without backing up the USB, restarted without stopping the array...lolyolo

 

Updated without issues, no parity check, (everything went as expected).

 

Thank you team!

[itimpi]

That message got introduced when the option to restart array operations was added as the plugin can only restart operations if it was a clean shutdown.  It is meant to be an informative message only and does not actually cause anything to happen.

 

I am currently working on some issues around the restart logic so this should get fixed as a by-product off that.    I could remove the notification entirely from the code so would welcome some feedback on whether it is useful (assuming it is working correctly).  My feeling was that it helped users by them not having to visit the syslog to be certain what had happened.

[itimpi]

9 minutes ago, AgentXXL said:

I tried manually deleting the file /config/forcesync but I still got the notification on the next array start. I'll wait to see if an upcoming update to the parity check tuning plugin fixes it. Worst case is I wait until my next scheduled parity check and see if that clears it up.

I have reproduced this in a test environment so I am virtually certain that the next update will only output this notification if it really is an unclean shutdown.   

 

Do you think this message adds value (when it is working correctly) as I could simply remove it from the plugin code.  My thought was that it was useful to users to know this had happened without them having to look into the syslog.

[DiscoverIt]

1 minute ago, itimpi said:

That message got introduced when the option to restart array operations was added as the plugin can only restart operations if it was a clean shutdown.  It is meant to be an informative message only and does not actually cause anything to happen.

 

I am currently working on some issues around the restart logic so this should get fixed as a by-product off that.    I could remove the notification entirely from the code so would welcome some feedback on whether it is useful (assuming it is working correctly).  My feeling was that it helped users by them not having to visit the syslog to be certain what had happened.

 

Sep 4 13:56:02 Bakery emhttpd: shcmd (142): touch /boot/config/forcesync 
Sep 4 13:56:02 Bakery Parity Check Tuning: Unclean shutdown detected

 

What was introduced from 6.12.3 to 6.12.4 that drastically changed the start up?

 

Seems like a wide ranging issue.

[itimpi]

Just now, DiscoverIt said:

What was introduced from 6.12.3 to 6.12.4 that drastically changed the start up?

Nothing that I know off.    If anything the change would be around the shutdown logic causing genuine unclean shutdowns to happen.

[AgentXXL]

4 minutes ago, itimpi said:

I have reproduced this in a test environment so I am virtually certain that the next update will only output this notification if it really is an unclean shutdown.   

 

Do you think this message adds value (when it is working correctly) as I could simply remove it from the plugin code.  My thought was that it was useful to users to know this had happened without them having to look into the syslog.

 

I'm open to keeping it... having more information is preferable to not having enough.

[Frank1940]

14 minutes ago, itimpi said:

Do you think this message adds value (when it is working correctly) as I could simply remove it from the plugin code.  My thought was that it was useful to users to know this had happened without them having to look into the syslog.

 

My question to your question is, "What exactly is the message intended to be conveyed to the recipient if it was working properly"?  It is not clear to me if the message was intended to be sent if (1) there was an unclean shutdown or (2) that the Parity Check Tuning plugin was running and would start the next regularly scheduled parity check using the Parity Check Tuning plugin.  

Edited September 4, 2023 by Frank1940
Added "parity check"

[itimpi]

5 minutes ago, Frank1940 said:

 

My question to your question is, "What exactly is the message intended to be conveyed to the recipient if it was working properly"?  It is not clear to me if the message was intended to be sent if (1) there was an unclean shutdown or (2) that the Parity Check Tuning plugin was running and would start the next regularly scheduled using the Parity Check Tuning plugin.  

It is simply meant to inform the user there was an unclean shutdown - case (1)  The plugin does not initiate anything as a result but Unraid normally does.  It would, however, not restart any array operation that was in progress during the shutdown phase (from point then reached).    Note the plugin never initiates a parity check or other array operation from the beginning - that is always done at the Unraid level.     Maybe I should change the wording and not mention Unraid automatically starting an array operation?

[Frank1940]

If the message (that I received is an error in logic in the sub-routine is the reason I got it, the message is fine.  The thing thatcaused me confusion is this one:

 

 

If this were changed to:   Event: Parity Check Required

 

Then it would be clearer what was happening.  Obviously, the logic that sends out the message has to be fixed so that it is not sent out when a clean shutdown are actually the case! 

[bambi73]

Updated from 6.12.3 at Saturday, switched back to macvlan/macvtap and so far so good, no traces.

Only problem I had is same as many others there, I got unclean shutdown notification. Which is not something I would expect when I always stop array before restarting/shutting down.

[ljm42]

@IFireflyl I moved your posts to their own thread: 

 

[Frank1940]

5 minutes ago, Frank1940 said:

If the message (that I received is an error in logic in the sub-routine is the reason I got it, the message is fine.  The thing thatcaused me confusion is this one:

 

 

If this were changed to:   Event: Parity Check Required

 

Then it would be clearer what was happening.  Obviously, the logic that sends out the message has to be fixed so that it is not sent out when a clean shutdown are actually the case! 

 

Further thoughts on this:  If the fact that this message is required by Developer Plugin Conventions, then change this line:

 

    Subject: [ELSIE1] Automatic unRaid Parity-Check will be started by Parity Check Tuning plugin

 

 

[itimpi]

1 minute ago, Frank1940 said:

 

Further thoughts on this:  If the fact that this message is required by Developer Plugin Conventions, then change this line:

 

    Subject: [ELSIE1] Automatic unRaid Parity-Check will be started by Parity Check Tuning plugin

 

 

There is no REQUIREMENT to output a message at all   The plugin has to determine if there has been an unclean shutdown for its own purposes as that means it cannot restart an array operation that was already in progress at the time of the shutdown.  Since the plugin has detected the unclean shutdown it seemed a good idea to pass this information on to the end user even when a restart was not potentially going to be attempted.

 

I want the event field to identify what has generated the notification (as is the case elsewhere).

It is the Subject and/or Description fields that can be changed.   However your suggested wording would be inaccurate as It is NOT the plugin that starts the automatic check it is the core Unraid system.

[ljm42]

@johnwhicker I moved your posts to their own thread 

 

[Kilrah]

I think having the notif is good since AFAIK Unraid doesn't provide one, but... it of course needs to match what unraid actually does.

 

Edited September 4, 2023 by Kilrah

[ljm42]

On 9/2/2023 at 4:32 AM, danioj said:

My only gripe is that the upgrade caused a Parity Check.

 

On 9/3/2023 at 2:22 AM, caplam said:

reboot triggered a parity check (unclean shutdown detected)

 

On 9/3/2023 at 3:47 AM, faxxe71 said:

- reboot triggered also a parity check (unclean shutdown detected)

 

FWIW, this was an issue that happened when shutting down 6.12.3, it was not related to the upgrade to 6.12.4.

 

The upgrade changes the files on the flash drive, it does not change the running system. So applying an upgrade will have no effect on whether the running system is able to shutdown properly.

 

i.e. the unclean shutdown likely would have happened the next time you rebooted, regardless of whether an upgrade was involved or not.

 

Please see this thread for more discussion and a recommendation:

  https://forums.unraid.net/topic/144649-6123-unclean-shutdown/#comment-1302638

 

 

I don't know why your systems had this issue. It would be helpful if you check the logs folder on your flash drive for diagnostics with the right date and upload them to that thread so I can look for clues.

[DivideBy0]

6 minutes ago, ljm42 said:

 

 

 

FWIW, this was an issue that happened when shutting down 6.12.3, it was not related to the upgrade to 6.12.4.

 

The upgrade changes the files on the flash drive, it does not change the running system. So applying an upgrade will have no effect on whether the running system is able to shutdown properly.

 

i.e. the unclean shutdown likely would have happened the next time you rebooted, regardless of whether an upgrade was involved or not.

 

Please see this thread for more discussion and a recommendation:

  https://forums.unraid.net/topic/144649-6123-unclean-shutdown/#comment-1302638

 

 

I don't know why your systems had this issue. It would be helpful if you check the logs folder on your flash drive for diagnostics with the right date and upload them to that thread so I can look for clues.

 

So this statement is not accurate then?  " The array should now stop successfully (This issue was resolved with 6.12.3)"

 

I mean what is done is done, but folks should know the issue is not fixed and manual interaction is still required, just to be on the safe side?

Edited September 4, 2023 by johnwhicker

[ljm42]

1 minute ago, johnwhicker said:

So this statement is not accurate then?  " The array should now stop successfully (This issue was resolved with 6.12.3)"

 

reload the page : )