DanielCoffey

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.

Thank you, I will do that. It may take a while to reproduce but I will run the log server until then.

I have been having infrequent issues with my server apparently dropping off the network or being inaccessible from a browser and having to be shut down by its own power switch and wondered whether I am developing a hardware issue with it. I would appreciate some advice. Specs in my signature. Because the server is infrequently used for Plex once every day or two it spends a lot of time asleep to save power. I send it a Magic Packet using a WakeOnLAN tool to wake it up, check the Plex docker is active (it sometimes isn't - I suspect Plex timeout issues) and use it to watch a film. This always works without issue. Some time after the film is finished I open a browser on my main desktop or tablet and request it Sleep again. Most of the time it works exactly as expected (c. 90%). Occasionally the browser fails to present the server's GUI. The server is still visible on the Router list of devices connected but nothing will access the server. I have to go over to it and press the Power button to make the device perform a shut down. On a reboot it works perfectly... till next time. Until today. Today the quick press of the power button did nothing. No drive activity, nothing happening at all. I had to press and hold to force the PSU to shut down. Does this sound like a hardware issue to you? The motherboard perhaps? I do have a monitor I can connect to it for diagnosis if needed. Might there be logs stored in the Flash drive about possible causes?

@Revan335If you click the little "!" next to the 6.10.1 version number on teh Update page of the GUI it says...

Remember that your Parity drive must always match (or exceed) the capacity of the largest data drive and as you increase the size of the largest drive in the array, the time to perform a Parity Check increases. To give a data point, 8Tb drives take around 16h for a Parity Check and it is fairly linear with drive size.

Since this is a Release Announcement thread, you mightl have a better chance of getting help if you raise a new thread in either the General Issues or KVM forums.

Thank you - I will be able to follow that. If I get into difficulty I will come back and ask.

I am currently set up with a pair of 512Gb SSDs in a btrfs cache pool and I would like to know the smoothest way of moving over to a single M.2 SSD, preferably without having to redo my Docker settings if possible. Mt Forum Signature is up to date. I do understand that I should run Mover first. Thank you.

The Basic license will allow you to grow your array in the future and you do still get the full Docker and VM support that the larger two licenses also share.

On the NAS in my signature I came across a bottleneck today and I am interested in knowing what might have caused it. This is a lightweight NAS that serves one PLEX Docker and also acts as an on-site backup for my desktop PC. My wife was watching a movie that was already encoded correctly for the Apple TV and without thinking I decided to back up a large number of small files to the backup share while the movie was playing. Very quickly the movie started to stutter then froze until the file transfer was complete. The movie was streaming from one of the HDDs. I know from experience that Plex only causes the i3-8300 to go between 10% and 25% load as a chunk is requested. The file transfer was 4Gb in size with about 8500 small files. It was going to the Backup share which is Cache = Yes via FTP (FileZilla). The Source files were on my desktop NVME drive and went over Cat6 LAN through a 1Gb switch. The NAS cache drives are a pair of SSDs which are on the motherboard's SATA connectors. The HDDs go through the SAS9207-8i card. When I heard that the movie was stuttering I looked at the Dashboard and saw the CPU with a couple of cores pegged at 100% and the other two at about 80%. I also wondered if I might have saturated the motherboard's SATA lanes. Since it is only a 4-core CPU I do not have any core pinning. What do you think might have caused the bottleneck and what might I be able to do so that it is less likely to happen again?

And remember that if you have a cache drive, movies will sit on it and contribute to it filling up until the Mover process runs according to its schedule (or you manually kick it off yourself) at which point they should be sent over to the array shares.

I am at 2560x1440 on Win10 if that matters. If you want me to check it on other platforms I have a Mac Mini (also at 1440p) running Safari browser and an iPad.

I have just tried 6.8.0-rc1 to compare its parity checks to both 6.7.2 and the Tunables script since my array is very straightforward and the result is interesting and shows there is still room for improvement. The first thing I did before upgrading from 6.7.2 was reset all the Disk Settings tunables back to default (including nr-requests which defaults to auto now). My array is 2x WD Red 8Tb dual parity and 6x WD Red 8Tb data with 2x 512Gb SSD for cache. 6.7.2 default - 17h15 to 17h30 6.7.2 tunables - 15h30 6.8.0-rc1 default - 16h45 I have added a screenshot of the 6.7.2 Tunables and also 6.8.0-rc1 default values for comparison and I think there is still scope for improvement. I suspect that on my server we could find up to an hour in there that could be tuned out.

If you have a spare PCI slot you also have the option of adding an HBA card such as the LSI SAS 9201-8i which will have two SAS ports. Each of these can be connected to four SATA drives using a SAS to SATA cable giving a total of eight mroe SATA ports. There are reputable resellers on eBay who will sell tested and flashed cards ready to plug in and go. EDIT : This does assume you have spare slots in your unRAID license of course.