search

wazzamatazz / NRuuviTag

.NET tools for working with the RuuviTag IoT sensor
MIT License
7 stars 1 forks source link

Facing a DBus.DBusException Error.LimitsExceeded max_match_rules_per_connection is exceeded when listening Ruuvitags with RaspberryPi 4 #4

Open mihquoiga opened 4 days ago

mihquoiga commented 4 days ago

I'm running my own program with raspberry pi that is listening to a bunch of Ruuvitags using this library. The software itself is running with no issues for about 3,5 days or so and after that I'm getting a LimitsExceeded with DBus error. This happens only with the raspberry pi and I haven't tried with any other Linux machines.. Windows listener seems to be runnign just fine.

I haven't been able to work around it and all help would be appreciated..

I'm not sure if it would be possible to reset BluezListener so that this limit is not exceeded or would someone have an idea how to avoid this from happening?

DbusIssue

wazzamatazz commented 3 days ago

I have to be honest, I'm quite far outside my comfort zone when it comes to the DotNet-BlueZ and Tmds.DBus side of things. I did find a Reddit post that describes the same error that you are seeing, along with instructions on how to modify the configuration file mentioned in your error message, although this might just delay when you see the error that you're seeing instead of preventing.

The Linux listener uses a custom build of DotNet-BlueZ that I forked from the original solely so that I could update the version of Tmds.DBus that was being used in order to fix a problem that I was seeing locally on my Raspberry Pi 3. Tmds.DBus is still active so it's possible that a more recent version fixes the problem, but I can't guarantee it. I'll also double-check if there is anything in the BlueZListener class that I should be disposing that I'm not.

If it runs fine for 3,5 days then (if this is practical) you could always schedule a restart of the machine every day or two until I've had a chance to publish an update.

mihquoiga commented 2 days ago

Hey! Thank you for your reply.

As you said that would delay the problem and restarting feels slightly cutting corners as well even though it's possible of course.

That would be awesome if it's possible for you to check this and I'd definitely be willing to test right away if you can publish an update. I think that the listener is somehow now piling up on those connections/rules so finding something to dispose there could definitely solve the issue.

Thank you!

wazzamatazz commented 2 days ago

Scheduling restarts would be a (hopefully!) temporary solution until a better solution was available.

It might be a bit of trial and error to fix it. It looks like the DotNet-BlueZ event handler that the Linux listener hooks into to be notified about new devices contains a Device property that is disposable - it might be the case that this property should be disposed by the event handler if the listener isn't going to monitor the device.

wazzamatazz commented 2 days ago

Hi, I've just published NuGet package versions for v0.13.0 containing changes described in #5. Try the update out when you get a chance and hopefully it fixes your issue!

wazzamatazz commented 2 days ago

Btw I just realised that I actually run into the same issue in my setup as well, but I hadn't noticed because I'm running the nruuvitag command inside a container using Docker Compose and my compose configuration is set to always restart the container whenever it exits so when the D-Bus limit gets hit and causes the process to crash, Docker is just restarting it immediately.

If you are running nruuvtag using systemd you can configure it to automatically restart on failure as described here.