3rd party plugins do require an update to have their communication monitored.  This is because not all communication is paused under any circumstances.  Notably, notifications will always go through to a browser that is otherwise paused.

 

 

55 minutes ago, csb said:

However, plugins like Dynamix System Temperature show live updates in the bottom status bar on all Unraid pages. These updateds are actually paused in out-of-focus Docker and Dashboard tabs, but not when e.g. the "Plugins" page is out of focus.

The current implementation in Unraid 7.1-beta2 only pauses Nchan communications, most plugins don't use Nchan but use regular 'post' requests to obtain information from the server. These post requests are not paused, but a browser may pause post requests by itself for any out-of-focus (hidden) pages.

 

Post requests have no impact on Nchan communication (i.e. can not cause Nchan to run out of memory).

 

9 minutes ago, bonienl said:

The current implementation in Unraid 7.1-beta2 only pauses Nchan communications, most plugins don't use Nchan but use regular 'post' requests to obtain information from the server.

That does indeed explain the observed behavior, thank you.

 

9 minutes ago, bonienl said:

but a browser may pause post requests by itself for any out-of-focus (hidden) pages.

Sadly, out-of-focus does not appear to necessarily equal hidden. Hence, my complaint that this negatively affects dashboard monitoring in a second browser window and my ability to see what is and isn't frozen by feature. This might be a client sided setting in Firefox, though, I'll look into this further.

 

Can you guys affected with this add this to your "go" file (/config/go on the flash drive) and reboot. (In particular if you have a dual socket CPU system)

 

sed -i '/worker_processes  1;/a\worker_cpu_affinity 01;' /etc/nginx/nginx.conf

 

So that the go file looks like this:

 

#!/bin/bash
# Start the Management Utility
sed -i '/worker_processes  1;/a\worker_cpu_affinity 01;' /etc/nginx/nginx.conf
/usr/local/sbin/emhttp 

 

 

Does that make any difference in eliminating the out of shared memory issues?

Am I impacted by this issue as well? Anyone can shed some light?

 

4 hours ago, kilonde said:

Am I impacted by this issue as well? Anyone can shed some light?

 

Why would you think you are?  what are you seeing on the dashboard for instance?

16 hours ago, Squid said:

Why would you think you are?  what are you seeing on the dashboard for instance?

The server goes completely unresponsive for no reason or user action. It can come back alive after several hours, sometimes not. 

14 minutes ago, kilonde said:

The server goes completely unresponsive for no reason or user action. It can come back alive after several hours, sometimes not. 

You'd need to set up the syslog server (mirror it to flash), and then after this all happens, post your diagnostics when it comes back, or if you have to force a reboot, post the diagnostics and the syslog.txt file that'll get saved in the logs folder on the flash drive.

 

Create a new thread, as initially I don't think this issue is the same as yours.

The issue does still happen on UNRAID 7.0.1

 

nchan stats https://tower.local/nchan_stub_status

total published messages: 8639286
stored messages: 0
shared memory used: 130308K
shared memory limit: 131072K
channels: 0
subscribers: 0
redis pending commands: 0
redis connected servers: 0
redis unhealthy upstreams: 0
total redis commands sent: 0
total interprocess alerts received: 0
interprocess alerts in transit: 0
interprocess queued alerts: 0
total interprocess send delay: 0
total interprocess receive delay: 0
nchan version: 1.3.7

 

syslog

Apr 24 16:17:47 tower nginx: 2025/04/24 16:17:47 [error] 4015853#4015853: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory.
Apr 24 16:17:47 tower nginx: 2025/04/24 16:17:47 [error] 4015853#4015853: *10106188 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost"
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [crit] 4015853#4015853: ngx_slab_alloc() failed: no memory
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: shpool alloc failed
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory.
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: *10106193 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost"
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [crit] 4015853#4015853: ngx_slab_alloc() failed: no memory
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: shpool alloc failed
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory.
Apr 24 16:17:48 tower nginx: 2025/04/24 16:17:48 [error] 4015853#4015853: *10106194 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost"

 

15 minutes ago, pixeldoc81 said:

The issue does still happen on UNRAID 7.0.1

Try 7.1.0-rc.1, there were some changes made that may help.

7.1.0-rc.1 - 4 days no nginx errors

I am still on 7.0 as I am waiting a few days to update to 7.1

 

It has happened to me twice in the past 24 hours (likely an open tab that I need to find), so I have updated my manual process with a script; the echo lines tell you what it does

 

