Jazer

Same here... my server (UI) crash with "out of memory". Restart nginx helped.

Setup: Unraid 7.0.0 Scenario: Install fresh Windows 11 or Ubuntu 24 LTE release with guest additions v0.1.299. I get a valid IP inside VM from DHCP. Internt works fine - local network devices are discoverd and ping-able beside "tower". Network: vhost0 / virtio-net 1) Inside VM: ping router [OK] 2) Inside VM: ping MacBook [OK] 3) From McBook: ping vm [OK] 4) From McBook: ping tower [OK] 5) Inside VM: ping tower [FAIL] 6) From Tower: ping vm [FAIL] The IP of tower is resolved successfully - but the ping can't reach "tower" by name nor IP. This is only a KVM problem and affects all VM's - Docker containers are not affacted. How can I fix this?

total published messages: 1830613 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 Yes - the load was shown. But honestly, I still don't really know what is causing the leak. I tested it with 16x open tabs and could not observe any significant increase for about 2h. After closing the lid of my laptop for some hours and coming back, am near the limit. *Maybe* messages/memory are not released after stalled connections or reconnecting causes it - im just guessing. Log: Jan 30 07:13:33 Tower nginx: 2025/01/30 07:13:33 [crit] 1257890#1257890: ngx_slab_alloc() failed: no memory Jan 30 07:13:33 Tower nginx: 2025/01/30 07:13:33 [error] 1257890#1257890: shpool alloc failed Jan 30 07:13:33 Tower nginx: 2025/01/30 07:13:33 [error] 1257890#1257890: nchan: Out of shared memory while allocating channel /shares. Increase nchan_max_reserved_memory. Jan 30 07:13:33 Tower nginx: 2025/01/30 07:13:33 [error] 1257890#1257890: *3172828 nchan: error publishing message (HTTP status code 507), client: unix:, server: , request: "POST /pub/shares?buffer_length=1 HTTP/1.1", host: "localhost"

total published messages: 1731910 stored messages: 157 shared memory used: 25524K shared memory limit: 131072K channels: 14 subscribers: 10 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 Latest FF // 2x Docker Tab (Adv. View) - 20 container running - Folder View plugin

total published messages: 1520977 stored messages: 18 shared memory used: 12000K shared memory limit: 131072K channels: 23 subscribers: 15 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 At least I'm oberving a constant increas of "shared memory used:", but I don't know whats causing it.

+1

Do I still get support here? Got following problem... I setuped my Macinabox Big Sur quite a while ago and it worked very well. At some point, maybe Unraid Update, my network stopped to work inside the VM (cable unplugged is shown). I tried all combos of card setting, w/o luck. I'm running the 7.0b3 - maybe Qemu changed and broke the support. XML is attached. Any ideas? mac.xml

I've a Intel 13500T and Jellyfin is running with option `--device=/dev/dri` (no external GPU) My iGPU is used, but only with 25% load... at the same time, my CPU has a load >900% Is this how it should be?

I've not found an option how to trigger the mover when a disk is utilized by X% (e.g. 80%). Is this somehow possible? Maybe with a script or so?

Same here... anything new on this topic? 1920 is really bad for mac users, because the XDR display uses 1728 points (not pixels) in HiDPI mode.

right... turns out to be memory issues

The network crashed not with the first kernel panic, but with the last. Weird. syslog

Sure... tower-diagnostics-20230322-0923.zip