neheb
commented
5 years ago This could be an OOM problem. Try adding a swap device.
That version of OpenWrt IIRC had a kernel bug relating to IPv6. Might want to update.
Open spitfire opened 5 years ago
neheb
commented
5 years ago This could be an OOM problem. Try adding a swap device.
That version of OpenWrt IIRC had a kernel bug relating to IPv6. Might want to update.
spitfire
commented
5 years ago This could be an OOM problem. Try adding a swap device.
That version of OpenWrt IIRC had a kernel bug relating to IPv6. Might want to update.
This router has 128MB of RAM, and when I ran Avahi without reflector it was using ~30, so I doubt this is a memory issue. Do you mean upgrade to 18.06.1?
neheb
commented
5 years ago Yes.
AFAIK it should have the cache coherency issue fixed with that kernel. I remember adding the patch before 18.06 was released.
I used to run an mt7621 device with 512MB of RAM and would run out of it when transmission was active. Run free -a to see if you have any. Memory usage with this platform tends to be fairly weird.
spitfire
commented
5 years ago I'm not really running anything else besides basics on it, BTW shouldn't OOM just kill the process, not the OS :)?
total used free shared buffers cached
Mem: 123936 49492 74444 564 1972 11236
-/+ buffers/cache: 36284 87652
Swap: 0 0 0```I don't think so. There's no OOM killer in OpenWrt as far as I know. When transmission used up massive RAM, it slowed the system down to a crawl (I mean serial console was delayed massively).
Could also be some kernel bug. I know samba with sendfile for example panics the kernel and reboots the device. Without sendfile it works great. I proposed removing to the OpenWrt mailing list, only to be met by opposition.
spitfire
commented
5 years ago I don't think so. There's no OOM killer in OpenWrt as far as I know. When transmission used up massive RAM, it slowed the system down to a crawl (I mean serial console was delayed massively).
Could also be some kernel bug. I know samba with sendfile for example panics the kernel and reboots the device. Without sendfile it works great. I proposed removing to the OpenWrt mailing list, only to be met by opposition.
ok, thanks for the info - I'll try sysupgrade now and I'll know if it helped by tomorrow:)
spitfire
commented
5 years ago Nope, that did not help - it ran for about 25 minutes and rebooted again. I was looking at htop with one eye, and avahi-daemon was using crazy amount of CPU power (2% when it was rather idle, then jumping between 20, 50 and 100%). I used to run it on some veeery old (from today's point of view) hardware and it's usage was never even noticeable, so there is something very wrong going on.
karlp
commented
5 years ago I've seen the name incrementing issue when there were two devices on the network with the same IP. Perhaps that's exploding something in avahi?
spitfire
commented
5 years ago I've seen the name incrementing issue when there were two devices on the network with the same IP. Perhaps that's exploding something in avahi?
No 2 devices on my network have the same IP address.
neheb
commented
4 years ago Maybe an strace log would show something.
neheb
commented
4 years ago Is this an issue with the latest version?
Maintainer: @thess Environment: MediaTek MT7621 ver:1 eco:3 (mipsel_24k), YouHua WR1200JS, 18.06.0
Description: After installing avahi-daemon and enabling reflector in
/etc/avahi/avahi-daemon.conf(enable-reflector=yes,allow-interfaces=br-lan,wlan0-1) the router started rebooting spontaneously (at least once time a day, sometimes every few hours). Also all Macs on my network would get name suffixes incrementing at alarming rates (i.e. mymacname-472), but I've seen no symptoms of the service itself crashing (at least the PID for avahi-daemon is not changing).