I have two issues that seem to creep up about 1 every month or two (different times of the month).

1. Docker vnets flapping

   1. This issue doesn't seem to cause anything but noisy logs but I'd like to know what's going on

2. php-fpm issue

   1. This is the real issue - when I start seeing these the UI freezes and I cannot run "docker ps", server terminal is laggy, UI goes down, I cannot restart php-fpm service. The only fix seems to be a reboot. This only seems to occur about every 40-90 days. I just rebooted again last night and am now reporting.

   2. Memory seems to be at about 70% utilization (of 128GB) (mostly consumed by a zfs pool)

   3. Diagnostics and logs from yesterday are attached.

I've tried debugging but by the time it happens I can't really maneuver the server so it's extremely hard to debug. Any assistance would be greatly appreciated.

Docker flapping issue sample

Jan  5 16:14:48 pumbaa kernel: br-2c57e8bd9fdb: port 10(veth9feb635) entered disabled state
Jan  5 16:14:48 pumbaa kernel: br-2c57e8bd9fdb: port 10(vethb028867) entered blocking state
Jan  5 16:14:48 pumbaa kernel: br-2c57e8bd9fdb: port 10(vethb028867) entered disabled state
Jan  5 16:14:48 pumbaa kernel: vethb028867: entered allmulticast mode
Jan  5 16:14:48 pumbaa kernel: vethb028867: entered promiscuous mode
Jan  5 16:14:51 pumbaa kernel: eth0: renamed from vethbee5c8d
Jan  5 16:14:51 pumbaa kernel: br-2c57e8bd9fdb: port 10(vethb028867) entered blocking state
Jan  5 16:14:51 pumbaa kernel: br-2c57e8bd9fdb: port 10(vethb028867) entered forwarding state
Jan  5 16:39:37 pumbaa kernel: br0: port 3(vnet1) entered disabled state
Jan  5 16:39:37 pumbaa kernel: vnet1 (unregistering): left allmulticast mode
Jan  5 16:39:37 pumbaa kernel: vnet1 (unregistering): left promiscuous mode
Jan  5 16:39:37 pumbaa kernel: br0: port 3(vnet1) entered disabled state
Jan  5 16:39:37 pumbaa kernel: usb 1-6.3: reset full-speed USB device number 6 using xhci_hcd
Jan  5 16:39:37 pumbaa kernel: cp210x 1-6.3:1.0: cp210x converter detected
Jan  5 16:39:37 pumbaa kernel: usb 1-6.3: cp210x converter now attached to ttyUSB0
Jan  5 16:40:43 pumbaa kernel: br0: port 3(vnet3) entered blocking state
Jan  5 16:40:43 pumbaa kernel: br0: port 3(vnet3) entered disabled state
Jan  5 16:40:43 pumbaa kernel: vnet3: entered allmulticast mode
Jan  5 16:40:43 pumbaa kernel: vnet3: entered promiscuous mode
Jan  5 16:40:43 pumbaa kernel: br0: port 3(vnet3) entered blocking state
Jan  5 16:40:43 pumbaa kernel: br0: port 3(vnet3) entered forwarding state
Jan  5 16:40:44 pumbaa kernel: cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Jan  5 16:40:44 pumbaa kernel: cp210x 1-6.3:1.0: device disconnected
Jan  5 16:40:48 pumbaa kernel: usb 1-6.3: reset full-speed USB device number 6 using xhci_hcd

php-fpm children dying sample

Jan  5 16:42:02 pumbaa php-fpm[14136]: [WARNING] [pool www] child 312763 exited on signal 9 (SIGKILL) after 133.889516 seconds from start
Jan  5 16:42:14 pumbaa php-fpm[14136]: [WARNING] [pool www] child 312765 exited on signal 9 (SIGKILL) after 145.724033 seconds from start
Jan  5 16:42:16 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327026 exited on signal 9 (SIGKILL) after 13.647382 seconds from start
Jan  5 16:42:26 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327446 exited on signal 9 (SIGKILL) after 11.937198 seconds from start
Jan  5 16:42:28 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327479 exited on signal 9 (SIGKILL) after 12.002520 seconds from start
Jan  5 16:42:34 pumbaa winbindd[3097]: [2026/01/05 16:42:34.383799,  0, traceid=179742] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn)
Jan  5 16:42:34 pumbaa winbindd[3097]:   open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_DISCONNECTED

