Sujet : error-message
-
Les avertissements SSH « Host key verification failed » et « REMOTE HOST IDENTIFICATION HAS CHANGED »
OpenSSH refuse de se connecter et affiche « Host key verification failed » ou la grande bannière « WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! » lorsque la clé du serveur ne correspond pas à celle enregistrée dans known_hosts. L'article explique pourquoi un serveur reconstruit et une véritable attaque produisent le même message, et comment les distinguer avant d'exécuter ssh-keygen -R.
-
Erreurs de vérification TLS selon les outils : unknown authority, CERTIFICATE_VERIFY_FAILED, certificat auto-signé dans la chaîne
Différents clients TLS signalent, chacun à sa façon, la même défaillance de fond, une chaîne de certificats incomplète ou non fiable : 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. L'article montre comment diagnostiquer la chaîne réelle avec openssl s_client avant toute correction, et pourquoi -k ou verify=False n'en est jamais une.
-
« Too many open files » (EMFILE) et la limite de descripteurs de fichiers
EMFILE, signalé par « Too many open files », indique qu'un processus a atteint sa propre limite de descripteurs de fichiers ouverts simultanément, documentée sous le nom RLIMIT_NOFILE. L'article explique comment distinguer une vraie fuite de descripteurs d'une limite simplement trop basse, et comment la relever au niveau du shell, de PAM et de l'unité systemd.
-
« Permission denied (publickey) » avec SSH : l'interpréter grâce à ssh -v
Dans OpenSSH, « Permission denied (publickey) » signifie que toutes les clés proposées par le client ont été rejetées, ou qu'aucune n'a été proposée, sans préciser laquelle. L'article montre comment ssh -v désigne précisément les clés essayées et passe en revue les cas suivants : mauvais nom d'utilisateur, IdentitiesOnly, permissions d'authorized_keys côté serveur et abandon par défaut de ssh-rsa (SHA-1) depuis OpenSSH 8.8.
-
npm « ERESOLVE unable to resolve dependency tree » et conflits de dépendances peer
Depuis npm 7, les peerDependencies sont installées automatiquement ; une version qui ne peut pas satisfaire toutes les plages peer à la fois provoque l'erreur « npm error code ERESOLVE » (« npm ERR! code ERESOLVE » avant npm 10.6). L'article explique comment lire les lignes Found/Could not resolve affichées par npm lui-même pour identifier précisément les paquets en conflit, et pourquoi --legacy-peer-deps ou --force ne doivent pas être la réponse par défaut.
-
« exec format error » et « cannot execute binary file » : incompatibilités d'architecture et de shebang
L'erreur ENOEXEC du noyau apparaît sous la forme « exec format error » ou « cannot execute binary file: Exec format error » lorsque l'architecture du processeur ne correspond pas ou qu'un script n'a pas de shebang exploitable ; des fins de ligne CRLF dans le shebang provoquent une erreur voisine, « bad interpreter » ou « required file not found ». L'article montre comment les distinguer avec file(1) et corriger chaque cas sans tâtonner.
-
L'erreur Git « detected dubious ownership in repository » et le correctif safe.directory
Git refuse de travailler dans un dépôt appartenant à un autre utilisateur que celui qui lance la commande, avec le message « fatal: detected dubious ownership in repository at ». L'article explique le correctif de CVE-2022-24765 à l'origine de ce contrôle, les cas où une entrée safe.directory par dépôt convient, et pourquoi chown est la meilleure solution dans les conteneurs et la CI.
-
« Argument list too long » (E2BIG) et la limite ARG_MAX
Une commande shell dont l'expansion produit trop d'arguments échoue avec « Argument list too long », l'erreur E2BIG renvoyée par execve(2) lorsque la limite ARG_MAX du noyau est dépassée. L'article montre comment mesurer cette limite et remplacer un glob défaillant par xargs ou par le regroupement de find avec -exec ... +, plutôt que de jouer sur le quoting.
-
« Text file busy » (ETXTBSY) : écriture dans un exécutable en cours d'exécution
ETXTBSY, affiché sous la forme « Text file busy », signale qu'on a tenté d'ouvrir en écriture le fichier d'un programme en cours d'exécution. L'article montre comment trouver le processus qui le maintient ouvert, et pourquoi un déploiement par renommage, plutôt que par écrasement sur place, évite l'erreur et toute interruption de service.
-
« error: externally-managed-environment » de pip et la PEP 668
pip refuse un « pip install » global avec « error: externally-managed-environment » lorsque la distribution a déclaré son Python système comme géré, conformément à la PEP 668. L'article explique le rôle du marqueur EXTERNALLY-MANAGED, les solutions dans l'ordre (venv, pipx, apt) et pourquoi --break-system-packages est un dernier recours, pas une option par défaut.
-
« ENOSPC: System limit for number of file watchers reached » et les limites d'inotify
Les surveillants de fichiers reposant sur l'API inotify de Linux échouent avec « ENOSPC: System limit for number of file watchers reached » lorsqu'une limite du noyau par utilisateur est épuisée, le plus souvent en surveillant node_modules ou d'autres arborescences volumineuses. L'article présente les deux paramètres sysctl concernés, la façon de relever les limites de manière persistante et la raison pour laquelle les conteneurs partagent en général la limite de l'hôte.
-
"version `GLIBC_2.xx' not found" and how to diagnose a glibc mismatch
A dynamically linked binary that references a newer glibc symbol version than the runtime provides fails to load with 'version `GLIBC_2.xx' not found'. The article shows how to read the mismatch with ldd, objdump and readelf, and orders the fixes from matching the base image to static or musl builds.
Lisible par machine : JSON