March 7, 20233 yr Fix common problems yelled at me to post my diagnostics here tower-diagnostics-20230307-1420.zip
March 8, 20233 yr Community Expert If it's a one time thing you can ignore, if it keeps happening try limiting more the RAM for VMs and/or docker containers, the problem is usually not just about not enough RAM but about fragmented RAM, alternatively a small swap file on disk might help, you can use the swapfile plugin: https://forums.unraid.net/topic/109342-plugin-swapfile-for-691/
March 9, 20233 yr Author It keeps happening, so it is not a one time thing unfortunately. Th error message is coming minutes after startup, I would not think ram would be getting unduly fragmented so soon after boot. Not sure what you mean by limiting more ram. I am not currently running any VMs, just dockers. The dashboard shows I am only using 10% of 32 gigs of ram. I am about to install the swapfile plugin and will see how that does.
March 9, 20233 yr Community Expert It's very strange if it's happening immediately after boot, and with so much free RAM, but see if swap helps.
March 9, 20233 yr Author Tried swap, it got filled up as well. Looking at the different diagnostics syslogs I have taken each time, avahi-daemon is what is triggering the out of memory error each time and is then killed. It appears to be for Apple Bonjour services, I use macs, but I do not know if this is needed, or what could be done to fix.
March 9, 20233 yr Community Expert Everything should work without that, try adding these to your go file, after the emhttp line: /etc/rc.d/rc.avahidaemon stop /etc/rc.d/rc.avahidnsconfd stop Then reboot.
March 9, 20233 yr Author Unfortunately it did not fix it, still happens every time I boot up. Just now it uses the swapfile before crapping out. I have included my latest diagnostions for shits and giggles tower-diagnostics-20230309-1603.zip
March 9, 20233 yr Author My go file looks like this #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & /etc/rc.d/rc.avahidaemon stop /etc/rc.d/rc.avahidnsconfd stop modprobe i915 chmod -R 777 /dev/dri
March 10, 20233 yr Community Expert So this time the oom-killer was invoke by php, suggesting avahi wasn't the problem, try booting in safe mode to see if you still have the runaway RAM issue.
March 14, 20233 yr Author Had to go out of town, so sorry for the delay. I booted into safe mode and it did not kick up the error. Of course the former parity drive i had just folded into the array decided to go tits up as soon as I left, so I get to deal with that as well tower-diagnostics-20230313-2128.zip
March 14, 20233 yr Community Expert 7 hours ago, Kansur said: Had to go out of town, so sorry for the delay. I booted into safe mode and it did not kick up the error. That suggests one of the installed plugin is the problem, remove one by one, or remove all and re-install one by one.
March 17, 20233 yr Author Sorry for the delay again, I had to wait for a parity rebuild and then a large file transfer befor i could start rebooting the server willy-nilly. Anyway, through the removal and adding of plugins and the culprit appears to be the unassigned devices plugin. You can see in the attached log files that right before avahi crashes out with an oom, unassigned devices throws some warnings while trying to do something with a local synology drive, not sure how or if that is related, I just know that I can boot fine and not get an out of memory error with every plugin installed, but as soon as I install the unassigned devices plugin it craps out. And it will do it with or without the 2 unassigned devices addons. Mar 17 15:17:10 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'ALFRED.local' 2>&1) took longer than 10s! ### [PREVIOUS LINE REPEATED 1 TIMES] ### Mar 17 15:17:26 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'ALFRED' 2>&1) took longer than 10s! Mar 17 15:17:36 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'ALFRED.local' 2>&1) took longer than 10s! Mar 17 15:18:25 Tower kernel: avahi-daemon invoked oom-killer: gfp_mask=0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0 tower-diagnostics-20230317-1518.zip
March 17, 20233 yr Author Removed unassigned devices and rebooted again, now nginx is throwing a conniption tower-diagnostics-20230317-1601.zip
March 17, 20233 yr Author Reinstalled unassigned devices to shut up nginx, did not reboot. Now it is spamming the log with: Mar 17 16:08:11 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token tower-diagnostics-20230317-1608.zip
March 18, 20233 yr I'm not seeing anything that I can attribute to UD. Although, this log entry is not necessarily a problem, I think I may have a resolution for the log entry: Mar 17 15:17:00 Tower unassigned.devices: Warning: shell_exec(/sbin/arp -a 'ALFRED' 2>&1) took longer than 10s!
March 22, 20233 yr Author Solution After updating to the 2023.03.19 unassigned devices release I am no longer getting the out of memory error after reboots
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.