Tag: linux | Page 3 | SkyMinds.Net

Python : résoudre l’erreur “ImportError: cannot import name main”

16 August 202427 février 2019 by Matt Biscay · Lecture: 2 minutes

Pip écrasé par une nouvelle version

Suite à une mauvaise manipulation, j’ai malencontreusement écrasé ma version de pip installée par APT en faisant un pip install pip.

Après cela, toute commande lancée par pip donne cette erreur:

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name mainCode language: JavaScript (javascript)

Pas glop! Si cela vous arrive un jour, voici comment retrouver la version pip initiale, installée par votre gestionnaire de paquet APT.

Retrouver la version pip initiale (apt)

On marque python2.7 comme binaire Python par défault en le sélectionnant dans cette liste (si besoin):

update-alternatives --config python

On désinstalle pip, dans APT et dans PIP :

python -m pip uninstall pip
sudo apt purge --autoremove python3-pip

On réinstalle pip avec APT:

apt install python3-pip

Et on vérifie la version de pip :

pip3 --version

qui nous donne:

pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)Code language: JavaScript (javascript)

Et voilà, nous venons de retrouver une version de pip utilisable sur notre système.

Note : ne pas tenter de mettre à jour pip manuellement, il vaut mieux laisser le gestionnaire de paquet gérer les mises à jour de ce paquet lorsque cela est nécessaire, au fil des mises à jour.

Serveur dédié : installation de MariaDB 10.3

23 December 201823 décembre 2018 by Matt Biscay · Lecture: 1 minute

Debian Stretch possède MariaDB 10.1 mais au vu des améliorations récentes de MariaDB, il est intéressant de passer à la version 10.3 pour des raisons de performance.

Ajout du nouveau dépôt

On installe les dépendances et on ajoute le dépôt de MariaDB 10.3 à notre fichier de configuration apt, ainsi que la clé du dépôt:

apt install software-properties-common dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.3/debian stretch main'Code language: JavaScript (javascript)

Mise à jour de MariaDB

Une fois que la clé du dépôt est ajoutée au trousseau, on installe la nouvelle mouture de MariaDB:

apt update
apt install mariadb-server

Notez que vous pouvez choisir la version de MariaDB à installer très facilement depuis le site officiel.

Et voilà, serveur de base de données mis à jour.

MariaDB : changer le répertoire des bases de données sous Debian photo

Serveur dédié : déplacer les bases de données MariaDB ou MySQL sur une autre partition

24 March 202220 décembre 2018 by Matt Biscay · Lecture: 4 minutes

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes.

Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;Code language: CSS (css)

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)Code language: JavaScript (javascript)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home.

Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = falseCode language: JavaScript (javascript)

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

Linux : désactiver les emails de notification d’une tâche cron

3 October 202118 novembre 2018 by Matt Biscay · Lecture: 3 minutes

La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit).

Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.

Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.

1. Méthode nucléaire : rendre la variable MAILTO nulle

Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:

MAILTO=""Code language: JavaScript (javascript)

Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron.

Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.

2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie

Si vous supprimez la sortie du script, crond n’aura rien à envoyer.

Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:

>/dev/null 2>&1Code language: JavaScript (javascript)

Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:

*/5 * * * * /example/script >/dev/null 2>&1Code language: JavaScript (javascript)

Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.

3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie

Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS.

L’argument -s envoie la sortie vers le log système et l’argument -m off désactive la notification email du résultat de la tâche.

Voici un exemple :

cat /etc/sysconfig/crond

Résultat:

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m offCode language: PHP (php)

Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:

service cron restart

Conclusion

Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.

Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:

*/5 * * * * /example/script > /dev/nullCode language: JavaScript (javascript)

Installer Redis pour accélérer WordPress sous Debian

3 October 202104 septembre 2018 by Matt Biscay · Lecture: 3 minutes

Aujourd’hui, nous installons le serveur Redis pour accélérer les temps de chargement de tous les sites présents sur le serveur.