Note: I know I have a failing drive -- replacement is on the way but that is not related as this stability issue has been happening for several months and the drive just started failing about a week ago.

pumbaa_logs.txt.zip pumbaa-diagnostics-20260105-1825.zip

57 minutes ago, geeksheikh said:

Jan  5 16:42:16 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327026 exited on signal 9 (SIGKILL) after 13.647382 seconds from start
Jan  5 16:42:26 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327446 exited on signal 9 (SIGKILL) after 11.937198 seconds from start
Jan  5 16:42:28 pumbaa php-fpm[14136]: [WARNING] [pool www] child 327479 exited on signal 9 (SIGKILL) after 12.002520 seconds from start

In my experience, these errors can be the result of the server being close to exhausting the memory, GUI can become extremely slow, like 1 minute to open the dashboard, try limiting the memory for VMs/docker services, or adding a little more RAM.

It could also be one or more containers hogging the CPU, try pinning only some cores to them, and leave cores 0/1 available for Unraid.

Also, recommend trying a couple of other things, go to Settings - Global share settings and set the Number of fuse File Descriptors to the max, and enable this:

https://docs.unraid.net/unraid-os/release-notes/7.0.0/#excessive-flash-drive-activity-slows-the-system-down

Thanks @JorgeB -- I saw this exact post from you on another thread. My CPUs are pinned and CPUs 0/1 are open for the server. As I noted, RAM utilization was only at 70% of 128GB.

How can I diagnoses the actual issue?

               total        used        free      shared  buff/cache   available

Mem:       131864536   111620016     3300104    19750552    38697964    20244520

Swap:              0           0           0

You may need trial and error; in my experience, it's typically Docker related, like a container exhausting the server's resources.

Try this script to see if it finds anything; copy it to the flash drive, then open a terminal window and run:

bash /boot/slowlog

Leave that window open; you can use Tmux so it's not closed automatically, and see if it shows something when the php errors start.

slowlog

ok, got it. Thanks. Ok to leave this running for 30+ days? May be a while before it happens again.

I tried to adjust the slowlog settings in www.conf while it was failing but the php-fpm wouldn't restart at that point.

Edited January 6Jan 6 by geeksheikh

I kind of don't think it's docker -- because while the failure was happening I was able to kill all the containers and stop the docker service -- still, php-fpm would not restart. Nonetheless, I'll do this and see what it shows us. Thanks again.

killall dockerd 2>/dev/null
killall containerd 2>/dev/null
killall containerd-shim 2>/dev/null
/etc/rc.d/rc.docker stop 2>/dev/null

@JorgeB the server hasn't crashed yet but it's started to show slowness in the UI and seeming like it's about to go -- do you see any illuminating facts in the slow_log file thus far?

Thanks.

slow_log.txt

It looks like the preclear plugin may be hanging when running a shell command. If you are not preclearing a disk, try uninstalling it.

That's exactly what I did -- but the only preclear plugin I could find was the unassigned devices preclear plugin -- I uninstalled it earlier today and the ui login is still incredibly slow -- seems like it's dying...now it looks like dynamix maybe?

slow_log_0205_1837.txt

Did you reboot after removing the plugin?

No but it wasn't the plugins -- here's the issue and the evidence

Basically, I had my docker.img at /mnt/user/docker_cache/docker.img (no idea why / how / when it got there). This somehow was mounted to a btrfs FUSE mount that was causing major io delays (again no idea). The share WAS configured for cache only (see image attached below). It seems that there was an issue with using a FUSE reference instead of an actual mount that caused major io waits to the docker img dragging the whole system down.

I'm not sure if I made a mistake sometime in the past or if the mover on one of the Unraid versions bugged out and moved it off cache or exactly what but for others out there that have this problem I suggest stopping your docker service, providing a path DIRECTLY to a real mount and not using a share path -- hopefully this can help someone else.

