Linux : résoudre l'erreur "failed to execute /lib/udev/socket:@/org/freedesktop/hal/udev_event" photo

Linux : corriger l’erreur « cannot open pixbuf loader module file »

par · Lecture: 7 minutes

Lors d’une mise à jour Linux, du lancement d’une application GTK, ou de l’ouverture d’une image, vous pouvez tomber sur cette erreur :

(gtk-update-icon-cache-3.0:12015): GdkPixbuf-WARNING **:
Cannot open pixbuf loader module file
'/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache':
No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.Langage du code : JavaScript (javascript)

Le message peut apparaître dans le terminal pendant un apt upgrade, lors du lancement d’un logiciel graphique, ou quand une application ne parvient plus à ouvrir certains formats d’images.

Dans la plupart des cas, le problème vient du cache des loaders GdkPixbuf. Ce cache indique à GTK quelles bibliothèques utiliser pour charger les formats d’images : PNG, JPEG, WebP, SVG, TIFF, AVIF selon les paquets installés, etc.

La bonne nouvelle : ce cache se régénère. Et, dans beaucoup de cas, une seule commande suffit.

À quoi sert GdkPixbuf ?

GdkPixbuf est une bibliothèque utilisée par les applications GTK pour charger et manipuler des images. Elle ne contient pas forcément tous les chargeurs d’images en dur : elle s’appuie sur des modules, appelés loaders, pour gérer différents formats.

La commande gdk-pixbuf-query-loaders collecte les informations sur ces modules et écrit le résultat dans le fichier de cache par défaut, ou sur la sortie standard selon son mode d’appel. La page de manuel Debian décrit précisément ce rôle : collecter les informations sur les modules chargeables de GdkPixbuf et les écrire dans l’emplacement de cache prévu. :contentReference[oaicite:0]{index=0}

Si ce fichier loaders.cache manque, est vide, pointe vers de mauvais chemins, ou correspond à une autre architecture, les applications GTK peuvent ne plus savoir charger certains formats d’images.

Lire Linux : corriger l’erreur « cannot open pixbuf loader module file »

Encoder une vidéo H.264 : utiliser qt-faststart pour la lecture progressive photo

FFmpeg : optimiser une vidéo MP4 pour la lecture progressive

par · Lecture: 9 minutes

Lorsque l’on intègre une vidéo MP4 dans une page web, on s’attend à ce qu’elle démarre rapidement. Pourtant, il arrive qu’un lecteur HTML5 attende le téléchargement complet du fichier avant de lancer la lecture.

Le problème ne vient pas forcément du navigateur, ni du lecteur, ni même du serveur. Très souvent, il vient de la structure interne du fichier MP4.

Pour qu’une vidéo MP4 puisse être lue progressivement, les métadonnées nécessaires à la lecture doivent se trouver au début du fichier. Dans un MP4, ces métadonnées sont stockées dans ce que l’on appelle le moov atom. Si ce bloc se trouve à la fin du fichier, le navigateur doit parfois attendre d’avoir téléchargé toute la vidéo avant de commencer la lecture.

La solution moderne consiste à optimiser le fichier MP4 avec FFmpeg et l’option -movflags +faststart.

Pourquoi une vidéo MP4 ne démarre pas immédiatement ?

Un fichier MP4 contient plusieurs blocs internes, appelés atoms ou boxes. Parmi eux, le bloc moov contient les métadonnées nécessaires au lecteur : pistes audio et vidéo, durées, index, informations de synchronisation, etc.

Si le bloc moov est placé à la fin du fichier, le navigateur ou le lecteur doit atteindre cette partie avant de savoir comment lire correctement la vidéo. Sur un fichier local, ce n’est pas très grave. Sur le web, cela peut provoquer une attente frustrante.

Pour une vidéo web classique, on veut donc placer le moov atom au début du fichier. Ainsi, le navigateur peut lire les métadonnées immédiatement, puis commencer la lecture pendant que le reste de la vidéo continue de se télécharger.

C’est ce que l’on appelle souvent la lecture progressive. Ce n’est pas du streaming adaptatif comme HLS ou DASH, mais c’est largement suffisant pour beaucoup de vidéos MP4 intégrées dans une page web.

Lire FFmpeg : optimiser une vidéo MP4 pour la lecture progressive

MySQL : résoudre le message "Warning: Using a password on the command line interface can be insecure." photo

MySQL ne redémarre plus : résoudre une partition pleine sur /var/lib/mysql

par · Lecture: 13 minutes

Il y a quelque temps, j’ai eu la mauvaise surprise de constater qu’un site était hors ligne parce que MySQL refusait catégoriquement de redémarrer.

En regardant les logs du serveur, le message était sans appel :

/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! failed!Langage du code : JavaScript (javascript)

La partition qui contenait les bases de données était pleine. Et quand MySQL n’a plus assez d’espace pour écrire dans son répertoire de données, ses fichiers temporaires, ses logs, ses redo logs ou ses binlogs, il peut refuser de démarrer, se bloquer, désactiver certains logs ou planter au mauvais moment.

MySQL documente explicitement les erreurs liées au disque plein, comme No space left on device, write failed ou les dépassements de quota. Le manuel MySQL explique que ces conditions peuvent toucher les écritures dans les tables, les fichiers de logs binaires et l’index des binlogs. Voir la documentation MySQL sur les disques pleins.

Voici une procédure moderne pour diagnostiquer et corriger le problème proprement, sans supprimer au hasard des fichiers dans /var/lib/mysql. Parce que supprimer des fichiers InnoDB à la main pour “faire de la place”, c’est rarement une stratégie. C’est plutôt une candidature spontanée à la restauration de backup.

Symptômes d’un MySQL bloqué par manque d’espace disque

Les symptômes peuvent varier selon la version, le moteur de stockage, la distribution et le système d’init. Vous pouvez voir :

  • MySQL ou MariaDB refuse de démarrer ;
  • systemctl start mysql échoue ;
  • systemctl restart mariadb reste bloqué ;
  • les sites affichent une erreur de connexion à la base ;
  • les logs indiquent No space left on device ;
  • les binlogs grossissent jusqu’à saturer la partition ;
  • les tables temporaires ne peuvent plus être créées ;
  • la partition /, /var, /tmp ou /var/lib/mysql est à 100 % ;
  • les inodes sont épuisés même s’il reste de l’espace en Go.

Sur les serveurs modernes, l’erreur peut apparaître dans le log MySQL, les logs MariaDB ou le gestionnaire d’hébergement. Plesk documente par exemple des échecs MySQL/MariaDB lorsque la partition racine, la partition /tmp ou les inodes sont saturés. Voir la note Plesk sur MySQL/MariaDB et le manque d’espace.

Lire MySQL ne redémarre plus : résoudre une partition pleine sur /var/lib/mysql

Articles suivants →