Redis (de l’anglais REmote DIctionary Server qui peut être traduit par « serveur de dictionnaire distant » et jeu de mot avec Redistribute1) est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit en C ANSI.

Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

Redis permet de manipuler des types de données simples : chaînes de caractères, tableaux associatifs, listes, ensembles et ensembles ordonnés.

Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux sur ce plan.

Lorsqu’une page WordPress est chargée par exemple, des requêtes sur la base de données sont lancées et cela prend un certain temps pour récupérer ces informations.

Lorsque Redis est activé, il garde ces requêtes SQL en mémoire, ce qui permet de gagner en temps de chargement des pages.

Voici donc le tutoriel pour mettre en place Redis sur votre serveur. Cela prend environ 15 minutes.

Installation du serveur Redis

Nous installons le serveur Redis et le paquet PHP associé:

apt install redis-server php-redis

Nous vérifions que Redis est bien actif, il nous suffit de lancer redis-cli:

redis-cli

On tape ping dans l’invite:

127.0.0.1:6379> pingCode language: CSS (css)

Réponse:

PONG

Parfait, le serveur Redis est bien installé et actif.

Configuration de Redis

Editons le fichier de configuration de Redis :

nano /etc/redis/redis.conf

Changez les valeurs suivantes :

maxmemory 256mb # max memory 
maxmemory-policy allkeys-lru # replace old keys with fresher ones
requirepass VOTRE-MOT-DE-PASSECode language: PHP (php)

Enregistrez et relancez le serveur pour prendre en charge la nouvelle configuration:

service redis-server restart

PHP : configurer un pool PHP pour chaque site

3 October 202102 septembre 2018 by Matt Biscay · Lecture: 2 minutes

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sockCode language: JavaScript (javascript)

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;Code language: JavaScript (javascript)

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restartCode language: CSS (css)

Shell : créer une liste de mot de passe facilement photo

Shell : créer une liste de mots de passe facilement

10 April 202323 juillet 2018 by Matt Biscay · Lecture: 3 minutes

Créer une liste de mots de passe simples

Voici un moyen très simple de créer une liste de mots de passe en utilisant le terminal sous Linux ou MacOS par exemple :

for i in `seq 1 8`; do mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX; doneCode language: JavaScript (javascript)

Explications sur le fonctionnement de la commande:

seq 1 8 va nous créer 8 mots de passe différents,

mktemp -u XXXXXXXXXXXXXXXXXXXXXXXX va nous créer des mots de passe alphanumériques dont le nombre de caractères dépend du nombre de X. Ici, j’ai mis 24 X donc les mots de passe feront 24 caractères.

Créer une liste de mots de passe sécurisés

La méthode précédente n’est pas vraiment sécurisée car le degré d’entropie est trop faible. Pour augmenter le niveau de sécurité, j’utilise cette commande:

for i in $(seq 1 8); do LC_CTYPE=C tr -dc '[:graph:]' < /dev/urandom | tr -d "'" | tr -d '"' | head -c 64 && echo; doneCode language: JavaScript (javascript)

Voici une explication de la commande :

