Supervisor: Introspection of de.pengutronix.rauc fails on generic linux

[frenck]

Problem/Motivation

Introspection of de.pengutronix.rauc fails on generic linux, which is to be expected since RAUC is only available on HassOS.

Log:

18-07-06 16:52:50 INFO (MainThread) [hassio.utils.gdbus] Introspect de.pengutronix.rauc on /
18-07-06 16:52:50 ERROR (MainThread) [hassio.utils.gdbus] DBus return error: b'Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name de.pengutronix.rauc was not provided by any .service files\n'
18-07-06 16:52:50 WARNING (MainThread) [hassio.dbus.rauc] Can't connect to rauc

Expected behavoir

I did not expect the error to show up in the logs. I can imagine it might confuse less technical users.

Suggested solution

Only introspect for RAUC, in case the underlying system is HassOS.

[jjtoard]

issues disappeared after upgrade to 0.86.3
but after a few reboots it is back

[frenck]

@jjtoard This happens in Hass.io and has nothing to do with your HA version.
It is not a harmful message.

[jerrychong25]

This issue still appeared on Raspbian OS with HA 0.87.1 installation.

[pimoon]

I got the issue me too.
Armbian Strech last version
Hassio fresh install

[pvizeli]

Rauc is the OTA updater for HassOS. This message mean: hey there is no HassOS around

[Alxandr]

Any way of installing Rauc on generic linux?

[dodexahedron]

How about logging it at warning (instead of error) and/or skipping it if the platform is not detected as hassos, as in the suggested solution?
Log diarrhea is not a good thing.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[niemyjski]

I just ran into this issue as well, ran the Hassio install on ubuntu 18 LTS

[keith721]

Please revise/update to WARNING rather than ERROR status.

[iamandymcinnes]

I'm also getting it on ubuntu 18.04

[PieBru]

This alarming log is still present today on Arch Linux, hassio fresh install from github repo, hassio-supervisor v163.

[codefaux]

Still there, for sure. Turns out I spent time out of my life searching for a fix to a problem that's not a problem while trying to diagnose something unrelated, due to an avoidable formatting change on an "error" message that doesn't actually mean anything important. Back to trying to figure out what's broken.

[PieBru]

@daninfuchs
Maybe a simple, indirect, temporary solution will solve raised alarms in new users like me. Maybe it's enough to suppress the message or the update request if not running on HassOS...
Or maybe explicitly adding to the message text: "Please ignore this message if NOT running on HassOS, see issue #560".
Just my 2 cents to avoid wasting time with silly issues.
Piero

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[niemyjski]

Any ideas on this?

[JranZu]

I have to agree with others on here - this message should only be showing up if running HassOS -- or at a minimum include that in the exception. I knew where to look for the answer so only wasted a few minutes on this -- but others that are not as experienced with open source software could spend hours trying to solve this -- possibly just giving up on HA all together.

[codefaux]

Personally, I feel that any software that throws an ERROR message during its normal operation is broken. If it's an error, it's something broken, incorrect, wrong, not working as planned. If it's an error, it is a problem. If it's a warning, it's something to safely ignore. My proposition, in a wholly generalized "approach to basic diagnostic error correction" in debugging my own work;
1 - It doesn't matter? It must not be an error, sounds like a warning or info message to me. Downgrade it.
2 - Maybe run a check so the error message from whatever underlying system isn't presented. If it IS an error, you're using something wrong and/or haven't built infrastructure to prevent the error from occuring.
3 - If I down't own the code presenting the error, maybe I should add my own debug line nearby telling people THEN AND THERE that it's not __ACTUALLY__ an error, I'm just not capable of blocking it -- this way they don't have to find/file a (year old) Github issue to eliminate the message as a potential source of a failure they're trying to diagnose.

I hope this helps! Keep up the good work, this entire thing is amazing.

[pvizeli]

That is not on my task list, so I never will work on that. I hold it open that other developer can pick this and provide a real fix and not only modify logger or change the log message.

[codefaux]

Awesome @frenck, super happy to see that it was a quick toss-in after all! Not to demean your work or anything, of course. I can't 'Like' pull requests directly or I just would've done that, lol. Good job!

[pvizeli]

Fix with next supervisor