Now the UI is back to being super snappy and I didn't even have to restart.

root@pumbaa:/mnt/ssdpool/fastcache/logs# grep -R "DOCKER_IMAGE_FILE" -n /boot/config 2>/dev/null
/boot/config/docker.cfg:2:DOCKER_IMAGE_FILE="/mnt/user/docker_cache/docker.img"

ls -l /dev/mapper | head
lsblk -o NAME,MAJ:MIN,SIZE,TYPE,FSTYPE,MOUNTPOINTS | sed -n '1,200p'
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,PKNAME | egrep 'dm-20|loop2|nvme|sd'
dmsetup info -C /dev/dm-20
dmsetup table /dev/dm-20

commands allowed me to see 
sdag           66:0   476.9G disk              
└─sdag1        66:1   476.9G part  crypto_LUKS 
  └─sdag1     253:20  476.9G crypt btrfs       /mnt/ssdpool

root@pumbaa:/mnt/ssdpool/fastcache/logs# dmsetup info -C /dev/dm-20
dmsetup table /dev/dm-20
Name             Maj Min Stat Open Targ Event  UUID                                              
sdag1            253  20 L--w    1    1      0 CRYPT-LUKS2-<redacted>-sdag1
0 1000180400 crypt aes-xts-plain64 :64:logon:cryptsetup:<redacted> 0 66:1 32768 1 allow_discards

root@pumbaa:/mnt/ssdpool/fastcache/logs# docker info | egrep -i "Docker Root Dir|Storage Driver|Backing Filesystem"
 Storage Driver: btrfs
WARNING: No swap limit support
 Docker Root Dir: /var/lib/docker

root@pumbaa:/mnt/ssdpool/fastcache/logs# df -h "$(docker info --format '{{.DockerRootDir}}')" 
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop2      160G   78G   79G  50% /var/lib/docker

root@pumbaa:/mnt/ssdpool/fastcache/logs# dmesg -T | tail -n 300 | egrep -i "i/o error|timeout|reset|nvme|ata|blk_update_request|xfs|btrfs|zfs"
[Mon Feb  2 05:11:30 2026] BTRFS warning (device dm-20): failed to trim 1 device(s), last error -121
[Tue Feb  3 05:11:31 2026] BTRFS warning (device dm-20): failed to trim 1 device(s), last error -121
[Wed Feb  4 05:16:01 2026] BTRFS warning (device dm-20): failed to trim 1 device(s), last error -121
[Thu Feb  5 05:15:46 2026] BTRFS warning (device dm-20): failed to trim 1 device(s), last error -121

root@pumbaa:/mnt/ssdpool/fastcache/logs# time docker version >/dev/null
time docker stats --no-stream >/dev/null
real	1m44.444s
user	0m0.311s
sys	0m14.391s

The only diagnostics we have are 5 weeks ago.

If at some point you were missing cache or it was unmountable, and you had Docker enabled, docker.img would have been created on the array.

Right, but as I noted in the initial thread -- this issue only happens 30-60 days after reboot so @JorgeB gave me a script to keep alive to monitor the php errors. I did that and the error presented yesterday / today and I replied. After further research I found out that the FUSE mounted io wait times were extremely high -- I have switched to direct mount and now the issue seems to be resolved. I posted the above for others with the issue.

6 hours ago, geeksheikh said:

It seems that there was an issue with using a FUSE reference instead of an actual mount that caused major io waits to the docker img dragging the whole system down.

If the share is only on a single drive, and you have enabled Exclusive Access option under Settings->Global Share settings then the FUSE layer should be by-passed. This is the recommended way to do this rather than reference the physical path directly as it is less likely to cause issues if you later make changes to your setup.

9 hours ago, geeksheikh said:

After further research I found out that the FUSE mounted io wait times were extremely high -- I have switched to direct mount and now the issue seems to be resolved. I posted the above for others with the issue.

Yep, that can definitely be an issue sometimes. Using disk paths or exclusive shares when possible is always the better option.