for i in $(seq 1 8); do : Cela commence une boucle for qui se répète 8 fois (de 1 à 8).
LC_CTYPE=C : Cela définit la variable d’environnement LC_CTYPE à la valeur C, ce qui assure que le générateur de mots de passe utilise le jeu de caractères ASCII.
tr -dc '[:graph:]' < /dev/urandom : Cela utilise la commande tr pour supprimer les caractères non imprimables et générer des caractères graphiques aléatoires à partir de /dev/urandom, qui est une source d’entropie aléatoire sur les systèmes Unix.
tr -d "'" | tr -d '"' : Cela utilise deux commandes tr supplémentaires pour supprimer les caractères de guillemets simples (') et les guillemets doubles (") des mots de passe générés. Cela garantit que les guillemets simples et doubles sont supprimés des mots de passe générés.
head -c 32 : Cela utilise la commande head pour limiter la longueur des mots de passe générés à 32 caractères.
&& echo; done : Cela termine la boucle for et ajoute un retour à la ligne (echo) pour afficher chaque mot de passe généré sur une ligne séparée.

Simple et efficace, j’utilise souvent cette commande lors de la création ou l’import d’utilisateurs en masse, lors de la création d’un fichier CSV par exemple.

Cela permet d’avoir des mots de passe un minimum sécurisés dès le départ de la création des comptes utilisateurs.

Linux : récupérer des vidéos depuis votre terminal avec MovGrab

19 January 202423 juin 2018 by Matt Biscay · Lecture: 2 minutes

Movgrab est un outil en ligne de commande écrit en C (sans dépendances) qui permet de récupérer facilement des vidéos sur des sites comme YouTube, DailyMotion, Vimeo, Blip.tv, Liveleak, Guardian…

Il permet de choisir les flux disponibles sur les pages vidéo, supporte les proxies, peut reprendre des téléchargements… c’est une application très utile.

Liste des sites supportés par movgrab

Movgrab fonctionne avec:

YouTube
Metacafe
Dailymotion
Vimeo
Break.com
eHow
5min.com
vbox7
blip.tv
Ted
MyVideo
ClipShack
MyTopClip
RedBalcony
Mobando
Yale University
Princeton University
Reuters
LiveLeak
Academic Earth
Photobucket
VideoEmo
VideosFacebook

Aljazeera
Mefeedia
IViewTube
Washington Post
CBS News
Euro News
MetaTube
MotionFeeds
Escapist
Guardian
RedOrbit
Sciive
Izlese
uctv.tv
royalsociety.tv
British Academy
Kitp
Dotsub
Astronomy.com
Teachertube.com
Discovery
Bloomberg.com

Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

3 October 202121 mai 2018 by Matt Biscay · Lecture: 2 minutes

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}Code language: PHP (php)

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restartCode language: CSS (css)

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu

24 March 202203 avril 2018 by Matt Biscay · Lecture: 3 minutes

A la maison, je galère un peu avec les taux de transfert des fichiers entre ma machine fixe (The Reaper) et le NAS Synology.

Lors des transferts via le navigateur, la vitesse arrive à peu près à 2MB/s, ce qui, excusez-moi du peu, sonne comme une douce plaisanterie.

Pour pallier ce problème, nous allons donc “mapper” un des répertoires du NAS directement dans un répertoire local de ma machine.

Comme cette dernière tourne sous Ubuntu, il suffira dans Nautilus de copier des fichiers ou dossiers dans ce répertoire pour que tout soit uploadé directement dans le NAS. Un gain de temps en perspective !

Activation de NFS sur le NAS

Sur le NAS, nous allons avoir besoin du protocole NFS (Network File System).

Rendez vous dans Control Panel > File Sharing > File Services > cochez la case pour activer le service NFS et appliquez les changements:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo

Ensuite, cliquez sur l’icône qui se trouve juste au dessus, Shared folders :

créez un nouveau dossier partagé. Je vais prendre NetBackup comme exemple pour ce tutoriel.
sélectionnez le dossier > cliquez sur Edit > sélectionnez l’onglet NFS permissions.
cliquez sur Create pour ajouter une nouvelle politique de droits NFS sur ce dossier.

Voici les droits à accorder:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 1

Configuration :

Hostname/IP : on indique l’IP de la machine locale. Sur mon réseau local, 192.168.0.10 est l’adresse de ma machine fixe.

Privileges: Read/Write pour lecture et écriture.

Squash : Map root to admin. Cela permet de monter automatiquement le répertoire au démarrage de la machine.

Je laisse coché toutes les autres options, les transferts asynchrones ne me dérangent pas.

Backup Manager : résoudre l’erreur “tar: file changed as we read it” lors de la création de la sauvegarde

