Hi.
I didn’t found on this forum information about “blocking menus”, problem which i have on probably all mikrotik my devices (~50 for this moment).
Little description our my situation - I have central server with ovpn configured for mikrotik devices. Configuration of this devices is synchronized by api, with custom python based application.
Devices are configured to send some part of logs by vpn connection to syslog server on central server. Other data send by this connection, are dns queries from clients connected to routerboards, sent by calea client, configured on /ip/firewall/calea. As there is some unrecognized problem with routerboard calea implementation and after around 24~48h transmission of calea transmission stops, I have configured cron job, which disables for several seconds part of /ip/firewall/calea entries, enables rest of them, then - after some time - calea configuration is restored to start point. This mostly resolves problem, but this does not work in all situations.
After some time of good looking situation, menu /ip/firewall/calea stops responding. When it’s accessed by api - i’m getting timeouts in queries of this menu. When it’s accessed by ssh connection/command line interface - print in this menu blocks (I didn’t test for how long time) - but with ctrl-c as rescue. In this moment, only rescue for unlocking this menu - is device reboot.
I had similar problems with other menus (empty or blocked /interface/ethernet, and/or /interface/bridge/port, and/or /interface/wireless - but all interfaces was working) - in which situations was also resolvable by reboot. For some time it seemed to me that this could be connected to little free memory on device, but as attachment shows - this was it’s probably result of failure. Statistics in attachment are for rb2011u device, they show free memory from /system/resource menu. 2014-01-26 8:18 is moment of block of /interface menu, also it is moment of start of log entries similar to: “internal error: login failed: failed to add queue: std failure: timeout (13)” - probably connected to this same problem. Today (2014.01.27) this menu accessed by ssh showed 32M of free memory.
Is there other way to resolve this, than rebooting devices at the time of detection of such problems?
Is this situation known to mikrotik developers?
btw. I have observed this on every mipsbe based devices (751u-2HnD, 951-2n, 951-2HnD, 2011u) I have. No matter which ros version it was deployed, this is same for at least 5.21 to 6.7.
