2016-02-04 3 views
1

Le serveur hôte est Centos 7.0.1406. Je crée lxc Centos 7.2.1511 conteneurs utilisant la commande suivante:Comment réparer les conteneurs Centos lxc lorsque des commandes aléatoires sont suspendues?

lxc-create -n test-container -t /etc/lxc/templates/lxc-centos --lxcpath=/var/lib/lxc/ 

Le conteneur lxc est créé et je peux commencer et attacher comme ceci:

lxc-create -n test-container -t /etc/lxc/templates/lxc-centos --lxcpath=/var/lib/lxc/ 

lxc-start -d -n test-container 

lxc-attach -n test-container 

Une fois que je suis à l'intérieur test-container , je tente d'exécuter des commandes aléatoires, telles que adduser foo ou yum install emacs et ils vont toujours accrocher comme ceci:

$ adduser foobar

...

ou comme ceci:

Est-ce ok [y/N]: y chèque de transaction course transaction en cours Test Test de transaction réussi transaction en cours Installation : freetype-2.4 .11-11.el7.x86_64
1/132 Installation: libICE-1.0.9-2.el7.x86_64
2/132 Installation: 2: libpng-1.5.13-7.el7_2.x86_64
3/132 Installation: libSM-1. 2.2-2.el7.x86_64
4/132 Installation: libjpeg-turbo-1.2.90-5.el7.x86_64
5/132 Installation: ATK-2.14.0-1.el7.x86_64
6/132 Installation: jasper-libs-1.900.1-29.el7.x86_64
7/132 Installation: 1: emacs-filesystem-24.3-18.el7.noarch
8/132 Installation: libthai-0.1.14-9. el7.x86_64
9/132 Installation: mesa-libglapi-10.6.5-3.20150824.el7.x86_64
10/132

...

Au début, je pensais que c'était un problème de paquet, mais même des commandes comme adduser sont suspendues. J'ai essayé de redémarrer le conteneur, en créant les conteneurs en utilisant le module salt lxc, en mettant à jour le noyau sur l'hôte, en évitant de mettre à jour les paquets, en clonant le conteneur, et bien d'autres ...

Je suis sur le point de changer d'idée aux conteneurs Debian, mais j'aimerais savoir si quelqu'un a déjà rencontré un problème similaire et sait comment le réparer.

+1

Je travaille avec diego sur ceci: La suspension commence sur des événements apparemment aléatoires. parfois juste après le démarrage du conteneur, parfois un peu plus tard. Après le redémarrage de l'hôte, certains anciens conteneurs fonctionnaient toujours correctement, seuls ceux récemment créés ou mis à jour semblaient être affectés par le problème. Dans un conteneur, nous avons pu provoquer le problème en mettant à niveau le package chkconfig.Cependant, ce n'était pas la cause du problème car après le redémarrage, même un conteneur qui avait l'ancienne version de chkconfig a maintenant le problème. ça fonctionnait bien avant le redémarrage. – eMBee

+1

il semble que si nous commençons un conteneur avec des outils libvirt au lieu d'outils lxc, le problème n'apparaît pas. malheureusement, les outils lxc sont beaucoup plus faciles à utiliser: 'lxc-create -n nom-conteneur -t centos; lxc-start -n container-name' vs créer manuellement une arborescence de fichiers conteneur puis l'activer avec: 'virt-install --connect lxc: /// --name conteneur -name --ram 512 --vcpu 1 - système de fichiers/var/lib/lxc/nom du conteneur/rootfs /,/'et plus tard' virsh --connect lxc: /// start container-name' (et la version libvirt ne définit même pas le nom d'hôte du conteneur) – eMBee

Répondre

2

cela semble être un bug avec la version des outils lxc actuellement en centos: lxc-1.0.8-1.el7.x86_64.

L'utilisation de différents outils, tels que libvirt, ou la mise à niveau de lxc vers la toute dernière version 1.1.5 résout le problème.

+0

lien vers l'insecte? –

+0

ce problème n'est pas discuté ailleurs à ma connaissance, et diego a dû arrêter de travailler sur le projet avant qu'il ait eu le temps de rédiger un rapport de bogue. – eMBee

+0

Merci beaucoup! La version 1.0.10-2.el7 a un bug. – azalio