Il y a quelques minutes, mon ordinateur est tombé en panne parce que mon disque dur était apparemment plein. Après avoir démarré en mode de récupération, j'ai découvert que mon fichier syslog dans/var/log était 64 Go volumineux. J'ai enregistré la fin du fichier sur une autre partition, puis je l'ai supprimé. Apparemment, le docker semble avoir été le problème parce que j'en ai trouvé beaucoup à la fin du fichier et qu'il y avait un processus de docker fonctionnant à 200% de CPU tout le temps. Après avoir effacé le journal et tué Docker, tout semble normal.
Nov 15 01:44:08 Elemental docker.dockerd[1120]:
time="2019-11-15T01:44:08.727060251Z" level=error
msg="failed to get event" error="rpc error: code =
Unavailable desc = all SubConns are in TransientFailure, latest connection
error: connection error: desc = \"transport: Error
while dialing dial unix /run/containerd/containerd.sock:
connect: permission denied\"" module=libcontainerd namespace=plugins.moby
Nov 15 01:44:08 Elemental docker.dockerd[1120]: time="2019-11-15T01:44:08.727116701Z"
...
Etc. J'espère que ce problème ne réapparaîtra pas mais j'aimerais quand même savoir ce qui aurait pu arriver ici.
J'ai fait installer le paquet docker via apt et snap en même temps. Le problème est donc résolu en supprimant Docker via le système d'emballage instantané.
# apt list --installed | grep docker
docker/bionic,now 1.5-1build1 AMD64 [installed]
docker-ce/bionic,now 5:19.03.5~3-0~ubuntu-bionic AMD64 [installed]
docker-ce-cli/bionic,now 5:19.03.5~3-0~ubuntu-bionic AMD64 [installed,automatic]
# snap list | grep docker
docker 18.09.9 418 stable canonical✓ -
# snap remove docker
docker removed
Quelqu'un chez Cannonical bousille les choses il y a quelques heures - c'est suivi sur le tableau de bord - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/185272
Mon système a été installé hier avec docker uniquement et comme le reste des gens ici - syslog a tué tout l'espace libre sur le disque, purger docker de snap a aidé.
Vous disposez de plusieurs services Docker en cours d'exécution. On dirait que dockerd essaie d'accéder aux différentes installations de containerd, spamming syslog.
Dans mon cas, l'installation de l'agent Teamcity et du docker était en conflit.
Sudo apt-get purge docker-ce
Sudo apt autoremove
Sudo rm -rf /var/lib/docker
Sudo truncate -s 0 /var/log/syslog
Exécutez ces commandes ci-dessus et redémarrez. tout s'est bien passé.
Cela m'est arrivé aussi. Je me demande si c'est une mise à jour instantanée qui a rendu cela possible:
ID Status Spawn Ready Summary
17 Done today at 00:34 UTC today at 00:34 UTC Auto-refresh snap "docker"
Désinstaller + réinstaller le package docker.io d'Ubuntu ramène ce problème, mais pour une raison quelconque, j'ai également installé un composant logiciel enfichable de docker, c'est donc ce qui a déclenché le conflit.
Name Version Rev Tracking Publisher Notes
core 16-2.42.1 8039 stable canonical✓ core
docker 18.09.9 418 stable canonical✓ -
Cependant, je ne me souviens pas avoir déjà installé le package de docker snap ... mais c'est un système de test après tout, quelqu'un d'autre aurait pu penser que c'était une bonne idée ...
J'ai aussi rencontré ce problème, donc juste au cas où d'autres personnes s'y promèneraient, je peux décrire la solution qui a fonctionné pour moi. J'ai d'abord essayé la suggestion de Chris Sung mais cela n'a pas fonctionné.
Les symptômes étaient:
dockerb fonctionnant à 200 +% CPU, et redémarrerait constamment avec une commande kill
Fichiers géants remplis dans syslog comme Philip Z. l'a vu. Quand je suis arrivé ce matin, il avait rempli tout mon disque dur avec un fichier de 700 Go.
Frist supprime l'énorme fichier afin que vous puissiez réellement faire des choses. Il recommencera à se remplir, mais vous devriez avoir un peu de temps.
Sudo truncate -s 0 /var/log/syslog
Supprimez ensuite l'installation de Snap Docker. Ce fut le problème pour moi, pas docker-ce
Sudo snap stop docker
Sudo snap remove docker
Je ne suis pas sûr que ce soit nécessaire, mais je suis allé de l'avant et je me suis également débarrassé de Snap
Sudo apt purge snap
Vous ne devriez plus voir le dockerb en haut. Vous pouvez ensuite réexécuter le troncateur de journaux pour supprimer les fichiers indésirables écrits pendant que vous exécutiez les commandes ci-dessus. Si vous bousillez comme je l'ai fait et supprimez complètement le syslog, assurez-vous de donner au nouveau syslog les autorisations appropriées.
Sudo cd /var/log
Sudo touch syslog
Sudo chown syslog:adm syslog
Sudo service rsyslog restart
Même problème ici aussi depuis cette nuit.
Les conteneurs Docker (mosquitto/influxdb/grafana) ne sont pas accessibles sur leurs ports respectifs.
Impossible d'arrêter les conteneurs avant d'utiliser --force
.
Arrêt forcé de tous les conteneurs mais le message de redémarrage de chacun est toujours le même:
"docker: Error response from daemon: all SubConns are in TransientFailure"
J'ai fait suppression du paquet Silvio . Ensuite, pour redémarrer le démon docker, j'ai exécuté ces commandes en tant que root:
systemctl unmask docker.service
systemctl unmask docker.socket
systemctl start docker.service
service docker start
Semble être bon maintenant. Merci à @Silvio.
J'ai reçu un avertissement d'espace bas sur Ubuntu.
L'espace ne me suffit pas pour analyser les erreurs répétées de journalisation/var/log
Mais les journaux les plus récents sont exactement les mêmes que vous.
J'ai essayé de vérifier quel processus écrivait le plus sur le disque, mais j'ai trouvé que le processeur de% du docker était supérieur à 250.
snap changes | grep docker
il semble docker snap installé par lui-même
54 Done yesterday at 23:31 EST yesterday at 23:31 EST Auto-refresh snap "docker
Sudo snap remove docker --purge
devrait retirer le bouton pression du docker et libérer immédiatement de l'espace