DanielCoffey

Thank you - in that case I will probably do a totally clean install when 7.0.xx drops to clean anything I have accumulated over the past few years. I assume the things I would be advised to back up would be my USB thumb drive, shares and users then screenshot the drive assignments and Docker parameters. My plugins are minor plus there are only two Dockers and no VMs.

I am interested in knowing whether routine Updates to Unraid (say from 6.12.13 to 6.12.14) perform a totally clean install of everything apart from the Docker Config and drive assignments or whether any hardware settings are retained? Would 6.12.xx to 7.0.xx be any different? The reason I ask is that I am still experiencing very slow Plugin and Docker updates despite asking for opinions on my network and router config. No consensus was reached and the issue seemed to start after an earlier Unraid update when I wasn't paying attention to the time taken. I am talking about 12 seconds to check a single plugin to see if there is an update and about 8 seconds to check a Docker for an update despite a quiet router and fast broadband. Recently I have noticed that when a Plugin actually does have an update, the step "Executing hook script: pre_plugin_checks" seems about as slow to execute as asking to refresh the list of plugins. If Unraid preserves some hardware and network settings between updates I am considering a full and clean reinstall when Unraid 7 arrives although setting up my Dockers again is something I don't have a lot of experience with.

I assume you were looking at the 4Gb B800Pi SLC model instead of the B600Sc MLC, yes?

Names lookup instantly too.

Now that was very revealing, thank you. My unraid server seems to be set up for IPv4 but my Windows machine is IPv6 so I get different results depending which machine I ping/traceroute from. hub.docker.com is 100% packetloss on both machines since I suspect the server does not respond to pings. Both machines get partial results from traceroute/tracert. Each line of traceroute is slow to appear, regardless of which machine I run it on. raw.githubusercontent.com pings perfectly on both machines but Unraid is slow to start pinging. With traceroute, the Windows PC gets most of the hops normally but Unraid is again slow to start the traceroute, loses one, picks up again and then drops the thread. Any thoughts as to the issue? If told how, I could attempt to turn on IPv6 on the Unraid box.

Update 03 September : I have downloaded and created a Trial USB stick and added the exact same plugins. There was no change to the time taken to Check for Updates. Still 36 seconds for 6 plugins. That hopefully eliminates anything inside the UNRAID box as the issue. I don't have any easy way to connect to a wifi hotspot without reconfiguring my router as an access point and totally messing my home network. Is there a listing of the server address that the Check for Updates contacts so that I can ping and tracert to it from the UNRAID box?

Thank you for the idea. Are there instructions for doing this without messing up my main flash drive (which I have just remembered is installed internally on a header... means pulling out the box to get at it)? I have already loaded unraid in safe mode before and it made no difference.

I am still having issues with slow plugin checking and would appreciate some thoughts on the cause. I can add that it is consistent, 24s to check two Dockers and 36s for 6 plugins. I can ping from the server to Google DNS and get 16ms responses as normal. Asking for OS Updates is instant and fast. Docker Updates are fast. It is just the checking that is slow. Could it be an issue of my ISP resolving just the checking server? Is there an address I can ping to test it?

Just an update. I have reset back to 8.8.8.8 and 8.8.4.4 for my DNS and rebooted both my server and router/switch. I am still getting slow responses for each plugin when checking for updates. When I open a command prompt in the UI and ask unraid to tell me the dns server it responds fine. Ping works quickly too. I still don't know why the plugins are so slow to check for updates however.

Any routers or switches with a mains transformer (wall wart) should be fine to put on a normal 4-way adapter and then put that into the UPS... but you may have to modify the plug of the adapter so that it fits into the UPS.

Ignore the gigabit in/out sockets. That is merely intended to be a surge suppressor for your WAN cable to protect your router. Wall to Gigabit In. Gigabit Out to Router WAN. The only cable you need to connect for regular use is the "USB & Serial" one. That allows the UPS to communicate with your server. Be aware that the max load of the UPS is relatively small (550W) and being a discontinued product are you certain the battery is in good condition? I can't answer your second question as I only have the one server on my own UPS.

Which speed test docker would you recommend with a simple setup please? I have CA but there are a few to choose from.

I stopped the Docker process and edited the Network Settings to point to those OpenDNS addresses and rebooted the server but nothing changed. I entered Safe Mode, started the server and checked the time to update the Dockers and it was unchanged at 24s. I have reverted to the normal unraid mode and rebooted the server. but there is still no change - 36s to check plugins for update.

When manually Checking for Updates it is taking around 37 seconds to check 6 Plugins and 24 seconds to check 2 Docker Containers. Around a month or so ago it was fast and only took about 5 seconds but something changed during that time and it is consistently slow now. From searching the forum I believe it may be a DNS issue but I don't know how to troubleshoot it. Please could someone check my Diagnostics and advise what I should check or alter please? nas-plex-diagnostics-20240816-1612.zip

I will check, thank you. It is an ASUS H370 ITX board on the 2811 bios. I would have to connect a monitor to see what bios options were available but it could be well worth a rummage in the Sleep settings.

