xreyuk

Thanks, after some testing I also believe it's Unraid's WireGuard implementation. I am using this for plex streaming and using Wireguard get constant buffering (i was using this same setup before 7.x completely fine). Decided to setup tailscale for a test, and using tailscale is flawless. I then decided to try the wireguard docker and that also worked flawlessly.

Did you get this fixed? I’m having similar problems

I would also like to second this, it's quite common in the UK to have different rates for day/night. Thanks!

Also works fine here.

Yeah I meant that prometheus might have updated so it means the plugin might need updating. I'll ask in the prometheus support.

Yeah in Prometheus. It was previously working and had stopped so I assumed it might be an incompatibility with the exporter after an update?

Started getting this error on prometheus for the wireguard plugin. Error scraping target: non-compliant scrape target sending blank Content-Type and no fallback_scrape_protocol specified for target I think prometheus updated not long ago and could have something to do with it? Any ideas?

No worries, I tried the admin password and that didn't seem to work. Will wait and see if anyone else has an issue. Thanks for the work!

Thanks, I'll see if it's just me or whether anyone else has the same problem. Just to confirm, seeing as there is no API token anymore, is this supposed to be setup using the admin password or an 'app password' from the API page?

This still doesn't start for me, are there any logs I can give you? My PiHole is setup to use the internal certs and force you to a https webui (or force you to ignore it if cert authority isn't recognised) if that matters. I did a fresh install as you suggested.

Ahh okay thanks, I’ll try again. I implemented the WireGuard exporter and left it but still got no data on the graph using the json in the first post. *EDIT* Got it working, the datasource in the json had Prometheus instead of prometheus.

Hi, Thanks for these plugins, I'll be another awaiting the PiHole update if/when it comes. I'm assuming based off the dates on it, the wireguard exporter no longer works? I've installed it but don't populate any information on the graph.

Have we had confirmation that this works in Unraid 7? It doesn't seem to be for me.

I can only get to C8 on this version of powertop and unraid 7. On previous version I was able to get to C10. This is the output when running powertop or any of it's associated commands modprobe cpufreq_stats failed Loaded 0 prior measurements Cannot load from file /var/cache/powertop/saved_parameters.powertop File will be loaded after taking minimum number of measurement(s) with battery only RAPL device for cpu 0 RAPL device for cpu 0 Devfreq not enabled glob returned GLOB_ABORTED Cannot load from file /var/cache/powertop/saved_parameters.powertop File will be loaded after taking minimum number of measurement(s) with battery only Leaving PowerTOP

I have a single ZFS drive for cache which uses snapshots and backs up to the array using SpaceInvaderOne's method with the Sanoid, ZFS Master plugins and a script. Do I need to undo any of this for unraid 7?

Sorry I missed the 'timeout' bit. This seems to have brought it back to showing stats. Are there any other symptoms as a result of this? Thanks

Hi, I'm also having the same error as above and changing refresh to 2000 doesn't fix it. I've seen ich777 has updated his intel gpu top plugin but that also hasn't fixed it. Running the intel_gpu_top command via terminal gives me all the correct information. Do I still need to try updating? Can intel-gpu-top be updated manually if the plugin is installed? If so does anyone know where to find instructions?

Thanks, I think it may have been my 'snapshots' dir causing it. I use SpaceInvaderOne's replication script to replicate my ZFS cache snapshots to the array. It's possible I didn't have this in the previous caching as it would have been setup after Cache Dirs was setup, however I didn't think adding a share to cache dirs would have caused such a cpu spike! I'm seeing smaller cpu jumps over the same time period, which is only minor, but is there a setting I can use to adjust these? I don't write to the array very often so probably don't cache dirs updating this often.

I'm now having the spiking CPU issue with the latest version of Cache Dirs. The below is from a 30 second window of CPU activity. I didn't have this problem with the old 'incompatible' one. My settings are whatever defaults come with the plugin (including /mnt/user scanning turned off), except I have removed any directories on my cache, so only have array drives cached by the plugin, none of which are written to at the time (the disks are all spun down). These are the settings I've always had and it's been fine. Disabling the plugin completely stops this behavior. Any ideas?

install file activity plugin - it should tell you more information about what is accessed when the disks spin up. Do you have Recycle Bin installed? If that's set to daily it might be spinning up every night.

I have not had any problems with Dockers since upgrading however Fix Common Problems is recommending to install this patch anyway. Is it something you recommend installing 'just in case'?

