[LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Questions et astuces concernant l'installation et la configuration d'archlinux
Avatar de l’utilisateur
milouse
Hankyu
Messages : 23
Inscription : dim. 14 août 2011, 17:56
Localisation : Nantes
Contact :

[LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par milouse » dim. 04 janv. 2015, 13:42

Bonjour,

Je viens jetter mon désaroi ici car j'ai un peu du mal à situer l'origine de mon mal et éventuellement comment le corriger. Je vous explique. Je suis en train de me monter un serveur auto-hébergé un peu particulier. En effet, c'est la même machine qui me sert (le soir en particulier) de PC de bureau (mail/rss/dev perso/musique/vidéo, j'en passe et des meilleurs).

Au début j'ai fait ça salement et ça allait. Mais progressivement je me suis dit que j'allais essayé de faire bien les choses (surtout depuis que j'ai pris la décision de m'installer un pod diaspora (ruby), migrer @home mon agrégateur de flux (leeed, php) et faire cohabiter ça avec mon blog (script perso, python). Après en avoir discuté avec un ami, j'ai tenté de me configurer différents containers LXC :
  • un container "blog"
  • un container "php"
  • un container "fossils" (pour ma forge perso)
  • un container "torrents" (le pire, c'est que c'est que du légal... j'ai pris l'habitude de seeder depuis longtemps des distro et surtout les fichiers de Scenery et Aircraft liés à FlightGear)
  • reste sur le "host" mon environnement graphique (awesome), hiawatha qui me sert d'aiguillage vers les bons container et mpd
Il en résulte que ça tourne à peu près bien, sauf.... ben quand ça pète.

Le souci c'est que je ne suis pas sûr à 100% de pourquoi ça pète. Le symptôme est simple : je suis sur mon environnement graphique en train de faire tout et n'importe quoi et à un moment donné je vais lancer une nouvelle appli (firefox, hubic, gimp...) et là X se kill et retour à l'écran de login. Cependant, tout ce qui tourne dans des tmux n'est pas killé (enfin, normal au fond) et les containers tournent toujours (normal aussi je pense)

Après une petite analyse je soupçonne que le problème vienne de mon container transmission. En effet, lorsque je le coupe le problème n'apparaît plus (mais comme il était très aléatoire, c'est compliqué d'être sûr). J'ai également remarqué que bien souvent, lié à ce crash, apparaissait des lignes du type « Too many files open »

J'ai également remarqué, au moment du dernier crash, les lignes suivantes dans le /var/log/daemon.log (j'ai ajouté le paquet permettant de continuer à avoir les anciens logs, j'ai du mal avec journalctl) :

Code : Tout sélectionner

Jan  3 20:37:03 rapyuta systemd[1]: Failed to set memory.limit_in_bytes on : Invalid argument
Jan  3 20:37:03 rapyuta systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument
Jan  3 20:37:03 rapyuta systemd[1]: Failed to reset devices.list on /user.slice: Invalid argument
Quand je cherche sur le net la cause potentielle de ces soucis, je trouve rien d'exceptionnellement probant (comme si j'étais le seul à les avoir). J'ai tout de même trouvé des messages de 2012 à propos de transmission et de « Too many files open », mais comme ça demande de modifier des fichiers systèmes (qui j'imagine sont les mêmes pour tout le monde, du coup pourquoi chez moi ça pète et pas les autres ?) je souhaitais avoir une confirmation avant de me lancer.

Il est question souvent de modifier le fichier /etc/security/limits.conf pour augmenter le nombre de fichier ouvert par le système. Est-ce une opération courrante à faire quand on a des container ? Et si oui je modifie bien sûr le fichier du host, pas des containers ?

Pour info, voici le résultat de quelques commandes lié à ça à l'heure actuelle (donc pas de crash à l'horizon...) sur le host (rapyuta) :

Code : Tout sélectionner

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 29258
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 29258
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ sudo sysctl fs.file-nr
fs.file-nr = 2720	0	372149

$ sudo sysctl fs.file-max
fs.file-max = 372149
Voilà, je suis ouvert vraiment à tous les avis concernant ce souci, car je trouve dommage de m'arrêter en si bon chemin à 2 containers... Ça fait pas très cloud. Pour l'instant mon meilleur « workaround » est d'avoir éteint mon container transmission mais bon, j'aimerai comprendre.

Bref, merci beaucoup d'avance et très bonne année à tous !

PS: au passage, je vois également dans les logs revenir très fréquement la ligne « kvm: disabled by bios »... KVM est important pour faire fonctionner LXC ? La doc est pas très clair à ce sujet.

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par Xorg » dim. 04 janv. 2015, 16:10