3 October 202108 février 2018 by Matt Biscay · Lecture: 4 minutes

Cela fait quelques jours que Backup Manager, qui me sert à sauvegarder automatiquement les fichiers et bases de données du site sur le serveur de sauvegarde, renvoie une erreur lors de la création d’un de mes fichiers de sauvegarde, alors que tout se passait sans encombres jusqu’alors.

C’est gênant dans le sens où on ne sait pas vraiment ce qui a empêché la bonne création du fichier et on ne peut vraiment être certain de l’intégrité du fichier de sauvegarde, ce qui est critique.

Voici le message d’erreur reçu par email à la fin de la sauvegarde :

Unable to create "/home/archives/mail.skyminds.net-home.20180208.master.tar.gz", check /tmp/bm-tarball.log.TZ2VAU
1 error occurred during the tarball generation.Code language: JavaScript (javascript)

Et voici le contenu du fichier log en question :

tar: /wp-content/ file changed as we read itCode language: JavaScript (javascript)

Étapes du débogage

Le moins que l’on puisse dire, c’est que tar ne nous donne pas vraiment d’indications sur la cause du problème. Un fichier qui change lors de la lecture, d’accord mais lequel ? De plus, il indique un répertoire et non un fichier précis.

Dans le fichier de configuration de Backup Manager, il est possible de choisir plusieurs formats de fichier pour compresser les fichiers de sauvegarde. J’utilise .tar.gz puisque tous mes machines tournent sous Unix mais là, j’ai changé la configuration pour utiliser le format zip.

On relance le script de sauvegarde : zip est beaucoup plus loquace dans ses messages d’erreur !

Voici ce qu’il nous indique :

zip warning: Not all files were readable
  files/entries read:  55621 (1.3G bytes)  skipped:  96 (414K bytes)

Très bien. Il ne nous reste plus qu’à trouver quels sont ces fichiers qui n’ont pas les droits de lecture.

A la racine du site, on lance donc une recherche pour trouver tous les fichiers et dossiers qui n’auraient pas les droits basiques de lecture (read) :

find . ! -perm -o=r

Résultat :

./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B0089KSLUY
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---CustomerReviews_B004LS7G3G
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00B2OI0FU
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B00JGYYQ24
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B006H4R9LG
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B005BHE48Q
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B00H2O1YOI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00MVQLMPI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B017EOYW9Y

Il s’agit donc de fichiers de cache de produits Amazon, qui sont absolument inutiles pour les sauvegardes: nous allons donc exclure ce répertoire de cache de nos fichiers de backup.

Suppression des répertoires de cache avant compression des archives

Dans la configuration de Backup Manager, ajoutez le chemin des répertoires de cache de quasiment tous les plugins WordPress :

export BM_TARBALL_BLACKLIST="/home/public_html/wp-content/plugins/*/cache/* /home/public_html/wp-content/*cache*"Code language: JavaScript (javascript)

Sauvegardez le fichier et relancez votre script de backup.

Méthode plus radicale : éditer le script

Si la méthode précédente ne porte pas ses fruits, en voici une autre. Il suffit de modifier la valeur du chmod dans ces deux fichiers :

/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/File.php
/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/Static.phpCode language: PHP (php)

Cherchez le chmod 600 :

'cache_file_umask' => 0600,Code language: PHP (php)

et remplacez-le par un chmod 644:

'cache_file_umask' => 0644,Code language: PHP (php)

Tada, plus d’erreur et des fichiers de sauvegarde propres, sans fichiers de cache inutiles !

Je suis assez content d’avoir trouvé une solution à ce problème assez récurrent.

Le fait d’avoir momentanément modifié le type d’archive à créer a bien aidé à isoler la cause du problème.

Serveur dédié : résoudre l’erreur “tail: inotify cannot be used, reverting to polling: Too many open files”

3 October 202110 décembre 2017 by Matt Biscay · Lecture: 4 minutes