If Sleep worked perfectly every time, it makes bringing the server up very convenient for me as it is tucked away in a spare room. From my desktop PC I can issue a WakeOnLAN command from a small app and 30 seconds later the server is available for us to use. Of course I still have to use the GUI to Sleep and I agree that is the same amount of effort as selecting Shut Down. Bringing the server up after a Shut Down requires going up to the server and pressing the power button so I may have to move it to a more prominent position. It also takes a good few minutes before it is ready to use. I know it is really just a small inconvenience but it is an irritation when there is a function (Sleep) that is supposed to make it easier but fails to work reliably and does not appear to have been thoroughly discussed for almost ten years.

Thanks bonienl for the tip on using "IPv4 only" for my specific server and router combination. It has certainly stopped any network errors in the logs and fixed the inability to access the GUI after inactivity. I am still plagued by the issue of Sleep not working reliably but this seems to be an ancient unraid issue dating back nearly ten years according to Google. I would prefer not to Shutdown the server daily but would also like to avoid the electricity cost of running the server 24/7 when it is only actually used for about 2 hours a day. Looks like I will have to Sleep then go and check if it actually has done it.

Well it has failed to Sleep again even under IPv4. I left the server running for three days and it was perfect, no isses, no errors in the log so after using Plex today I slept the server. It failed to Sleep and I didn't notice for a few hours. Once I spotted the server awake I slept it again and this time it worked. The issue occurred in the syslog at Jul 19 18:58:24 NAS-PLEX s3_sleep: Enter sleep mode I really would prefer to have the server Sleeping when not in use as according to the UPS it is using about 40W with drives spun down. Any thoughts as to the crash on sleep? nas-plex-diagnostics-20230719-2300.zip syslog-192.168.1.11.log

I have an ASUS RT-AX86U running Merlin's firmware on a Giganet FTTP connection and the IPv6 page shows it is set to Native (PPPoE), PPP which seems correct according to ASUS' wiki. The motherboard is about 6 years old as you can see from my sig so it might be something to do with IPv6 support on that. I am not too bothered if the change back to IPv4 corrects the issue with the GUI being inaccessible. I'll watch it for a couple of days then revert to my normal "Sleep after using the server for the day" routine. I do have a secondary issue of Plex failing to find my media after about a day which requires a Docker restart but perhaps it is also connected to this issue. I will monitor Plex and raise a separate Issue if I still have problems with that Docker. Thank you everyone for the assistance and hopefully I can flag the post as Solved in a couple of days.

Thank you - I have stopped the array, set IPv4 Only and applied that change followed by a shutdown and reboot of the server. Everything came up cleanly and a peek at the syslog shows that there are no references to IPv6. Here is a Diagnostic if it is needed of the server in a healthy state and I will monitor it over the next couple of days allowing the server to remain powered on. nas-plex-diagnostics-20230716-1125.zip syslog-192.168.1.11.log

Alright - it has done it again - the server is inaccessible via the GUI after a period of inactivity and has to be rebooted. Changes I made since last time are... 1. Upgraded to 6.12.3 and Rebooted the server 2. Set HDD spin down time from Never to 30 mins (no idea why I had set it to Never in the past) 3. Instead of Sleeping the server yesterday evening I left it active overnight. Interesting events during the overnight inactivity (no idea if they are significant)... Jul 16 03:53:26 NAS-PLEX apcupsd[2501]: Power failure. Jul 16 03:53:26 NAS-PLEX apcupsd[2501]: Power is back. UPS running on mains. Also... Jul 16 05:15:50 NAS-PLEX kernel: nginx[14966]: segfault at 218b8 ip 00000000004e7630 sp 00007ffdaebced40 error 4 in nginx[424000+110000] likely on CPU 0 (core 0, socket 0) Jul 16 05:15:50 NAS-PLEX kernel: Code: 40 00 48 8b 47 08 ba 80 33 e1 01 48 85 c0 48 0f 44 c2 c3 0f 1f 80 00 00 00 00 48 83 7f 20 00 74 19 48 83 ec 08 e8 30 48 02 00 <48> 8b 40 08 48 83 c4 08 c3 0f 1f 80 00 00 00 00 48 8b 47 10 c3 66 Jul 16 05:15:50 NAS-PLEX nginx: 2023/07/16 05:15:50 [alert] 2830#2830: worker process 14966 exited on signal 11 Also an unusual event this morning that spammed a lot of log file. Time stamp starts here and continues... Jul 16 06:21:42 NAS-PLEX nginx: 2023/07/16 06:21:42 [alert] 2830#2830: worker process 18163 exited on signal 6 Jul 16 06:21:42 NAS-PLEX nginx: 2023/07/16 06:21:42 [alert] 2830#2830: shared memory zone "memstore" was locked by 18163 I was unable to access the GUI at about 07:38:00 so short-pressed the Power Button to trigger a shutdown which worked as expected. nas-plex-diagnostics-20230716-0842.zip syslog-192.168.1.11.log

I will perform a clean reboot and test the Plex docker. It should only take a couple of days to test and find out. Thank you for the help.

Got it, sort of. This time it failed to Sleep and left messages in the syslog. I tried to command it to go to Sleep at Jul 14 18:27:28 and also 18:29:41 and it did not do so. I was able to get back in to the GUI on the browser which was helpful. nas-plex-diagnostics-20230714-1933.zip syslog-192.168.1.11.log

Good to know. I have set up a cache-only share and pointed the syslog server to that. The system always comes back up after a power on so we should be able to get it. I will post back next time it occurs.

Actually when it happens again it is unlikely that will be able to run the diagnostic tool because I won't be able to access the GUI to trigger it.