* Improve D-Bus error handling for NetworkManager
There are quite some errors captured which are related by seemingly a
suddenly missing NetworkManager. Errors appear as:
23-11-21 17:42:50 ERROR (MainThread) [supervisor.dbus.network] Error while processing /org/freedesktop/NetworkManager/Devices/10: Remote peer disconnected
...
23-11-21 17:42:50 ERROR (MainThread) [supervisor.dbus.network] Error while processing /org/freedesktop/NetworkManager/Devices/35: The name is not activatable
Both errors seem to already happen at introspection time, however
the current code doesn't converts these errors to Supervisor issues.
This PR uses the already existing `DBus.from_dbus_error()`.
Furthermore this adds a new Exception `DBusNoReplyError` for the
`ErrorType.NO_REPLY` (or `org.freedesktop.DBus.Error.NoReply` in
D-Bus terms, which is the type of the first of the two issues above).
And finally it separates the `ErrorType.SERVICE_UNKNOWN` (or
`org.freedesktop.DBus.Error.ServiceUnknown` in D-Bus terms, which is
the second of the above issue) from `DBusInterfaceError` into a new
`DBusServiceUnkownError`.
This allows to handle errors more specifically.
To avoid too much churn, all instances where `DBusInterfaceError`
got handled, we are now also handling `DBusServiceUnkownError`.
The `DBusNoReplyError` and `DBusServiceUnkownError` appear when
the NetworkManager service stops or crashes. Instead of retrying
every interface we know, just give up if one of these issues appear.
This should significantly lower error messages users are seeing
and Sentry events.
* Remove unnecessary statement
* Fix pytests
* Make sure error strings are compared correctly
* Fix typo/remove unnecessary pylint exception
* Fix DBusError typing
* Add pytest for from_dbus_error
* Revert "Make sure error strings are compared correctly"
This reverts commit 10dc2e4c3887532921414b4291fe3987186db408.
* Add test cases
---------
Co-authored-by: Mike Degatano <michael.degatano@gmail.com>
* Use find to delete files recursively
Instead of using rm -rf use find to delete files recursively. This
has the added benefit that we do not need to rely on shell expansion.
In particular, shell expansion caused the --one-file-system flag to
not work as intended: The idea was that the content of a (left-over)
bind mounted directory would not get deleted. However, since shell
expansion passed the directory to rm, rm happily deleted also files in
that bind mounted directory.
* Pass arguments correctly
* Fix argument order and stderr output
* Improve error handling
Log with exception level if there is an OS level error. Decode the
stderr output correctly.
* Remove unnecessary newline
* Revert Home Assistant configuration to `/config`
With the new add-on config feature the intention is to provide a good
location for add-on specific configurations. Currently, add-ons such
as Node RED or ESPHome use the Home Assistant config directory because
this location is accessible to the user (via Samba VSCode add-on etc.).
To make it clear to add-on developer that the new intention is to use
add-on specific config, the implementation now bind mounts the add-on
configuration directory to `/config`. And since some add-ons still need
access to the Home Assistant configuration, its config folder is mounted
to `/homeassistant` under the new scheme.
However, users do know the path `/config`, and edit things e.g. through
the SSH or VS Code add-on. Also `/config` is still the
directory from inside the Core container.
For SSH/VS Code add-on we could work around using a symlink, but that
only works as long as these add-ons don't have a add-on config
themselfs.
This all has very high confusion potential, for not much gain. The
renaming is mainly "developer friendly", but not really user friendly.
Let's minimize potential confusion, and keep things where they are.
The Home Assistant config directory stays at `/config, in all cases,
everwhere.
Map the new add-on configuration directory to `/addon_config`.
* Adjust tests/comments
* Cache common version checks
We check core version quite frequently in the code, and its a bit expensive to do
all the comparsions everywhere. Since its mostly the same check happening over and
over we can cache it
* Cache common version checks
We check core version quite frequently in the code, and its a bit expensive to do
all the comparsions everywhere. Since its mostly the same check happening over and
over we can cache it
* fix import
* Don't check if Core is running to trigger rollback
Currently we check for Core API access and that the state is running. If
this is not fulfilled within 5 minutes, we rollback to the previous
version.
It can take quite a while until Home Assistant Core is in state running.
In fact, after going through bootstrap, it can theoretically take
indefinitely (as in there is no timeout from Core side).
So to trigger rollback, rather than check the state to be running, just
check if the API is accessible in this case. This prevents spurious
rollbacks.
* Check Core status with and timeout after a longer time
Instead of checking the Core API just for response, do check the
state. Use a timeout which is long enough to cover all stages and
other timeouts during Core startup.
* Introduce get_api_state and better status messages
* Update supervisor/homeassistant/api.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Add successful start test
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
