Error popups for Ubus appear then disappear on their own

This looks like an OpenWRT error, but I have gotten several, sometimes up to ~3, appearing as popups in the upper right area of the NethSec window that disappear on their own. I haven’t tried to copy the command with the button provided, but the last one disappeared before I could have.

This has happened across multiple releases.

I don’t see any operational issues.

What would you like me to do?

I think I’ve seen the same sporadic errors in my firewall.
You should click on the bell in the top right corner, copy the command and run it in a shell.
When I tried in my firewall, the command didn’t return errors, but maybe yours will.

If the command returned no error… why message appeared on webgui?

In my case, while I could have followed the instructions in the popups to do that, I ignored them, but recently they pretty much disappear on their own before I could.

There is a clue into what is going on in my system. Except for (from memory) one instance, they all happened immediately after an image upgrade, and usually after the upgrade, there are two or three. I just installed the latest image, and got two identical ones. In previous cases, they referenced different NethSec modules. 5 minutes ago, I did a screen snip (I am on Windows 11), and the two popups said

Ubus request failed
ns.dashboard.service-status

I will try more diligently to do so, but my hypothesis is they are a symptom of various services being booted where there are, between OpenWRT and the NethSec services, dependencies that aren’t sequenced by the software and are still booting up after the user logs in. i see this a lot in microservices implementations. My favorite example is Skype, where simultaneous rings on two PCs and an Android phone can result in one device ringing forever after I answer to call on another.

Unlike the Skype example, in the NethSec case, things seem to resolve themselves.

I would suggest one change. If the reason the popups disappear on their own is that the system retried it and it worked, that’s a good thing, but document it in the popup (I think your goal should be, never require the user to actually look at documentation, at least except for enabling some new service). If it is the case were it retries the operation and eventually works, display the number of retries. Windows does something I like, which is when it has high latency on a disk access a number of times, it logs an Event Viewer entry telling the user something about how many times it occurred, and whether there were any actual read/write errors.

If it is the case where it could cause some data corruption, while you don’t want to force a user to clear a popup frequently, since firewalls are supposed to just run by themselves, maybe there is a case where you should leave it up.

Under my hypothesis about asynchronous non-sequenced processes, the faster the computer, the less likely it is to occur. In my case, I have a fanless industrial-style computer (no air vents) with an i74600 CPU and 8GB.

1 Like