Processus, permissions, disque plein, réseau et journaux : les questions Linux d’un entretien d’administration ou de plateforme.
Cliquez sur une question pour dérouler la réponse attendue.
Un processus a son propre espace mémoire ; les threads d’un même processus le partagent. C’est pour cela qu’un thread qui corrompt la mémoire fait tomber tout le processus, alors qu’un processus voisin continue.
Lire la réponse détailléeps photographie ; top et htop filment. Ce n’est pas deux façons d’obtenir la même liste : l’une sert à prouver un état à un instant, l’autre à voir qui monte.
Dans ps aux ou ps -eo pid,user,pcpu,pmem,stat,etime,args --sort=-pcpu, vous lisez cinq choses, dans cet ordre :
USER) : un démon root n’a pas la même surface qu’un job utilisateur.STAT) : R court, S attend (souvent normal), D attend le disque sans pouvoir être interrompu, Z est un zombie, T est stoppé.etime) : un java né il y a 3 secondes après un redémarrage n’est pas le même incident qu’un process de 47 jours.python sans chemin ni script est souvent un worker mal lancé.top ajoute le temps réel : qui grimpe, qui oscille, qui reste en D. La charge en tête de top n’est pas le pourcentage CPU ; c’est une autre question. Ici, on veut le tri (P CPU, M mémoire) et le lien PID → service (systemctl status <pid>).
Ce que l’intervieweur attend : vous ne « listez pas les process ». Vous choisissez une colonne selon l’hypothèse. CPU qui s’envole → tri CPU. Machine qui swap → RSS et si/so. Service muet → état D ou Z, puis /proc/<pid>/fd et les journaux. Une sortie ps sans question préalable est une liste, pas un diagnostic.
kill sans numéro envoie SIGTERM (15). Le processus peut l’attraper : fermer des sockets, vider des tampons, retirer un verrou, s’arrêter proprement. kill -9 envoie SIGKILL. Le noyau arrête le processus sans lui parler. Aucun gestionnaire, aucun finally, aucun arrêt systemd gracieux.
L’ordre n’est pas une préférence esthétique. TERM d’abord, parce que l’arrêt propre est une partie du contrat du service. Une base qui meurt en -9 laisse un journal à rejouer, un PID file périmé, des connexions clientes coupées au milieu d’une transaction. Un serveur d’application laisse des fichiers temporaires et des verrous POSIX. systemctl stop envoie TERM, attend TimeoutStopSec, puis KILL : c’est exactement cette politique.
Quand -9 est légitime : le processus ignore TERM (boucle serrée qui ne revient jamais à epoll, binaire qui masque le signal, interpréteur gelé), ou il est en D depuis trop longtemps — et encore, KILL ne débloque pas un sleep non interruptible : le processus ne mourra qu’une fois le driver sorti de l’attente. Si kill -9 « ne fait rien », l’hypothèse n’est plus le signal, c’est l’I/O ou un namespace.
La relance : « Pourquoi pas toujours -9, c’est plus sûr que ça reste ? » Parce que vous échangez une minute de patience contre des heures de réparation d’état. En entretien, nommez le signal, nommez ce qu’il permet, et dites que -9 est un dernier recours après observation (ps, journaux, strace un instant), pas le premier réflexe.
Le load average compte les tâches prêtes ou en attente disque, pas le pourcentage CPU. On le compare au nombre de cœurs, puis on tranche entre saturation processeur et file d’I/O.
Lire la réponse détailléeTrois triplets : propriétaire, groupe, autres. Sur chaque triplet, r lit, w écrit, x exécute. Sur un fichier, x autorise à le lancer. Sur un répertoire, x autorise à le traverser : sans x, vous pouvez parfois lister (r) et quand même ne pas cd ni ouvrir un fichier dont vous connaissez le nom. C’est le point que beaucoup d’entretiens cherchent.
Les nombres sont la même chose en octal. r=4, w=2, x=1. chmod 644 = rw-r--r-- : le propriétaire écrit, le monde lit. 755 = rwxr-xr-x : binaire ou dossier public. 600 pour une clé privée : personne d’autre ne lit. chmod 777 n’est pas « pour que ça marche » : c’est renoncer au modèle. On le dit, et on propose le bon masque.
chmod u+x script.sh est plus lisible qu’un octal quand on ajoute un droit. chmod -R sur / ou sur un home entier est l’incident classique : on casse ~/.ssh (qui exige 700 / 600) et des sockets.
Ce que l’intervieweur veut : vous savez pourquoi 755 sur un dossier (traverser + lister pour les autres) et pourquoi 640 sur un fichier de config qui contient un secret de groupe. Le nombre n’est pas une magie à mémoriser, c’est trois sommes. Et vous mentionnez que le bit d’exécution sur un dossier n’a rien à voir avec « lancer le dossier ».
chown utilisateur:groupe fichier change qui est évalué dans les triplets rwx. Le noyau compare d’abord votre UID au propriétaire ; si ce n’est pas vous, il compare vos groupes au groupe du fichier ; sinon, c’est « autres ». Une permission 640 (rw-r-----) ne sert que si les lecteurs légitimes sont dans le groupe, pas s’ils comptent sur « autres ».
C’est pour ça qu’un service www-data qui doit lire des fichiers déployés par deploy se règle avec un groupe commun (chown deploy:www-data + 640 ou 440), pas en mettant le service en root. chown -R trop large après une copie est l’autre face : vous donnez à un démon l’écriture sur des scripts, ou vous retirez au processus le droit d’écrire son propre socket.
ls -l montre user group. id montre vos groupes. Si id www-data n’inclut pas le groupe du fichier, aucun chmod g+r ne suffira tant que l’appartenance est fausse. Les ACL (getfacl) existent quand le modèle à un groupe ne suffit plus ; en entretien junior, le modèle POSIX suffit, à condition de ne pas oublier le groupe.
Relance : « Pourquoi ne pas tout mettre au même utilisateur ? » Parce que le propriétaire d’un binaire n’est pas celui qui doit le lancer, et parce que le moindre privilège se joue entre UID et GID. Deux rôles, un fichier : c’est exactement le groupe.
umask n’ajoute aucun droit. Il retire des bits au moment où un processus crée un fichier ou un dossier. Le mode demandé par open ou mkdir (souvent 666 pour un fichier, 777 pour un dossier) est masqué par le umask. Avec 022, un fichier naît en 644, un dossier en 755. Avec 077, personne d’autre que le propriétaire ne lit : 600 / 700.
C’est un réglage du processus, hérité au fork, pas une propriété du fichier déjà écrit. Changer le umask du shell n’a aucun effet sur nginx déjà lancé. D’où les surprises : un cron, un service systemd (UMask=), un utilisateur sudo n’ont pas le même masque que votre session interactive. Un fichier « trop ouvert » en production vient souvent d’un umask 000 ou 002 dans un job, pas d’un chmod volontaire.
umask -S le montre en lettres. Pour un démon qui écrit des secrets, on fixe 077 ou 027 dans l’unité, on ne « corrige après » avec un chmod oublié à la prochaine rotation.
L’intervieweur vérifie que vous ne confondez pas umask et chmod. L’un agit à la naissance ; l’autre sur l’existant. Et que vous savez pourquoi 002 est courant sur un serveur partagé (écriture groupe, pas « autres ») alors que 022 suffit pour un compte personnel.
Trois bits spéciaux, trois intentions.
setuid sur un binaire : le processus s’exécute avec l’UID du fichier, pas du lanceur. passwd doit écrire /etc/shadow : il est setuid root. C’est un élévation ciblée et historique. Un script setuid n’est en général pas honoré par le noyau, précisément parce que la surface (PATH, IFS, liens) est trop large. Un binaire setuid root que vous avez compilé vous-même est une porte : tout bug d’écriture devient root.
setgid sur un binaire : même idée pour le GID. Sur un répertoire, les fichiers créés héritent du groupe du dossier, pas du groupe primaire du créateur. C’est le levier des répertoires de projet partagés (775 + setgid) pour que tout le monde écrive dans le même groupe sans chgrp après coup.
sticky bit sur un dossier (chmod 1777 /tmp) : on peut créer, mais on ne supprime ou ne renomme que ses propres fichiers (ou root). Sans ça, /tmp en 777 permettrait d’effacer le socket ou le fichier temporaire du voisin.
ls -l montre s ou t à la place de x. find / -perm -4000 liste les setuid : c’est un réflexe d’audit, pas une curiosité. En entretien senior, on attend le risque (élévation, suppression croisée) et le cas légitime (passwd, /tmp, dossier projet), pas la table des bits.
On mesure d’abord quel système de fichiers est saturé, puis on descend dans l’arbre, puis on cherche les fichiers effacés encore ouverts. Supprimer au hasard est précisément ce qu’on ne fait pas.
Lire la réponse détailléeParce que df -h compte des blocs, pas des inodes. Un inode est l’enregistrement d’un fichier : nom à part, un petit fichier consomme un inode et presque aucun kilo-octet. Un répertoire de millions de cookies de session, de mails Maildir, de caches PHP ou de fichiers .tmp satura les inodes alors que Use% en blocs reste à 40 %. Le message est le même : No space left on device. Le débutant regarde df -h et conclut que « ce n’est pas le disque ».
df -ihLa colonne IUse% à 100 % tranche. Ensuite on cherche où il y a trop de fichiers, pas trop de gigaoctets :
sudo find /var -xdev -printf '%h\n' | sort | uniq -c | sort -n | tailou un du --inodes selon la version. Le remède n’est pas truncate d’un gros journal : c’est supprimer ou rotater des nuées de petits fichiers, corriger l’application qui les crée, monter un FS avec plus d’inodes si le motif est structurel.
L’autre piège, plus rare au même oral : quota utilisateur, volume thinly provisioned, ou réserve root (tune2fs) qui fait échouer un process non-root alors que df montre 5 % libres. En entretien, le cas attendu reste inodes. Vous montrez que vous savez changer d’unité de mesure avant de changer de théorie.
df lit le compteur de blocs du système de fichiers ; du additionne les fichiers encore visibles. Un écart vient presque toujours d’un fichier effacé toujours ouvert, d’un autre mount, ou d’un sparse file.
Lire la réponse détailléeOn ne « lit pas les logs ». On cadre : quel unité, quelle fenêtre, quel niveau, puis on élargit.
systemctl status nginx
journalctl -u nginx -n 200 --no-pager
journalctl -u nginx --since "10 min ago"status donne l’état (failed, activating), le code de sortie, les dernières lignes et le PID. Ça suffit souvent. journalctl -u évite de noyer le signal dans tout le journal. -p err filtre la gravité ; -xe après un systemctl start qui échoue montre le contexte du dernier échec.
La panne n’est pas toujours l’unité que l’on croit. Un service en StartLimitHit a déjà échoué N fois : il faut l’échec précédent, pas le message « failed to start » du refus actuel. journalctl -u foo -b (depuis le boot) ou _SYSTEMD_UNIT=foo.service tranche. Pour une machine entière : journalctl -p err -b puis on resserre.
Pourquoi pas tail /var/log/syslog d’abord ? Parce que beaucoup d’unités n’écrivent que dans le journal, que la rotation a déjà coupé le fichier, et que systemd sait l’unité, le PID, le boot. Les fichiers sous /var/log restent utiles pour une appli qui logue elle-même ; on les prend en plus, pas à la place.
Relance : « Le service restart en boucle. » Vous regardez Restart= et StartLimitBurst, le ExecStart (chemin, user, permissions), et les lignes avant le kill — OOM, bind de port, socket, dépendance Requires qui n’est pas active.
Sans rotation, un service stable remplit le disque. Avec une mauvaise rotation, vous croyez avoir tourné la page et le processus écrit encore dans l’inode ancien : df ne baisse pas. Ce n’est donc ni « un cron de ménage » ni un paramètre cosmétique.
Deux mondes. journald : SystemMaxUse=, MaxFileSec= dans journald.conf, puis journalctl --disk-usage et journalctl --vacuum-size=500M en urgence. logrotate : un fichier sous /etc/logrotate.d/ décrit fréquence, compress, delaycompress, et surtout postrotate (reload nginx, kill -USR1). Oublier le signal, c’est le fichier deleted de 20 Go.
Vérifier : ls -lh /var/log, dates des .1 / .gz, logrotate -d /etc/logrotate.conf (dry-run), et pour une unité : est-ce qu’elle logue vers le journal, un fichier, ou les deux. Un conteneur sans driver de log limité (max-size) contourne logrotate de l’hôte et remplit /var/lib/docker.
En entretien, le bon fil : qui écrit, qui ferme, qui signale. La rotation réussie, c’est un nouveau fichier et un processus qui l’a rouvert. Le reste est de la place disque différée.
Cron n’est pas « le même shell que le vôtre ». Trois pièges reviennent à chaque incident.
PATH. Un crontab a un PATH minimal (/usr/bin:/bin). aws, kubectl, un venv, même php selon la distro : introuvables. Le job échoue en une ligne, souvent sans que vous le voyiez. On fixe PATH= en tête, on utilise des chemins absolus, on ne « teste pas seulement à la main dans SSH ».
L’utilisateur. /etc/crontab a une colonne user ; crontab -e de deploy n’est pas root. Les fichiers écrits n’ont pas le bon propriétaire ; ~ et les clés SSH ne sont pas ceux que l’on croit. sudo crontab -e vs /etc/cron.d/ : encore un autre contexte.
Le courrier et le silence. Cron envoie la sortie à MAILTO. S’il n’y a pas de MTA, ou que personne ne lit root, l’échec est invisible. On redirige vers un fichier et on teste le code de sortie (set -e, wrapper qui journalise). cron n’a pas l’environnement de systemctl --user : pas les mêmes variables, pas le même umask, souvent pas de TTY, d’où des scripts interactifs qui « marchent en SSH ».
En plus : le % dans crontab est un saut de ligne ; les fuseaux (CRON_TZ) ; et un job long qui se chevauche (flock). L’intervieweur veut que vous reproduisiez l’environnement cron (env -i PATH=... /chemin/script) au lieu de relancer le script dans votre session pour « vérifier ».
Une clé privée reste privée, l’agent évite de la recopier, le fichier des clés autorisées lie une clé publique à un compte. On ne se connecte pas en root par mot de passe, et on ne commite jamais une clé.
Lire la réponse détailléeUn port en écoute, c’est un processus qui a appelé bind + listen. La question n’est pas « la liste », c’est qui écoute où (adresse et namespace).
ss -lntup-l listening, -n pas de résolution DNS (sinon ss attend), -t/-u TCP/UDP, -p le processus. 0.0.0.0:8080 est le monde ; 127.0.0.1:8080 seulement la machine ; :: IPv6. Beaucoup d’« ça marche en local mais pas de l’extérieur » s’arrêtent là : le service n’a jamais écouté sur l’interface publique.
lsof -iTCP:8080 -sTCP:LISTEN quand vous partez du numéro. ss a remplacé netstat sur les distros actuelles ; dire les deux est acceptable, s’accrocher à netstat comme seule vérité l’est moins.
Pourquoi ce n’est pas un listing : dans un conteneur ou un réseau privé, ss sur l’hôte ne montre pas le listen du netns voisin. Un docker port / ss dans le namespace évite de conclure « rien n’écoute » alors que le process est dans un autre monde. Et un TIME-WAIT n’est pas une écoute : confondre les colonnes de ss -tan fait croire qu’un port est pris alors que rien n’accepte de connexion.
L’entretien : vous liez port → PID → unité (systemctl status <pid>), et vous dites si le bind est local ou global.
« En local » veut souvent dire : sur votre laptop, le nom résout. Le serveur a un autre /etc/resolv.conf, un autre cache, parfois pas de sortie UDP/53. Vous ne déboguez pas « le DNS ». Vous déboguez quel résolveur, depuis quelle machine.
Sur le serveur :
cat /etc/resolv.conf
getent hosts api.example.com
dig +short api.example.comgetent passe par NSS (nsswitch.conf) : fichiers, DNS, parfois mdns. dig parle au résolveur listé, ou à @8.8.8.8 pour séparer « le nom n’existe pas » de « notre relais est mort ». Un curl qui échoue alors que dig réussit n’est plus du DNS : c’est TCP, TLS, proxy (NO_PROXY), ou IPv6 (AAAA qui part dans le vide, curl -4 pour tester).
Les classiques plateforme : resolv.conf géré par systemd-resolved / Docker / DHCP qui pointe vers un résolveur interne injoignable depuis ce VPC ; search domain qui transforme db en db.corp.local chez vous et pas sur le nœud ; TTL et cache (resolvectl flush-caches).
Vous parlez de chemin : machine → resolv.conf → serveur DNS → autorité. Vous changez un maillon à la fois. Relancer dig sur le laptop ne prouve rien sur le serveur.
Le noyau choisit une victime quand la mémoire est épuisée : le processus disparaît avec un code 9, et dmesg ou journalctl portent une ligne Out of memory. Ce n’est ni un crash applicatif ni un kill d’opérateur.
Lire la réponse détailléeulimit expose les rlimits : plafonds du processus (et de ses enfants) sur les fichiers ouverts, la taille du core, la pile, les processus, parfois la mémoire virtuelle. Ce ne sont pas des « réglages de confort ». Quand une appli atteint nproc ou nofile, l’échec ressemble à un bug : Too many open files, fork: Resource temporarily unavailable, un thread qui ne démarre plus.
ulimit -a
cat /proc/<pid>/limitsLe piège : ulimit dans votre shell ne dit rien du démon. systemd a LimitNOFILE=, LimitNPROC= ; un service lancé au boot a les limites de l’unité, pas celles de /etc/security/limits.conf d’une session SSH. PAM applique limits.conf aux logins, pas forcément à PID 1. D’où « ça marche quand je lance à la main, pas sous systemd ».
On ne monte pas nofile à l’infini par magie : chaque descripteur coûte, et masquer une fuite de sockets ne soigne rien. On mesure (ls /proc/pid/fd | wc -l contre la limite), on cherche la fuite, on aligne la limite sur un besoin réel (proxies, Java, bases).
Relance : soft vs hard. Le soft est le plafond actuel ; le hard est le max que le process non-root peut se donner. Un service qui s’auto-augmente encore besoin que le hard le permette.
Un lien dur est un autre nom pour le même inode : deux chemins, un seul contenu, un seul compteur de blocs. Effacer un nom ne libère les données que lorsque le dernier nom (et le dernier descripteur) disparaît. Les liens durs ne traversent pas les systèmes de fichiers — l’inode est local à un FS — et on ne fait généralement pas de lien dur sur un répertoire.
Un lien symbolique est un petit fichier qui contient un chemin. ls -l montre ->. Si la cible bouge ou disparaît, le lien casse (dangling). Il peut pointer hors du disque, vers un mount qui n’est pas encore là, vers un chemin relatif trompeur. ln -s crée ça ; ln sans -s crée un dur.
Pourquoi l’entretien insiste : du et les sauvegardes. Un dur n’est pas dupliqué en blocs ; deux symlinks vers le même gros fichier, du peut compter deux fois selon les options. rm d’un symlink enlève le lien, pas la cible ; rm d’un dur enlève un nom. cp -a et rsync -a préservent les symlinks ; les suivre (-L) copie la cible et surprend.
La phrase utile : le dur partage l’inode ; le symbole partage une adresse. Pour /etc/alternatives ou un current -> releases/42, c’est du symbole. Pour ne pas copier un gros fichier deux fois sur le même volume, c’est du dur.
/proc n’est pas un disque de fichiers « système ». C’est le noyau exposé en arborescence. Chaque /proc/<pid>/ est l’état live d’un processus : vous lisez sans lui envoyer de signal et sans dépendre de ps qui n’affiche qu’une vue.
Ce qu’on ouvre vraiment :
cmdline, exe : ce qui a été lancé, même si ps tronque ou que quelqu’un a fait un exec.environ : les variables réelles du démon (séparateur NUL) — d’où « ça marche dans mon SSH ».fd/ : fichiers et sockets ouverts ; les deleted s’y voient.limits, status (VmRSS, Threads, Cpus_allowed) : rlimit, mémoire, affinité.cgroup : dans quel plafond mémoire / CPU il vit.net/tcp et, au niveau machine, /proc/meminfo, /proc/loadavg, /proc/diskstats.ls -l /proc/pid/fd plus readlink explique un port, un fichier verrouillé, un cwd (cwd). C’est plus fiable qu’un lsof quand lsof n’est pas installé.
On ne « configure pas l’OS en éditant /proc » au hasard (echo dans sysctl est une autre histoire, /proc/sys). En debug, /proc est la source ; ps et top n’en sont que des extraits. C’est la phrase attendue.
nice ajuste la priorité CPU de l’ordonnanceur, pas la vitesse du disque ni la latence réseau. Une valeur nice haute (jusqu’à 19) veut dire moins prioritaire : le processus cède le CPU aux autres quand il y a contention. Une valeur basse (jusqu’à -20, root) le favorise. S’il n’y a personne d’autre à faire tourner, nice ne change presque rien : la machine idle donne le CPU à tout le monde.
On nice un batch, une compression, un find de nuit, pour qu’ils n’allongent pas les requêtes d’un service. On ne nice pas un démon à +19 en croyant « calmer la charge » : s’il est le travail utile, vous le rendez juste plus lent sous charge. ionice est l’équivalent I/O ; le confondre avec nice est fréquent.
ps -o pid,ni,pri,comm ; renice sur un PID déjà lancé. systemd : Nice= dans l’unité, plus propre qu’un wrapper oublié.
Relance : « Ça réduit le load average ? » Pas forcément. Le process tourne toujours, il est juste moins souvent élu. Le load compte les tâches prêtes ; un batch nice reste prêt. Nice est un arbitrage, pas une réduction de travail.
strace affiche les appels système. Vous le sortez quand le processus est vivant, ne progresse pas, et que les journaux mentent ou se taisent : il n’est pas « occupé en userland », il attend le noyau — ou il martèle la même erreur.
Cas justes : hang au démarrage (open d’un fichier manquant, connect vers une IP morte, attente futex), EACCES / ENOENT répétés, DNS qui bloque dans read d’un socket, lecture d’un FS réseau. Vous attachez (-p PID), vous limitez (-e open,connect,network), vous ne laissez pas un -f verbeux sur une prod saturée sans filet : chaque appel est intercepté, le process peut ralentir d’un ordre de grandeur.
Ce que vous cherchez n’est pas « la liste des syscalls ». C’est le dernier appel qui ne revient pas, ou le errno en boucle. strace -c donne un histogramme si vous soupçonnez trop de petits read. Pour du CPU pur en userspace, strace est le mauvais outil (perf, un profiler). Pour un deadlock Java, les futex sans le stack applicatif ne suffisent pas.
En entretien : hypothèse → un filtre d’appels → une preuve → on retire strace. Ce n’est pas un mode de supervision.
À la main, votre shell a un PATH riche et parfois un alias. Le script lancé par cron, systemd ou sudo non login n’a pas ce PATH. python ou aws devient « command not found » alors que la même ligne dans SSH réussit. Ce n’est pas que le script est faux : c’est que la recherche de binaire a changé.
Le shebang (#!/usr/bin/env python3 ou #!/usr/bin/python3) dit quel interpréteur le noyau exécute. Sans shebang, un fichier lancé avec ./script échoue (exec format) ; lancé avec bash script ça passe, d’où « ça marche selon comment on l’appelle ». env python3 dépend encore du PATH de l’appelant. Un chemin absolu dans le shebang est plus reproductible ; un venv se fixe avec le python du venv, pas python3 système.
chmod +x est requis pour ./. Les fins de ligne Windows (CRLF) cassent le shebang : python3\r introuvable — classique après un clone mal configuré.
La réponse d’entretien : reproduire l’environnement d’exécution (PATH vide, user du service, shebang visible avec head -1), pas relancer le script dans le terminal où il marchait déjà.
Un compte personne, un compte service, root le moins souvent possible. L’humain n’est pas www-data ; le démon n’a pas de shell login ni de clé SSH. sudo n’est pas « devenir root pour tout » : c’est une liste d’actions (sudoers) journalisées, idéalement des commandes précises, pas ALL=(ALL) NOPASSWD: ALL copié d’un tutoriel.
Le moindre privilège se lit dans trois couches : UID du process (unité User=), groupes pour les fichiers partagés, capabilities si un binaire a besoin d’un bind 80 sans être root (AmbientCapabilities=). Donner UID 0 à un conteneur « pour que le volume s’écrive » est l’anti-réponse.
sudo -l montre ce que vous avez le droit de faire. /etc/sudoers.d/ plutôt qu’un visudo monolithique. Les incidents : un script sudo sans chemin absolu (PATH hijack), un sudo su habituel qui annule tout le modèle, des clés déployées sur un compte partagé ubuntu.
Phrase attendue : on élève une action, pas une session, et chaque service a l’identité minimale qui lui permet d’ouvrir ses fichiers et ses ports — rien de plus.
Ce sont des MAC (contrôle d’accès obligatoire) : même root ou un process compromis reste dans une politique. DAC (rwx, owner) dit ce que le propriétaire autorise ; MAC dit ce que la politique de la machine autorise en plus. Un démon web n’a pas à écrire /etc/shadow même s’il a un bug d’écriture.
SELinux (RHEL, Fedora, parfois Android) étiquette processus et fichiers (ps -Z, ls -Z). Les refus vont dans l’audit (ausearch, journalctl avc: denied). setenforce 0 « pour que ça marche » est le geste que l’intervieweur attend que vous refusiez comme solution : on met le domaine en permissif le temps de collecter, on ajuste le fcontext (semanage fcontext, restorecon), on ne désactive pas le cadre.
AppArmor (Ubuntu, SUSE) attache un profil à un chemin de binaire. Plus simple à raconter, moins granulaire que les types SELinux. aa-status, logs apparmor="DENIED", aa-complain le temps d’apprendre.
En deux minutes : à quoi ça sert (réduire le blast radius), comment on voit un refus (AVC / DENIED, pas l’erreur applicative seule), comment on corrige (label / profil, pas chmod 777 + SELinux off). Si vous dites seulement « ça bloque, je le coupe », la question est ratée — c’est précisément le test.
On nomme d’abord l’état : attend-il le CPU, le disque, le réseau, un verrou ou un signal. Ensuite on prouve avec ps, /proc et éventuellement strace, au lieu de redémarrer pour voir.
Lire la réponse détailléePing prouve un chemin ICMP, pas un service. On vérifie ensuite le port, l’écoute, le pare-feu, le DNS et la couche TLS, dans cet esprit : chaque test isole un étage.
Lire la réponse détailléeParce que beaucoup de services n’écrivent pas que dans leur répertoire métier. Ils écrivent des sockets, des PID, des journaux, des sockets systemd, des work files PostgreSQL (/var/lib), des overlays Docker, des sessions PHP, des tmp de sort et de systemd-private. Quand /var ou /tmp est un FS dédié à 100 %, l’échec remonte comme une erreur applicative absurde : impossible de créer un worker, Read-only file system mal lu, No space left, échec de bind sur un socket dans /run si /run est plein aussi (tmpfs).
/tmp plein casse les compilations, Java (java.io.tmpdir), les uploads, ansible, les scripts qui font mktemp. /var plein casse journald, les bases, les paquets (/var/cache), Docker. Le service « web » qui « n’écrit que des réponses » écrit quand même access.log, et le reverse proxy écrit dans /var/log.
On ne devine pas. df -h /var /tmp /run puis du -xh sur ces mounts. On relie le message d’erreur au FS du chemin dans l’erreur, pas au home de l’appli. Un PrivateTmp= systemd isole un /tmp privé : l’hôte peut être libre et l’unité saturée dans son namespace — systemctl status et le cgroup.
Relance : « On a agrandi le disque racine, ça continue. » /var était un autre volume. df par mount, encore une fois.
Symptôme précis, hypothèses classées, une preuve qui en élimine, puis une action. L’outil vient après la question, jamais l’inverse.
Lire la réponse détaillée