#!/usr/bin/env bash

echo "Cleaning up /var/log/syslog"
> /var/log/syslog   &\
> /var/log/syslog.1 &\
> /var/log/syslog.2


echo "Cleaning up /var/log/nginx/error.log"
> /var/log/nginx/error.log &
> /var/log/nginx/error.log.1

echo "Find the master process and kill it"
ps -axfo pid,ppid,uname,cmd | grep nginx | grep -v '\\_' | awk '{print $1}' | xargs kill -9

echo "Wait 10 seconds"
sleep 10

while true; do
    echo "Attempting to start nginx"
    /etc/rc.d/rc.nginx start
    sleep 10
    echo "Check nginx status"
    /etc/rc.d/rc.nginx status | grep "is running" && echo "nginx is running"; exit 0
done

I also added it to my GH https://raw.githubusercontent.com/mmartial/unraid-study/refs/heads/main/varlog_nginx.sh

 

1 hour ago, martial said:

I am still on 7.0 as I am waiting a few days to update to 7.1

 

When you do upgrade to 7.1, please try it without your script and see how the OS handles this situation now

3 hours ago, Squid said:

When you do upgrade to 7.1, please try it without your script and see how the OS handles this situation now

I just did, I saw 7.1.1 released followed up by 7.1.2 so I was unclear if I should wait, but that error convinced me. Will report if I see it again. Thank you

Version 7.1.2 (and maybe 7.1.0+, I didn't install those and I upgraded directly to 7.1.2) of UnRaid add the "nchan_max_reserved_memory" directive the the nginx configuration file. If (like me) you were adding that in the go file for previous versions, nginx will not start after the update to 7.1.2 and you will not be able to get to the web interface. If this happens to you it's because the "nchan_max_reserved_memory" is in the nginx config file twice and that will cause nginx to not start.

On 5/14/2025 at 4:23 PM, Squid said:

When you do upgrade to 7.1, please try it without your script and see how the OS handles this situation now

Just wanted to say thank you.

I am leaving browsers on multiple systems open on the various pages of the dashboard and not a single occurrence!

unRAID 7.1.4 has been running about a week or two but getting this today:

total published messages: 3173183
stored messages: 6534
shared memory used: 78236K
shared memory limit: 262144K
channels: 20
subscribers: 5
redis pending commands: 0
redis connected servers: 0
redis unhealthy upstreams: 0
total redis commands sent: 0
total interprocess alerts received: 0
interprocess alerts in transit: 0
interprocess queued alerts: 0
total interprocess send delay: 0
total interprocess receive delay: 0
nchan version: 1.3.7

stored messages and shared memory usage are increase about 1 and 4-8kB per second respectively. I had the WebUI open on a few tabs across two machines. I closed the browser completely on one machine (Chrome) and made sure there were no zombie processes or anything. No change.

Other machine, I went to the tab and it looked to briefly refresh and had a bunch of very quick updates. Going back to the debug output and it's back to

total published messages: 3174928
stored messages: 19
shared memory used: 56K
shared memory limit: 262144K
channels: 20
subscribers: 5
redis pending commands: 0
redis connected servers: 0
redis unhealthy upstreams: 0
total redis commands sent: 0
total interprocess alerts received: 0
interprocess alerts in transit: 0
interprocess queued alerts: 0
total interprocess send delay: 0
total interprocess receive delay: 0
nchan version: 1.3.7

I didn't get to nginx falling over with out of memory errors but I suspect they would have started once it reached the 256MB on shared memory used

So it's still an issue with 7.1.4 unfortunately.

What do we need to do to get this fixed? My server is now getting hard locked daily because of this bug and there is seemingly no way to fix it.

I can't really trust Unraid to behave anymore so am now actively seeking alternatives.

2 hours ago, mhmatthall said:

What do we need to do to get this fixed? My server is now getting hard locked daily because of this bug and there is seemingly no way to fix it.

I can't really trust Unraid to behave anymore so am now actively seeking alternatives.

Are you sure it's this problem? Have you confirmed http://<ip of unraid>/nchan_stub_status is showing increasing memory usage? In my experience this doesn't "hard lock" the server at all.

It's a bit hard to test but changing Settings->Display Settings->Allow realtime updates on inactive browsers to "No" might help.

Basically if you change to another window after a few seconds the live updates stop.

Edited October 2, 2025Oct 2 by Shonky