Ces derniers temps, j'ai fais face à une série noire de bugs sur mes serveurs. Il y a une théorie qui dit que dans le monde du logiciel libre, vous êtes toujours responsable quand une erreur arrive. L'objectif de cet article est donc de me servir d'aide mémoire, de réfléchir sur les solutions possibles et peut-être d'aider certaines personnes qui rencontreraient ce problème.
Fuite mémoire dans le noyau Linux
---------------------------------
Le premier bug a touché mon serveur auto-hébergé suite à une coupure de courant.
Étant à 6 000km de ce dernier, ce n'est pas facile de diagnostiquer d'où vient le problème.
J'ai d'abord pensé à un problème sur le réseau.
Quand au final, je me suis aussi aperçu que mes graphes [munin](http://munin-monitoring.org/) en local étaient coupés.
Mais par contre rien ne semble suspicieux à première vue. Donc on constate que depuis la coupure électrique et donc le redémarrage, le serveur fonctionne pendant deux heures en moyenne et se coupe. Mais est toujours sous tension. Ca ressemble beaucoup à quelque chose comme un kernel panic.
L'étape suivante la plus logique est donc de se pencher sur les logs. Pour le coup, `journalctl` ne m'a pas été d'une grande aide. Il n'avait qu'un historique depuis le dernier démarrage. Par contre, j'ai quand même trouvé un fichier `/var/log/syslog`. Un point qui me fait dire que la gestion des logs peut-être très différente en fonction des distributions Linux et de la configuration de la stack systemd & co. Et donc on trouve entre autre des centaines de lignes comme celle là :
```
Apr 13 19:12:02 deuxfleurs kernel: [30185.865364] Out of memory: Kill process 20580 (munin-node) score 0 or sacrifice child
Comme quoi notre Linux n'aurait plus de RAM. Je pensais donc au début à un processus qui utiliserait toute la RAM. Ce qui n'est pas le cas après vérification de `htop`.
Qui plus est, on vient de le voir, Linux tue les processus qui consomment trop de RAM quand cette dernière vient à manquer.
Ayant installé [netdata](https://github.com/firehol/netdata) pour avoir un meilleur suivi, je constate l'augmentation régulière de la RAM au fur et à mesure du temps :
Les graphes Munin n'étaient pas assez précis pour que je puisse constater cette augmentation.
Ne reste plus que le noyau. Et tout ce qui gravite autour, noyau monolithique oblige. La première commande qui m'est conseillé est `slabtop` :
```
Active / Total Objects (% used) : 669706 / 851401 (78,7%)
Active / Total Slabs (% used) : 37806 / 37811 (100,0%)
Active / Total Caches (% used) : 67 / 103 (65,0%)
Active / Total Size (% used) : 131870,09K / 152821,89K (86,3%)
Minimum / Average / Maximum Object : 0,02K / 0,18K / 4096,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
Le résultat ne m'a pas semblé aberrant. Mais peut-être qu'avec des connaissances plus poussées, il aurait été possible de détecter le problème depuis slabtop.
En parallèle de ces recherches, j'avais entrepris une grosse mise à jour du système. Une fois terminée, je redémarre sur le nouveau noyau. C'est une migration du noyau
```none
Linux deuxfleurs.fr 4.3.0-1-686-pae #1 SMP Debian 4.3.5-1 (2016-02-06) i686 GNU/Linux
```
au
```none
Linux deuxfleurs.fr 4.4.0-1-686-pae #1 SMP Debian 4.4.6-1 (2016-03-17) i686 GNU/Linux
```
Le problème est alors résolu, je savais que ça venait du noyau car la mémoire vive augmentait de manière continue sans qu'aucune application identifiée en soit la cause. Maintenant, il s'agit de savoir où et pourquoi.
Après quelques recherches, j'ai trouvé la réponse sur la mailing list [lkml](https://lkml.org/lkml/2015/12/6/113). C'est bien une fuite mémoire sur un pilote qui tourne dans le noyau. Plus exactement le pilote realtek, qui est utilisé par les dongles wifi USB.
Après vérification sur ma machine, en effet il était bien là :
```none
Bus 004 Device 002: ID 0846:9041 NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188CUS]
```
Le patch tient en 2 lignes, il manquait juste un free pour libérer la mémoire allouée.
Cet épisode fut l'occasion pour moi de découvrir comment un serveur se comporte en l'absence de mémoire vive libre, comment est géré la mémoire vive dans le noyau. J'ai eu beaucoup de chance que le bug soit déjà corrigé.
Il semble qu'un outil nommé [kmemleak](https://www.kernel.org/doc/Documentation/kmemleak.txt) a été créé dans l'objectif de découvrir ce genre de bugs. La question que tout le monde se pose : est ce que ça aurait pu arriver sur Windows ? Je ne sais pas, mais Microsoft propose aussi des outils pour vérifier ses pilotes, nommés [Driver Verifier](https://msdn.microsoft.com/en-us/library/windows/hardware/ff545448(VS.85).aspx).
Docker
------
Après plus de 200 jours d'uptime sur un CoreOS, j'ai commencé à rencontrer quelques problèmes. Mais avant de vous en faire part, je profite de ce billet pour attirer votre attention sur l'importance des fichiers `.dockerignore`.
En effet, lorsque vous allez lancer un `docker build`, ce dernier va envoyer votre contexte au daemon Docker. Le contexte, de ce que j'en ai compris est l'ensemble des fichiers dans votre répertoire courant.
Il se trouve que dans mon répertoire courant se trouve aussi les données que je veux garder (persister). Et que ces derniers peuvent faire plusieurs gigaoctets. Ces données seront alors envoyé à chaque build au daemon docker, monopolisant des ressources pour rien, et surtout ça prend du temps. Le fichier `.dockerignore` permet donc de préciser quels dossiers et fichiers ne pas envoyer au daemon, comme un `.gitignore`.
Mais revenons à nos moutons. Au bout de ces 200 jours, lorsque je relançais un conteneur, ce dernier n'avait plus accès à internet.
En relançant ce conteneur un certains nombre de fois, il a fini par fonctionner. Ce qui est vraiment bizarre. De ce que j'ai pu lire sur internet, d'autres personnes ont rencontré ce problème plus ou moins [ici](https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1509867) et [là](https://github.com/docker/docker/issues/866#issuecomment-19218300).
La solution proposée est en général d'arrêter Docker, de supprimer le bridge, puis de le redémarrer. Ayant une version assez vieille, j'en ai profité pour mettre Docker à jour.
Au redémarrage, tout se passe bien, sauf qu'un container ne veut plus se lancer.
L'erreur est pour le moins cryptique :
```none
Error response from daemon: Could not find container for entity id 20d3aad...
```
Il me semble que cette erreur était provoquée par :
```
/usr/bin/docker rm php1
```
Encore une fois, c'est un [bug connu](https://github.com/docker/docker/issues/17691). De ce que j'ai compris, Docker possède une base de donnée sqlite, dans lequel il stocke les id des containers, et probablement des informations à leur sujet. Il semble qu'une entrée dans cette base de donnée pointe vers un dossier n'existant plus. Il est typique de la mise à jour de docker 1.8 vers docker 1.9. La solution proposée est la suppresion de la base de données et des containers existants.
Je me suis personnellement contenté de ne plus utiliser l'identifiant php1, que j'ai remplacé par php-01. En sachant que dans ma base de donnée, cet identifiant restera un fantôme à tout jamais... ou jusqu'à que je le supprime manuellement.
Les DNS de Google
-----------------
J'ai aussi un serveur VPN, partagé avec quelques amis, permettant de s'affranchir de certaines restrictions imposés par un pare feu un peu récalcitrant.
Ce dernier est configuré afin de fournir des serveurs DNS au client. Afin de me simplifier la vie, j'avais alors fourni ceux de google, les très célèbres 8.8.8.8 et 8.8.4.4.
Mon service VPN fonctionnait très bien, jusqu'au jour où plus de connexion internet. En remontant, je finis bien par découvrir que le problème vient de la résolution DNS. La commande ping fonctionne très bien mais impossible de résoudre un nom de domaine.
Mais le problème est dur à identifier, car parfois la résolution fonctionne. Ca peut être dû à plusieurs facteurs différents, mais sachez que Windows n'hésite pas à faire des requêtes sur les serveurs DNS de tous les réseaux de la machine, pouvant au passage révéler les sites que vous voulez consulter.
Depuis OpenVPN 2.3.9, il existe une option de configuration nommée *block-outside-dns* qui permet de résoudre ce problème sous Windows. Pour plus d'information, voici le [bug report](https://community.openvpn.net/openvpn/ticket/605).
En passant sur le serveur, le ping fonctionne très bien. Par contre, au moment de réaliser une requête avec dig, le serveur DNS de google ne répondait plus. Finalement, j'ai décidé de tenter un autre serveur DNS, celui de mon hébergeur. Cette fois-ci ça a marché.
Après avoir laissé un ticket chez mon hébergeur, voici leur réponse :
> Il arrive de temps en temps que Google bloque les requêtes venant de certaines IPs ou certaines plages d'IP pour diverses raisons, je ne pourrais donc que vous inviter à utiliser d'autres serveurs DNS que les leurs.
Vous voilà donc prévenu ! Les serveurs DNS de Google c'est bien pour utilisation domestique, c'est tout !
