While setting up metrics monitoring for the LXD server I operate, I set core.metrics_address to an IP assigned by a LXD-controlled network interface.
At the same time, I wanted to change server.crt and server.key to a CA-signed certificate and key, so I had to restart the service.
However the service refused to start throwing the error:
level=error msg="Failed to start the daemon" err="Bind network address: listen tcp 10.246.192.1:8444: bind: cannot assign requested address"
To resolve the issue I had to install the sqlite client, understand the database model and finally delete the line corresponding to core.metrics_address in the config table.
While the error probably has its technical reasons, a few questions here:
wouldn’t be convenient to clarify in the documentation to not use a LXD-controlled IP address for core.host_address and core.metrics_address?
wouldn’t be convenient to document the proper way to troubleshoot this kind of scenario, providing some guidance for a direct access to the db (not via lxd sql) and the database model and dictionary?
DQLITE doesn’t provide a file you can access with sqlite3 command that applies modifications (it does provide a file called db.bin which can be used to view the database with sqlite3).
Instead you can use the DB patch process to apply changes on start up:
Please could you open an issue wrt to the bind error as I believe there should be logic to understand this scenario, https://github.com/canonical/lxd/issues, as people do tend to do this from time to time.
Please could you open an issue wrt to the bind error as I believe there should be logic to understand this scenario, https://github.com/canonical/lxd/issues , as people do tend to do this from time to time.
DQLITE doesn’t provide a file you can access with sqlite3 command that applies modifications (it does provide a file called db.bin which can be used to view the database with sqlite3).
Instead you can use the DB patch process to apply changes on start up:
I saw that. But if you want to perform some sql with DB patch process you still need to understand which query should be run, design it and see the data it must be run on. This is why a direct access to the db would be beneficial (in my case, a not-clustered server, sqlite3 was working fine) as well as data dictionary. Of course this comes with a huge risk to break things, but users can be warned about it.