February 17, 20251 yr total published messages: 2681425 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: Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory. Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: *3131170 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory. Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: *3131171 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /devs. Increase nchan_max_reserved_memory. Feb 17 23:21:18 server nginx: 2025/02/17 23:21:18 [error] 3495097#3495097: *3131172 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/devs?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory. Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: *3131173 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory. Feb 17 23:21:19 server nginx: 2025/02/17 23:21:19 [error] 3495097#3495097: *3131178 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory. Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: *3131179 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory. Feb 17 23:21:20 server nginx: 2025/02/17 23:21:20 [error] 3495097#3495097: *3131180 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory. Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: *3131181 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/cpuload?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /disks. Increase nchan_max_reserved_memory. Feb 17 23:21:21 server nginx: 2025/02/17 23:21:21 [error] 3495097#3495097: *3131182 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Feb 17 23:21:22 server nginx: 2025/02/17 23:21:22 [crit] 3495097#3495097: ngx_slab_alloc() failed: no memory Feb 17 23:21:22 server nginx: 2025/02/17 23:21:22 [error] 3495097#3495097: shpool alloc failed Feb 17 23:21:22 server nginx: 2025/02/17 23:21:22 [error] 3495097#3495097: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory. dmesg: [Mon Feb 17 23:20:06 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:20:06 2025] nginx[3495093]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 10 (core 2, socket 0) [Mon Feb 17 23:20:06 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:21:06 2025] nginx[3495097]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 1 (core 1, socket 0) [Mon Feb 17 23:21:06 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:21:07 2025] nginx[3496422]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 3 (core 3, socket 0) [Mon Feb 17 23:21:07 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:22:07 2025] nginx[3496423]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 1 (core 1, socket 0) [Mon Feb 17 23:22:07 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:22:08 2025] nginx[3497690]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 9 (core 1, socket 0) [Mon Feb 17 23:22:08 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:23:07 2025] nginx[3497742]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 11 (core 3, socket 0) [Mon Feb 17 23:23:07 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:23:08 2025] nginx[3498986]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 3 (core 3, socket 0) [Mon Feb 17 23:23:08 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:24:07 2025] nginx[3499049]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 9 (core 1, socket 0) [Mon Feb 17 23:24:07 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:24:10 2025] nginx[3500248]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 11 (core 3, socket 0) [Mon Feb 17 23:24:10 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:25:20 2025] nginx[3500304]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 8 (core 0, socket 0) [Mon Feb 17 23:25:20 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:25:20 2025] nginx[3502195]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 11 (core 3, socket 0) [Mon Feb 17 23:25:20 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:25:22 2025] nginx[3502196]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 10 (core 2, socket 0) [Mon Feb 17 23:25:22 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [Mon Feb 17 23:25:22 2025] nginx[3502201]: segfault at 0 ip 0000000000000000 sp 00007ffdb7dbe498 error 14 in nginx[400000+24000] likely on CPU 2 (core 2, socket 0) [Mon Feb 17 23:25:22 2025] Code: Unable to access opcode bytes at 0xffffffffffffffd6. Unraid 7.0.0 with latest Patch (also happend on Unraid 6.11.x - 6.12.x) VM1 Firefox on Windows Tab: https://tower.local/VMs/UpdateVM?uuid=83303fef-9e86-cdb9-6382-2d241f21adb3 Running for some days i guess PC Firefox on Windows Tab: https://tower.local/Docker Running for some days with hibernation inbetween Edited February 17, 20251 yr by pixeldoc81 Update
March 1, 20251 yr On 2/18/2025 at 11:55 AM, limetech said: There is a possible fix for this in upcoming v7.0.1 release. It did not fix my issue.
March 1, 20251 yr Not sure if this symptom been reported, but a couple of times I've gone back to a browser tab with a dashboard page showing. This could have been even after sleeping/hibernating the machine with the tab open. I see it very quickly updating i.e. there's a bunch of queued updates somewhere (likely buffered on the unRAID side given the memory issue). Quickly going to that diag link and I see the memory allocated figure drop rapidly to something like 500kB. Perhaps it's something like tabs being put partly to sleep in Chromium so they're not updating or at least not able to receive updates. Do the updates get pushed from the unRAID side rather than requested by the client? For the record it's not happened in 7.0.1 so far but it's only early days for me. It only happens rarely since I'm very careful to not leave tabs open because of this issue specifically.
March 5, 20251 yr On 2/6/2025 at 2:22 AM, csb said: So far, a viable workaround is: close browser, ssh into server, restart nginx, reopen browser after. Thank you. This is the only temporary fix that has worked for me
March 5, 20251 yr Throwing my hat into the ring. I'm experiencing the same issue on 7.0. Will update to 7.0.0.1 to see if it improves. The strange thing is, these errors were timestamped at a time when I didn't have a tab open with the Unraid interface
March 6, 20251 yr On 2/18/2025 at 10:55 AM, limetech said: There is a possible fix for this in upcoming v7.0.1 release. Running v7.0.1, just ran into this exact issue... and this thread. I guess I'll try to make sure I close my tabs after I'm done with them.
March 13, 20251 yr Updating to V7.0.1 and my logs are now being spammed by another message: 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036554 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036587 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:33 [alert] 5099#5099: worker process 3036591 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:35 [alert] 5099#5099: worker process 3036643 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:36 [alert] 5099#5099: worker process 3036675 exited on signal 6
March 15, 20251 yr On 3/13/2025 at 6:43 AM, iLaurens said: Updating to V7.0.1 and my logs are now being spammed by another message: 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036554 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:31 [alert] 5099#5099: worker process 3036587 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:33 [alert] 5099#5099: worker process 3036591 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:35 [alert] 5099#5099: worker process 3036643 exited on signal 6 ker process: ./nchan-1.3.7/src/store/spool.c:479: spool_fetch_msg: Assertion `spool->msg_status == MSG_INVALID' failed. 2025/03/13 12:37:36 [alert] 5099#5099: worker process 3036675 exited on signal 6 same errors for me too. I'm on 7.0.1 only thing I could do to resolve it is reboot.
March 15, 20251 yr Hard to believe this thread was started over five years ago (December 13, 2019) and still no fix. I guess this issue just doesn't affect that many users? I wonder what it is about our setups that could be causing this or perhaps we are just a minority that keeps a tab with the GUI opened. Edited March 15, 20251 yr by denzo
March 16, 20251 yr 11 hours ago, denzo said: I wonder what it is about our setups that could be causing this or perhaps we are just a minority that keeps a tab with the GUI opened. It only affects a few users, I leave a tab always open for both my main servers and don't see this, possibly some combination of other things.
March 17, 20251 yr On 3/16/2025 at 11:18 AM, JorgeB said: It only affects a few users, I leave a tab always open for both my main servers and don't see this, possibly some combination of other things. I suppose more than a few. I also have this problem and I didn't write, I've just been waiting for a few years for this to be fixed... I changed the server configuration during this time and still the same. The fact is that I always have browser tabs open on my desktop. For several years I have had a script in cron that restarts nginx every 1 hour.
March 18, 20251 yr 1 hour ago, r4id said: I suppose more than a few. I also have this problem and I didn't write, I've just been waiting for a few years for this to be fixed... I changed the server configuration during this time and still the same. The fact is that I always have browser tabs open on my desktop. For several years I have had a script in cron that restarts nginx every 1 hour. I'm not knowledgeable about scripts/cron is it relatively easy to do? By easy I mean like copy/paste? Sorry I'm just not very good with stuff like that.
March 18, 20251 yr I can confirm that 7.0.1 did not (fully?) fix this issue for me either. While I haven't had a catastrophic failure of actually running out of shared memory since the upgrade (likely because I'm more sensitive to the bug now and know how to work around and avoid it), I'm still getting tons of nginx: 2025/03/18 08:27:38 [alert] 12593#12593: worker process 2927495 exited on signal 6 and rapidly filling, and thereafter never really emptying, "shared memory used" whenever my desktop with open tabs to Unraid wakes from standby. So the issue remains unresolved.
March 18, 20251 yr 7 hours ago, denzo said: I'm not knowledgeable about scripts/cron is it relatively easy to do? By easy I mean like copy/paste? Sorry I'm just not very good with stuff like that. That sounds like an awful and potentially risky "solution" to this problem. I wouldn't trust that all those little scripts, actions and plugins on Unraid that ask you to please leave their script window open while they run and/or require interactive prompts would entirely happy to have nginx forced closed underneath them. In my experience, it also wouldn't actually properly resolve the issue. The "worker process xxxxxxxx exited on signal 6" alerts keep coming even after an nginx restart, and the share memory keeps filling up until the offending browser tabs are closed. An hourly restart of nginx would indeed likely prevent it from ever reaching the shared memory limit, but that's an awfully ugly workaround. "Close all open tabs and manually restart nginx via SSH" whenever needed is almost certainly still the better approach here.
March 18, 20251 yr 1 hour ago, csb said: That sounds like an awful and potentially risky "solution" to this problem. I wouldn't trust that all those little scripts, actions and plugins on Unraid that ask you to please leave their script window open while they run and/or require interactive prompts would entirely happy to have nginx forced closed underneath them. In my experience, it also wouldn't actually properly resolve the issue. The "worker process xxxxxxxx exited on signal 6" alerts keep coming even after an nginx restart, and the share memory keeps filling up until the offending browser tabs are closed. An hourly restart of nginx would indeed likely prevent it from ever reaching the shared memory limit, but that's an awfully ugly workaround. "Close all open tabs and manually restart nginx via SSH" whenever needed is almost certainly still the better approach here. I don't close tabs and I don't have to log in. I don't see nginx being restarted. Unraid stopped hanging after a few days. It's been working like this for a few years. So I consider this solution safe.
March 18, 20251 yr 8 hours ago, denzo said: I'm not knowledgeable about scripts/cron is it relatively easy to do? By easy I mean like copy/paste? Sorry I'm just not very good with stuff like that. install apps "user scripts". Then in settings - user scripts "add new scripts" : #!/bin/bash /etc/rc.d/rc.php-fpm restart Set it to start every hour and that's it.
March 18, 20251 yr 7 hours ago, r4id said: install apps "user scripts". Then in settings - user scripts "add new scripts" : #!/bin/bash /etc/rc.d/rc.php-fpm restart Set it to start every hour and that's it. Thanks! That was easy! Appreciate it.
March 20, 20251 yr Same for me with Version 7.0.1: unRAID nginx: 2025/03/20 11:39:30 [error] 4070043#4070043: nchan: Out of shared memory while allocating channel /cpuload. Increase nchan_max_reserved_memory ...
March 29, 20251 yr A couple of things I have noticed so far: "Live Updates Paused" triggers even when the dashboard is open on my secondary screen for active monitoring. Annoying. I'm aware that this is likely expected behavior, but it makes me wish the timeout internal were configurable - it's brutally short. Some (?) plugins completely ignore it: my Tasmota dashboard plugin keeps happily updating, even when "Live Updates Paused" freezes other data, so this will likely not fix all leaks caused by plugins updating.
March 29, 20251 yr 1 hour ago, csb said: A couple of things I have noticed so far: "Live Updates Paused" triggers even when the dashboard is open on my secondary screen for active monitoring. Annoying. I'm aware that this is likely expected behavior, but it makes me wish the timeout internal were configurable - it's brutally short. Some (?) plugins completely ignore it: my Tasmota dashboard plugin keeps happily updating, even when "Live Updates Paused" freezes other data, so this will likely not fix all leaks caused by plugins updating. The timeout is 30 seconds. You can disable this entire thing via Settings, Display Settings, Allow RealTime updates. Any issues with nginx_out_of_shared_memory has absolutely nothing to do with any docker containers etc as they don't use the basic internal subsystem at all. But, if you have been receiving the error regularly on previous versions, I'd highly recommend you keep the operation as is. If you still get the error, then I have a good idea as to what the next steps are for the mitigations. If the error completely disappears, then you can try allowing real-time updates, as there is another part of the fix that by itself might have fixed it, we need to know if the default disallowing fixes it first
March 29, 20251 yr 2 minutes ago, Squid said: Any issues with nginx_out_of_shared_memory has absolutely nothing to do with any docker containers etc as they don't use the basic internal subsystem at all. I'm sorry, I'm unable to follow you here: At what point do you think that I was talking about docker containers "etc"? I was talking about Unraid plugins (or do you consider those "etc."?) and was giving the feedback that not all dashboard live updates are correctly frozen with this new feature in place. While, e.g. the information on "Dynamix" developed plugins appear to no longer provide live updates when "Live Updates Paused" triggers, the popular "GPU Statistics", "Plex Streams" and "Tasmota Power Monitor" plugins continue to display live updates on the Dashboard when live updates should, supposedly, be paused. Given, that there has long been the suspicion that certain plugins could at least exacerbate this issue, I'm surprised you felt the need to dismiss this observation so readily. As limiting as it can clearly be, I will likely keep this new feature in place for now and see if I can still observe the dreaded "worker process xxxxxx exited on signal 6" errors. That said, while I have seen the dreaded log-spam and increasing shared memory used values, I have yet to come close to actually running out of shared memory since the 7.0.1 update. Maybe that has already been fix enough.
March 29, 20251 yr And another observation: "Live Updates Paused" appears to exclusively trigger on pages that, traditionally, show live updates, like the Dashboard or the Docker tab. This does feel quite sensible at first glance. 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.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.