Salut.

Beaucoup de choses dont tu parles me sont totalement inconnues, mais je connais le «Too many files open». Un petit exemple simple en C :

Code : Tout sélectionner

#include <stdio.h>
#include <stdlib.h>

#define MAX 1024

int main()
{
	int i, fichiers[MAX + 1];
	char tmpfile[30];

	for(i = 1; i <= MAX; i++)
	{
		sprintf(tmpfile, "/tmp/file%i.XXXXXX", i);
		printf("Fichier temporaire %4i... ", i);
		fichiers[i] = mkstemp(tmpfile);
		
		if(fichiers[i] < 0)
			printf("Échec.\n");
		else
			printf("Ok.\n");	
	}

	return 0;
}
Bref, rien de bien utile, c'est juste pour "voir" la limite du nombre de fichiers ouverts autorisés. Avec mon exemple, les 3 derniers fichiers échouaient chez moi, mais après un ulimit -n 2048, plus de soucis.
Donc oui, change la limite. :)

Visiblement la commande ulimit -n permet de le faire et sans nécessiter les droits root, alors tu n'y perds rien à essayer. :wink:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Avatar de l’utilisateur
milouse
Hankyu
Messages : 23
Inscription : dim. 14 août 2011, 17:56
Localisation : Nantes
Contact :

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par milouse » dim. 04 janv. 2015, 16:56

Merci pour ta réponse super rapide :)
Je vais attendre un peu si d'autres personnes ont d'autres avis (je sais pas pourquoi, ça me semble trop « simple ». Et pour le coup, à cause des containers il faut que je modifie le nombre de fichier en root... du coup je voulais être sûr de ne pas abîmer mon matériel.

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par Xorg » lun. 05 janv. 2015, 13:24

En fait ces limites sont juste là pour éviter les abus (où bien déceler quand un programme ouvre des fichiers sans jamais les fermer s'il est mal conçu :P ).
Tu peux trouver des explications sur Internet, comme ici, ou encore .
Tu sais, des fois ce n'est pas obligé que la solution soit toujours compliquée... :mrgreen:

Mais libre à toi d'attendre d'autres réponses, je respecte ta décision, car comme je l'ai dit, je ne connais pas LXC. :wink:
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

coolgeek
archer
Messages : 100
Inscription : jeu. 24 juin 2010, 09:44

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par coolgeek » lun. 05 janv. 2015, 16:56

les limites fourni de base correspondent a un usage standard (type PC de bureau) et cela evite notemment des fork bomb. La solution de passer par le fichier limits.conf est, je pense, la bonne quand on commence a avoir un usage particulier de son installation (ce qui semble etre ton cas).
Dans ce ficher, il est possible de mettre des limites pour le systeme et / ou par utilisateur. Le fait de le faire via "ulimit -n" doit le faire que pour la session courante, sinon il faut les droit root pour les rendre perenne (logique). A toi de voir selon tes besoin si tu veux augmenter cette limite pour atteindre un niveau resonnable ou tout simplement de le mettre en illimité, sachant que ca peux eventuellement etre un vecteur d'attaque.

Avatar de l’utilisateur
milouse
Hankyu
Messages : 23
Inscription : dim. 14 août 2011, 17:56
Localisation : Nantes
Contact :

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par milouse » lun. 05 janv. 2015, 17:21

Ok merci beaucoup à tous les deux :). Je vais donc tester dans les jours qui viennent en augmentant progressivement la limite. J'espère que je n'aurai pas besoin de la mettre trop haut.

Avatar de l’utilisateur
Xorg
Maître du Kyudo
Messages : 1930
Inscription : dim. 22 janv. 2012, 19:25
Localisation : Entre le clavier et la chaise.
Contact :

Re: [LXC] Too many files open --> Pas très sûr de ce qu'il faut faire

Message par Xorg » lun. 05 janv. 2015, 17:35

Je pense que tu peux la doubler (de 1024 à 2048) pour être tranquille.
Puis une fork-bomb, ça sature la table des processus (du coup ça ne joue pas sur cette limite-là). Pour prévenir des fork-bombs, c'est la variable nproc qu'il faut modifier (source).
Arch Linux x86_64 - Gnome 3 (Wayland)
- Desktop : Intel® Core™ i5 2500K - 8Go de DDR3 - SSD 250Go + 2 HDD 500Go
- Laptop : Intel® Pentiuml® 4405U - 4Go de DDR4 - SSD 120Go
Image AUR___Image Wiki___Image GitHub
Tux est un manchot, et non un pingouin. :marche:

Répondre