Dr Clèm's Blog

Tags: Captain's log FLOSS FOSS Free Software Linux container LXD Ubuntu Canonical Snap

How to fix a broken LXD server due to fail snap auto-refresh

Sunday Aug 16, 2020 15:37, last edition on Sunday Aug 16, 2020 15:42

For my Linux containers, I am using LXD. The recommended way to install LXD is Snap, which updates daily. Few days ago, the last release of LXD has been released and the update started automatically. For the next two following days, I experienced timeout on my virtual servers. I also noticed at lot of input/output (I/O) on the hard drives. I started to investigate. I identified, using Htop among other tools like Netdata, that the process snapd, from Snap, was using 100% of the hard drives and all the I/O were on the /var/ partition. Using the command snap watch --last auto-refresh, I saw that the update stated more than two days ago and was stuck at the step Copy snap "lxd" data. I aborted the ongoing procedure but I ended up with a completely broken LXD. Hopefully, on Linux Containers forum, I found someone with the same, or at least similar enough, issue.

You can try to automate snap in offline mode. Make sure your host is not connected to the internet. This is definitely recommended for hypervisors and therefore also the LXD hosts. (my opinion for LXD hosts)

Download snap somewhere else with:
snap download lxd

Copy the files to your LXD node and install the snap:
snap ack <package.assert>
snap install <package.snap>

Linux Containers

It saved my day! At least, what was left ot it. It is at least the second time that this issue happens to me and it appears to impact other user. Unfortunately, it is a sign that LXD is not ready for production environment which requires stability. It is also a reminder that I need to find a way to backup LXD.

Mastodon Follow me Mastodon Share
Comments
There is no comment yet.
Post a comment

* required field.

Your comment

*

About you

*

*

Dr Clément Février

Bonjour, Je suis Clément Février, docteur en physique théorique de l’université de Grenoble Alpes, ingénieur Recherche et Développement dans le domaine de l’imagerie médicale et de la chirurgie mini-invasive chez Surgivisio et soutien du mouvement La France Insoumise.


Dites les velotaffeur, vous avez entendu parler d'un casque qui a un feu avant, un feu arrière et des clignotants sur les cotés / avant arrière ? (Enfin un simple bandeau led de chaque coté se gère hein)
Genre un truc pour que les voitures voient qu'on tourne à droite ou gauche sans qu'on ai besoin de tendre le bras ?

Parce que bon, j'ai testé ce soir, passer sur les marquages au sol + les rails du tramway avec un bras levé sous la pluie, niveau stabilité on repassera ^^'

J'arrive pas à trouver :/ et les solutions existantes de clignotants sont seulement pour l'arrière

Si le coeur vous en dit vous pouvez partager ;)

#velotaff #boostappréciés :)

The only thing that really matter is, at the end of the day, to choose the correct method automatically without conditional statement at runtime. I really wonder is a workaround is possible.
I already tried to add "std::tuple< d1*, d2 > b_tuple" to class b, using some forward declaration, but, of course, std::get< i >(b_tuple) cannot compile since it will be known at runtime only.

But I allow complete refactoring code, even the b and d1 & d2. Templates, new classes and sub classes and even are fine (I already put 100-lines define to add iterator to enum and another one to allow enum inheritance, and my coworkers begin to hate me ^^)
For example, method "create" can become a class, or class b can be construct using a macro to make somehow the base class aware of derived ones
BASE(b, ...) std::tuple< __VA_ARGS__ > g_ ## b; class b

How to choose a function at run time using overloaded resolution in ?
I feel it's an old known issue without (obvious) answer, but many things changed since c++98
stackoverflow.com/questions/64

I add the new following constrain to my original question, it can be up to C++14, no more (although if a solution in c++17 or C++20 exist, I'm interested) because of compiler limitation (appears to be based on gcc 5.14 from what I understood).