Luci crash on 19.07.2 when visiting /admin/status/realtime/connections

Openwrt 19.07.2 x86-64 running on a apu4c2 in a qemu/kvm vm w/ 192MiB memory.

I try to visit the realtime connection graphs. At first, page loaded properly, but all counters remain at 0, and after a while I get a message that there's nothing to report (sorry, unable to catch exact message). It seemed to me that something did timeout. Upon page refresh, I get the following error:


/usr/lib/lua/luci/dispatcher.lua:315: /etc/config/luci seems to be corrupt, unable to find section 'main'
stack traceback:
	[C]: in function 'assert'
	/usr/lib/lua/luci/dispatcher.lua:315: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:208: in function </usr/lib/lua/luci/dispatcher.lua:207>

This seems similar to LUCI Error after upgrade to r10949 or r10951: /etc/config/luci seems to be corrupt

I tried

/etc/init.d/uhttpd restart
/etc/init.d/rpcd restart
luci-reload

to no avail. I don't see other errors than the one shown over http in logread output.

Any thoughts on how to proceed to further investigate this?

Can't help but I had the same error on a BT Hub with the current release - 19.07.02.

I tried removing and reinstalling Luci with and without the --force-maintainer option, but that didn't help.

I gave up and I've just used the reset button to erase all settings and get the UI back.

That hints at a problem with the rpcd-mod-rrdns module. Does it start working if you do the following:

mv /usr/lib/rpcd/rrdns.so /usr/lib/rpcd/rrdns.so.hide
/etc/init.d/rpcd restart
1 Like

Unfortunately, it does not appear to change anything.
Edit: wait, it did work. Is there anything I can do to further nail this down?

I appreciate you taking the time to post suggestions!

Could this somehow be memory related? I know the router handles a large number simultaneous connections because of a service I host.

Update: And I seem to be able to reproduce the crash, even after your suggested move. Whenever I browse to the connection stats page and then somewhere else, I get an error.

So the rpcd process is always crashing after browsing to the connections page?

Always is too strong. I have just managed to get the page to load, which produces a "A web page is slowing down your browser" Firefox warning, and only a partially filled table.

Which I admit confuses me, because

cat /proc/net/nf_conntrack | wc -l

tells me there's only 3.8k connections.

Are you able to trigger rpcd crashes or timeouts using ubus call luci getConntrackList ?

No, I have looped it for a minute, calling that command every second without a single crash.

And now I understand what rrdns.so does, I think it unlikely that it affects my crashes. Reverse DNS lookups were not enabled from the start.

I don't understand how I can suddenly no longer reliably reproduce this.

Hm, thanks for trying. I still suspect this call to be the culprit. Either that or the ubus call luci getRealtimeStats '{ "mode": "conntrack" }' one.

1 Like

I got the same behavior of crashes when checking connections. It gets triggered when using the ubus call.

Hi , Got exactly same problem.

When active connection is high (Above 2-3k) the following command

ubus call luci getRealtimeStats '{ "mode": "conntrack" }'

Works just fine and returns a reply.

And this

ubus call luci getConntrackList

Just hangs an causes Luci to return

/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main'

Only restarting rpcd gets it back using

service rpcd restart

My device has plenty of ram (RPI) so i think the code for returning the connection list doesnt really work with large numbers, I guess it should only return the top 100 connections or something like that.

Using my mobile app on my router (https://github.com/hagaygo/OpenWRTManager) with "Active Connections" overview causes LuCI to keep crashing while there is a lot of active connections.
It uses same API as real time page.

Just an update , same behavior on OpenWRT 21.02

2 Likes

And on OpenWrt v22.03.2

This issue seems to still exist. Thanks to @hagayg for opening a GitHub issue, where the discussion was continued: https://github.com/openwrt/luci/issues/4816