Ce matin, je me suis aperçu que le serveur était un peu moins réactif que d’habitude.

Ni une, ni deux, je lance le terminal et commence par vérifier les fichiers log. Un message attire alors mon attention :

tail: inotify cannot be used, reverting to polling: Too many open files Code language: HTTP (http)

C’est bien étrange puisque très peu de services sont censés lancer des tail. Nous allons donc lancer quelques commandes pour savoir qui est responsable de cet état.

Hotfix : à la recherche des anon_inode:inotify

1. Première méthode pour avoir un aperçu de tout ce qui tourne en ce moment sur le serveur :

ps -ef

La liste est très exhaustive (plusieurs pages chez moi) et ne permet pas vraiment de voir ce qui se passe, étant donné que rien n’est trié.

2. Changeons notre fusil d’épaule et trouvons la liste des processus qui font appel à inotify:

for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

Résultat:

      8 /proc/25634/fd/anon_inode:inotify
      1 /proc/715/fd/anon_inode:inotify
      1 /proc/6146/fd/anon_inode:inotify
      1 /proc/330/fd/anon_inode:inotify
      1 /proc/32148/fd/anon_inode:inotify
      1 /proc/31695/fd/anon_inode:inotify
      1 /proc/31262/fd/anon_inode:inotify
      1 /proc/3067/fd/anon_inode:inotify
      1 /proc/3066/fd/anon_inode:inotify
      1 /proc/3065/fd/anon_inode:inotify
      1 /proc/3064/fd/anon_inode:inotify
      1 /proc/3063/fd/anon_inode:inotify
      1 /proc/3062/fd/anon_inode:inotify
      1 /proc/21853/fd/anon_inode:inotify
      1 /proc/2063/fd/anon_inode:inotify
      1 /proc/1924/fd/anon_inode:inotify
      1 /proc/1563/fd/anon_inode:inotify
      1 /proc/1196/fd/anon_inode:inotify

3. Maintenant, nous allons chercher dans cette liste de processus les commandes qui font appel à anon_inode:inotify :

ps -p $(find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print 2> /dev/null | sed -e 's/^\/proc\/\([0-9]*\)\/.*/\1/')Code language: JavaScript (javascript)

Résultat:

  PID TTY      STAT   TIME COMMAND
  330 ?        Ss     0:00 /lib/systemd/systemd-udevd --daemon
  715 ?        S      0:00 tail -f /tmp/bm-tarball.log.7lZV2O
 1196 ?        S      0:00 tail -f /tmp/bm-tarball.log.B1I64h
 1563 ?        S      0:00 tail -f /tmp/bm-tarball.log.hhDVas
 1924 ?        S      0:00 tail -f /tmp/bm-tarball.log.Ztuk8T
 2063 ?        Ss     0:06 /usr/bin/dbus-daemon --system
 3062 tty1     Ss+    0:00 /sbin/getty 38400 tty1
 3063 tty2     Ss+    0:00 /sbin/getty 38400 tty2
 3064 tty3     Ss+    0:00 /sbin/getty 38400 tty3
 3065 tty4     Ss+    0:00 /sbin/getty 38400 tty4
 3066 tty5     Ss+    0:00 /sbin/getty 38400 tty5
 3067 tty6     Ss+    0:00 /sbin/getty 38400 tty6
 6146 ?        Ss     0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon
25634 ?        Sl     0:21 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -
31262 ?        S      0:00 tail -f /tmp/bm-tarball.log.82bIqR
31695 ?        S      0:00 tail -f /tmp/bm-tarball.log.6Hqw69
32148 ?        S      0:00 tail -f /tmp/bm-tarball.log.UMpkfiCode language: JavaScript (javascript)

Ah on y arrive, c’est déjà beaucoup plus clair. Le service qui pose problème est donc backup-manager (voir le tutoriel Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde), qui semble laisser ouvert tous ses fichiers de logs !

← Précédent Suivant →