Upgrade seems to have worked fine for me, it also seems to have stopped my custom docker network assigning ipv6 addresses even though ipv6 was disabled which is nice. Upgraded from 6.12.6

Thanks, the syslogs are from a time where I know the server was working to when the server crashed, e.g id been using it the night before so knew it was good, I didn’t see it relevant to post syslog information before that. ill have to get it setup to run in safe mode in a couple days as ill have to make provisions to do that (make sure dns is setup etc). all the hardware is new and RAM was memtested when the server was built. Ive seen so many posts in here the last few days with the same symptoms I’m just starting to think it’s a bug with unraid.

Hi, I have unraid running on the following hardware. Intel Core i3-12100 16GB Corsair Vengeance 3200Mhz RAM Gigabyte H610i Mini ITX Motherboard Corsair RMx 650W PSU 4 x 4TB Seagate IronPort HDDs in array, formatted in XFS 1 x Crucial P3 Plus 500GB NVME in Cache Pool formatted in ZFS. I have Dockers for Homebridge, Plex, Cloudflare DDNS, Sabnzbd, Sonarr/Radarr/Notifarr and Homarr dash. No CPU Pinning has been done except for Plex, which is pinned to Cores 3 and 4. The other dockers are able to use all available cores. I have one Debian VM running which has been assigned to core 2 - to avoid it using resources Unraid might need on core 1). It has 1GB RAM assigned and is running PiHole and Unbound. I use powertop and auto tune to tune the server where it can reach C10 states, however in the meantime I've had a crash where a PCI card was installed which prevented it going to less than C2 so don't think this is the problem. I have been experiencing frequent crashes since I installed Unraid at the start of January, in total I have logs for 4, but have experienced 5. 4 out of 5 crashes has left Unraid unreachable, non responsive to ping (including the VM's on it's own IP), whilst the box still has power. I have to manually power off and power on to get access back. 1 crash I was able to connect a keyboard/mouse/monitor and get a login prompt which seemed to bring it back to life. Parity checks are successful after unclean shutdown. The details and diagnostics/relevant syslogs are below. I have included syslogs from between the time I know the server to have been good, between the time I noticed it had crashed and needed to reboot. This is information for crashes 2-5 as crash 1 had no logs and I didn't take diagnostics. Crash 2 - 3rd Feb Crash occured in the early hours of the morning whilst sleeping, but woke up to the box non responsive to any login attempts and GUI inaccessible however all of my dockers and VM was still working. I managed to connect a monitor/mouse/keyboard and this gave me an unraid login after which the GUI became accessible again. Server had previously been up since 31st Jan, 'Syslog 2 and Diagnostics 2' relate to the below. The diagnostics was taken a bit later on the day as I didn't have chance when I noticed the crash. Syslog to me indicates it could be related to potentially running out of memory (for whatever reason) Crash 3 - 3rd Feb This crash I noticed around 8PM in the evening. Unraid, all my dockers and my VMs became unresponsive and the server would not respond to pings. No automated tasks were scheduled between the two crashes this day (except for whatever sonarr/radarr do) and the server had pretty much been idle most of the day. Had to power off and back on via power button to get server back. 'Syslog 3 and Diagnostics 3' contain information for this, obviously diagnostics was taken after the reboot. The syslog to me seemed to indicated an nginx crash may be the cause here. Crash 4 - Feb 10th This time it'd crashed again in the early hours of the morning, woke up to find exactly the same symptoms as Crash 3. Unresponsive to pings on both Unraid and the VM, server still powered on. Had to power on/off via power button to get server back. 'Syslog 4 and Diagnostics 4' related to this crash, obviously diagnostics taken after reboot. Syslog is literally empty so i have no idea. Crash 5 - Feb 11th Crash occurred around 9PM in the evening. Exactly the same symptoms as previous 2 crashes. Syslog 5 and Diagnostics 5 in the attached files are relevant. Syslog again seems literally empty to me so I have no idea. Only 'weird' thing I can see in the logs appears to be one nginx crash which could be related, and the other is that my dockers are assigning IPv6 addresses despite IPv6 being disabled in Unraid settings, as well as my custom docker network which also says IPv6 is disabled. The crashes only seem to occur when the HDDs are spun down, so the system is at very light load only serving DNS from unbound/Pihole basically. Any help would be greatly appreciated. Diagnostics 3.zip Diagnostics 4.zip Diagnostics 5.zip Syslog 2.txt Syslog 3.txt Syslog 4.txt Syslog 5.txt Diagnostics 2.zip