After a while with default config on the webinterface slow down to death. The CPU getting higher and higher until i shut down the browser window.
I tried it with ssl or without both the same. Tried material skin but the same with the bootstrap skin...
But its after a couple of time ... if i reboot the router all is fine ... 12 hours later not.
I tried to kill and start the uhttpd but that dont fix it.
I have the same issue but for me it's happening after like 5 minutes. I have a script that makes QSS LED blinking according to system load and the load becomes so big the the LED is "crashing", after a few minutes later the WiFi stops working, I can see the network but I cannot connect to it. SSH also stops working, it stops taking commands, just hanging so I cannot access log of see how much free RAM is still available. After a reboot everything is OK for a few minutes.
It's been happening for me since RC1 (I didn't really tested previous builds) and it's happening on stable too. For now I just came back to Chaos Calmer. No issues like that.
Yeah it would be better if i got back to CC too ... the issue with too less space and so on are annoying me.
I only got SQM, DDNS and VNSTAT working ... all other is default
yeah ok sqm could be the reason but if i stop sqm the issue is the same ... further the cpu load is low if i connect via ssh. Only if iI open luci via http or https the load get trough the roof ...
CPU: 3% usr 94% sys 0% nic 0% idle 0% io 0% irq 1% sirq
Load average: 3.39 2.66 1.76 4/45 27036
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
26924 15188 root R 3416 12% 26% [luci]
Hm, that is quite interesting indeed, but at the moment I have no idea at all why. Could you do me a favor, install strace using opkg and provide me the output of running strace -p $(pidof luci) ? Maybe this gives some clues about what the luci process is actually doing when spending this CPU time...
I will do ... but i got an idea .. i cleaned up /tmp/ via "rm -rf opkg-*" and now it works fine ... it seems to have to do with the cache from uhttpd i think ...
Yes, I do. Version 1.8 to be precise.
I thought it had something to do with only 32MB RAM but to be honest I didn't saw any indications that there was a problem with to low RAM available. I have SWAP enabled too.
The difference for me is, I don't have LuCI installed at all.
I have installed: kmod-usb-core kmod-usb2 kmod-usb-printer p910nd ntpdate dnscrypt-proxy-resolvers dnscrypt-proxy hostip iodine libsodium dnsmasq-full vnstat sqm-scripts ddns-scripts miniupnpd etherwake curl wget
If it is SQM's fault then it's a bummer since the only reason I updated to LEDE is because of cake. Now I'm back to Chaos Calmer and it's working great but unfortunately no cake there.
Hm im pretty sure its a memory problem but dont know whats happen. Has to do with the opkg update issue on 32 MB devices because if i delete the opkg-lists the issue is not happen ... after i update the lists the device became slow and get problems if i open luci
"opkg lists" are just files. But they are stored in the ramdisk and thus decrease the memory available for running the system. Lists seem to take some 460 kB at the moment.
Most likely the device has just enough free memory to run, and saving the opkg packages lists to ramdisk takes away the crucial amount, tipping the router toward crash due to memory exhaustion.
You might try backporting the cake package and editing the Makefile a bit. If I remember correctly, a restriction of only kernel 4.0+ support was added to cake some time ago. But originally cake has been developed using 3.18 based firmwares, I think. Note that you need to patch also "tc" in iproute2 package.
In principle it is rather straightforward. I wrote the original two patches that imported cake into LEDE. The support is creatd by just two files: