Explication des valeurs affichées dans htop/top sous Linux (2019)

• En partant de l’écran htop d’Ubuntu Server 16.04 x64, suit via /proc et la sortie de commandes ce que signifient réellement uptime, load average, Tasks, PID, l’arborescence des processus, l’état, le temps CPU, la priorité et les indicateurs mémoire
• Beaucoup de valeurs affichées proviennent de procfs et de fichiers système comme /etc/passwd, /etc/group, /etc/shadow ou /etc/nsswitch.conf, et strace permet de vérifier quels fichiers le programme lit
• Le load average n’est pas la même chose que le taux d’utilisation du CPU ; c’est une moyenne mobile à décroissance exponentielle qui inclut les processus en cours d’exécution, ceux en attente d’exécution et ceux en état uninterruptible
• Les codes d’état comme R, S, D, Z, T et t sont liés au fonctionnement des signaux, de kill, de fork/exec/wait, et donnent des indices pour comprendre pourquoi un processus est arrêté ou reste présent
• VIRT, RES, SHR et MEM% montrent la mémoire virtuelle, la mémoire physique et la mémoire partageable sous des angles différents ; il est donc difficile de conclure à l’usage mémoire réel à partir d’un seul chiffre

---

D’où viennent les valeurs de htop

• uptime indique depuis combien de temps le système fonctionne ; la même information peut aussi être consultée avec la commande uptime
• Le programme uptime lit /proc/uptime
  • Le premier nombre est la durée totale, en secondes, pendant laquelle le système est resté allumé
  • Le second nombre est la durée, en secondes, pendant laquelle le système est resté en état idle
  • Sur un système multicœur, le temps idle est additionné par cœur et peut donc être supérieur à l’uptime total
• strace uptime 2>&1 | grep open ou strace -e open uptime permet de voir les fichiers ouverts par uptime
  • Un exemple de sortie inclut /proc/uptime, /var/run/utmp et /proc/loadavg
• Les nombres de /proc/uptime sont pratiques pour les programmes ou les scripts, tandis que la sortie de uptime est formatée pour être lisible par un humain

Load average et utilisation CPU

• Les trois premières valeurs de /proc/loadavg représentent le load average du système sur les 1, 5 et 15 dernières minutes
• La quatrième valeur affiche le nombre de processus actuellement en cours d’exécution et le nombre total de processus sous une forme comme 1/120, et la dernière valeur est le dernier PID utilisé
• Lorsqu’un nouveau processus est lancé, un PID lui est attribué ; en général, les PID augmentent puis sont réutilisés lorsqu’ils sont épuisés
  • Le PID 1 appartient à /sbin/init, lancé au démarrage
• Si un seul processus apparaît comme en cours d’exécution dans htop, il peut s’agir de htop lui-même
• sleep 30 n’est pas en cours d’exécution mais en état sleep, il n’augmente donc pas le nombre de running processes
• Une tâche qui consomme continuellement du CPU, comme cat /dev/urandom > /dev/null, augmente le nombre de running processes et le load average
• Le load number est une valeur qui compte les processus en cours d’exécution ou en attente d’exécution, ainsi que les processus en état uninterruptible
• Le load average n’est pas une moyenne simple, mais une moyenne mobile à décroissance exponentielle
  • Même le load average sur 1 minute ne reflète pas uniquement les 60 dernières secondes : il donne plus de poids à la dernière minute tout en incluant aussi une partie de l’activité antérieure
• Sur un système mono-CPU, avec un processus CPU-bound, on peut simplifier en considérant qu’un load average de 1.00 correspond à 100 % d’utilisation CPU
  • Sur un système à 2 cœurs, la même situation peut être vue comme 50 % d’utilisation CPU
  • Sur un système à 2 cœurs, le load average correspondant à 100 % d’utilisation CPU peut être simplifié à 2.00
• Cette simplification n’est pas toujours exacte, car les processus en état uninterruptible sont inclus dans la charge
  • Il est donc possible d’avoir un load average élevé sans que l’utilisation CPU soit élevée
• L’utilisation CPU instantanée peut être vérifiée avec mpstat
  • sudo apt install sysstat -y
  • mpstat 1

Tasks, PID et arborescence des processus

• Tasks, en haut à droite dans htop, affiche le nombre total de processus et le nombre de processus en cours d’exécution
• Le noyau Linux appelle en interne les processus des tasks, et htop utilise Tasks au lieu de Processes pour économiser de l’espace à l’écran
• Shift+H permet d’activer ou de désactiver l’affichage des threads
  • Si vous voyez quelque chose comme Tasks: 23, 10 thr, les threads sont affichés
• Shift+K permet d’activer ou de désactiver l’affichage des kernel threads
  • Si vous voyez quelque chose comme Tasks: 23, 40 kthr, les kernel threads sont affichés
• Un PID est attribué à chaque lancement d’un nouveau processus
  • Lorsqu’on l’exécute en arrière-plan, comme avec sleep 1000 &, le numéro de job et le PID sont affichés
  • Dans bash, $! est développé en l’ID du dernier processus lancé en arrière-plan
• Les informations relatives aux processus se trouvent sous /proc/<pid>/
  • /proc/<pid>/cmdline contient la commande exécutée, avec les arguments séparés par des octets \0
  • tr '\0' '\n' < /proc/<pid>/cmdline ou strings /proc/<pid>/cmdline permet de l’afficher de façon plus lisible
  • /proc/<pid>/cwd est un lien vers le répertoire de travail courant, et /proc/<pid>/exe un lien vers le binaire exécuté
• Les outils de diagnostic comme htop, top et ps lisent les détails des processus dans /proc/<pid>/<file>
• Celui qui crée un nouveau processus est le parent process, le processus nouvellement créé est le child process, et cette relation forme l’arborescence des processus
• Dans htop, appuyer sur F5 permet de voir la hiérarchie des processus
  • ps f et pstree -a montrent aussi la même relation
• Quand on exécute date depuis bash, bash crée une copie de lui-même avec fork, charge /bin/date en mémoire avec exec, puis le bash parent attend la fin du child
• /sbin/init est lancé au démarrage et démarre sshd ; lors d’une connexion SSH, sshd crée un processus de session, et cette session exécute le shell bash

Utilisateurs et droits des processus

• Chaque processus appartient à un utilisateur, représenté par un ID numérique
• L’entrée Uid de /proc/<pid>/status permet de vérifier l’ID utilisateur d’un processus
• Une commande comme id 1000 affiche le nom d’utilisateur et les groupes correspondant à l’ID numérique
• id choisit la source de résolution des noms selon la configuration de /etc/nsswitch.conf
  • Dans le système d’exemple, il lit /etc/passwd et /etc/group
  • compat correspond au mode Compatibility, similaire à files mais autorisant des entrées spéciales
  • Les informations utilisateur peuvent aussi être stockées dans d’autres bases de données ou services, comme LDAP
• /etc/passwd et /etc/group sont des fichiers texte qui associent des ID numériques à des noms lisibles par l’humain
• Les vraies informations de mot de passe se trouvent dans /etc/shadow
  • $6$ désigne l’algorithme de hachage sha512
  • Viennent ensuite un salt aléatoire pour empêcher les attaques par rainbow table, puis le hash du mot de passe + salt
• Par défaut, un programme s’exécute avec les droits de l’utilisateur qui l’a lancé
  • C’est aussi le cas même si le propriétaire de l’exécutable est un autre utilisateur
• Pour l’exécuter en tant qu’un autre utilisateur ou en tant que root, on utilise sudo
  • sudo id s’exécute avec l’UID 0 de root
  • On peut l’exécuter en tant qu’utilisateur précis, par exemple avec sudo -u daemon id
• Si l’on tente d’écrire directement dans /etc/sudoers avec une redirection, seul echo est exécuté en root et l’append est effectué par l’utilisateur courant, ce qui peut échouer
  • echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers
  • sudo bash -c "echo '$USER ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers"
• /etc/sudoers doit être édité avec sudo visudo
  • Il valide le contenu avant l’enregistrement, afin d’éviter une erreur qui empêcherait d’utiliser sudo
• /usr/bin/passwd peut écrire dans /etc/shadow même lorsqu’il est exécuté par un utilisateur ordinaire
  • La présence de s dans les permissions du fichier le fait fonctionner comme un exécutable setuid
  • Il s’exécute avec les droits de root, le propriétaire de l’exécutable
  • Les exécutables setuid appartenant à root peuvent être trouvés avec find /bin -user root -perm -u+s

Codes d’état des processus

• La colonne d’état de htop est affichée sous le nom S, et ses principales valeurs sont les suivantes
  • R : running ou runnable, en cours d’exécution ou en attente dans la run queue
  • S : interruptible sleep, en attente de la fin d’un événement
  • D : uninterruptible sleep, généralement en attente d’I/O
  • Z : defunct zombie, terminé mais pas reap par son parent
  • T : arrêté par un signal de job control
  • t : arrêté par un debugger pendant un tracing
  • X : dead, état qui ne devrait pas être affiché
• ps affiche aussi des sous-états comme Ss, R+ ou Ss+

• R : en cours d’exécution ou exécutable

  • L’état R signifie qu’un processus est actuellement en cours d’exécution ou attend dans la file d’exécution
  • Le code source d’un programme, après compilation, devient des instructions CPU ; à l’exécution, il est chargé en mémoire et le CPU exécute ces instructions
  • Être en cours d’exécution signifie que le CPU exécute physiquement les instructions

• S : sleep interruptible

  • Dans l’état S, les instructions du processus ne sont pas exécutées par le CPU ; il attend un événement ou une condition
  • Quand l’événement se produit, le kernel passe son état à running
  • sleep 1000 est un exemple d’attente pendant une durée donnée
  • Cet état peut être interrompu par un signal
  • Dans htop, on peut envoyer un signal en appuyant sur F9
  • kill est un appel système qui envoie un signal, et /bin/kill est le programme userland qui l’appelle
  • Le signal par défaut est TERM, qui demande l’arrêt du processus
  • Les signals sont des nombres ; leurs noms sont généralement écrits en majuscules et peuvent avoir le préfixe SIG
  • Exemples : INT, KILL, STOP, CONT, HUP
  • kill -INT 10089, kill -2 10089 et /bin/kill -2 10089 produisent le même effet
  • Quand on appuie sur CTRL+C, bash envoie SIGINT au foreground process
  • Envoyer SIGINT ou SIGTERM ne garantit pas que le processus s’arrête
  • Un programme peut définir un signal handler pour effectuer des opérations de nettoyage puis se terminer
  • SIGKILL, ou 9, force le kernel à terminer le processus sans lui laisser la possibilité de répondre

• D : sleep non interruptible

  • L’état D ne peut pas être réveillé par un signal ; comme SIGKILL est aussi un signal, on ne peut pas tuer ce type de processus
  • Cet état est utilisé lorsqu’un processus doit attendre sans interruption, ou lorsque l’événement est censé se produire rapidement
  • Exemple : lecture/écriture disque
  • Un processus uninterruptible peut souvent être en attente d’I/O après un page fault
  • Ce type d’état peut apparaître lors de latences de lecture/écriture NFS
  • Il peut aussi apparaître lorsque la mémoire disponible est trop faible et que les processus swappent beaucoup
  • Par exemple, si l’on exécute sudo mount 8.8.8.8:/tmp /tmp &, /sbin/mount.nfs passe à l’état D
  • Avec strace, on voit que l’appel système mount bloque le processus
  • En passant l’option intr à mount, on peut l’exécuter de façon interruptible
  • sudo mount 8.8.8.8:/tmp /tmp -o intr

• Z : processus zombie

  • L’état Z signifie que le processus s’est terminé mais que son parent ne l’a pas encore reap
  • Un processus zombie peut être normal s’il n’existe que brièvement
  • Un processus zombie qui reste longtemps peut indiquer un bug du programme
  • Un processus zombie ne consomme pas de mémoire et n’occupe qu’un PID
  • On ne peut pas kill le processus zombie lui-même
  • On peut envoyer SIGCHLD au parent process pour lui demander de reap le zombie
  • En tuant le parent process, on peut supprimer le parent et ses zombies
  • On peut reproduire l’état zombie avec un programme C où, après fork, le child fait exit(0) et le parent fait sleep(20)
  • Quand le parent se termine, le zombie disparaît
  • La raison pour laquelle le zombie est conservé est que le parent doit pouvoir vérifier l’exit code du child avec l’appel système wait

• T et t : processus arrêtés

  • L’état T signifie que le processus a été arrêté par un signal de job control
  • Si l’on appuie sur CTRL+Z pendant l’exécution de cat /dev/urandom > /dev/null, il passe à l’état T
  • On peut le relancer avec fg
  • On peut aussi l’arrêter avec le signal STOP et le reprendre avec le signal CONT
  • L’état t signifie que le processus est arrêté pendant qu’un debugger le trace
  • Si l’on s’attache avec sudo gdb -p <pid> à un processus lancé avec nc -l 1234 &, il passe à l’état t

Temps CPU, niceness, priorité

• Linux étant un système d’exploitation multitâche, même avec un seul CPU plusieurs processus semblent s’exécuter simultanément
• En réalité, un CPU unique ne peut exécuter qu’une seule instruction à la fois ; il utilise donc le partage de temps (time sharing)
  • Un processus s’exécute brièvement puis est interrompu
  • Les autres processus en attente d’exécution s’exécutent à tour de rôle
  • Le court intervalle pendant lequel un processus s’exécute s’appelle un time slice
• Un time slice ne dure généralement que quelques millisecondes, ce qui se remarque peu tant que la charge du système n’est pas élevée
• Sur un seul cœur, si le load average vaut 1.0, on peut considérer que le CPU est utilisé à 100 %
  • S’il est supérieur à 1.0, il y a plus de processus à exécuter que le CPU ne peut en traiter, ce qui peut entraîner des ralentissements ou des délais
  • S’il est inférieur à 1.0, le CPU est parfois en état d’inactivité (idle)
• Le fait que le temps d’exécution d’un processus ne corresponde pas exactement au temps réellement écoulé s’explique également par le partage de temps
• Lorsqu’il y a plus de tâches à exécuter que de cœurs CPU disponibles, il faut décider quelle tâche exécuter en premier
• Le scheduler du noyau Linux choisit le prochain processus dans la run queue, selon l’algorithme de planification du noyau
• En général, on ne peut pas contrôler directement le scheduler, mais on peut indiquer quels processus sont plus importants
• La niceness, affichée sous NI, est la priorité en espace utilisateur (user-space priority)
  • Sa plage va de -20 à 19
  • -20 correspond à la priorité la plus élevée et 19 à la priorité la plus basse
  • On peut considérer qu’un processus plus nice cède davantage la place à un processus moins nice
• PRI est la priorité en espace noyau (kernel-space priority) utilisée par le noyau Linux
  • Sa plage va de 0 à 139
  • 0~99 correspond au temps réel, 100~139 à la plage destinée aux utilisateurs
• La relation entre la valeur nice et la priorité s’explique par PR = 20 + NI
  • Les valeurs -20~+19 de NI deviennent 0~39 pour PR, qui sont ensuite mappées sur 100~139
• Avant l’exécution, la niceness se définit avec nice -n niceness program
• La niceness d’un processus en cours d’exécution se modifie avec renice -n niceness -p PID
• Les couleurs d’utilisation CPU sont les suivantes
  • Blue : thread de faible priorité, nice > 0
  • Green : thread de priorité normale
  • Red : thread noyau

Indicateurs mémoire : VIRT, RES, SHR, MEM%

• Un processus a l’impression d’être seul en mémoire ; cela est implémenté par la mémoire virtuelle
• Un processus n’accède pas directement à la mémoire physique, mais possède son propre espace d’adressage virtuel
• Le noyau peut traduire les adresses de mémoire virtuelle en mémoire physique, ou en mapper certaines parties sur le disque
• C’est pourquoi un processus peut sembler utiliser plus de mémoire que celle installée dans l’ordinateur
• La mesure de l’utilisation mémoire d’un processus varie selon qu’elle inclut ou non les éléments suivants
  • bibliothèque partagée
  • mémoire mappée sur disque
  • mémoire sortie en swap
• Les couleurs d’utilisation mémoire sont les suivantes
  • Green : mémoire utilisée
  • Blue : buffers
  • Orange : cache

• VIRT/VSZ

  • VIRT correspond à la quantité totale de mémoire virtuelle utilisée par une tâche
  • Elle inclut le code, les données, les bibliothèques partagées, les pages sorties en swap, ainsi que les pages mappées mais non utilisées
  • Même si une application demande 1 Go et n’en utilise que 1 Mo, VIRT peut afficher 1 Go
  • Même si un fichier de 1 Go est mappé avec mmap sans être réellement utilisé, VIRT peut afficher 1 Go
  • Dans la plupart des cas, VIRT n’est pas un chiffre très utile

• RES/RSS

  • RES correspond à la mémoire physique qui n’a pas été sortie en swap, c’est-à-dire la mémoire résidente actuellement présente en mémoire physique
  • RES peut mieux représenter l’utilisation réelle de la mémoire que VIRT, mais a aussi ses limites
  • Elle n’inclut pas la mémoire sortie en swap
  • Une partie de la mémoire peut être partagée avec d’autres processus
  • Si un processus utilise 1 Go de mémoire puis appelle fork(), le RES des deux processus peut apparaître comme 1 Go chacun, mais en réalité seul 1 Go peut être utilisé grâce au copy-on-write de Linux

• SHR

  • SHR correspond à la quantité de mémoire partagée utilisée par une tâche
  • Elle reflète la mémoire qui peut potentiellement être partagée avec d’autres processus
  • L’exemple de programme C montre comment les valeurs VIRT, RES et SHR évoluent au fil des étapes malloc, utilisation partielle de la mémoire, fork, puis écritures mémoire supplémentaires
  • La section de cet exemple mémoire reste marquée TODO

• MEM%

  • MEM% correspond à la proportion de mémoire physique disponible actuellement utilisée par une tâche
  • C’est la valeur de RES divisée par la RAM totale
  • Exemple : si RES vaut 400M et que la RAM est de 8 Go, 400/8192*100 = 4.88%

Processus par défaut d’Ubuntu Server 16.04

• Étude des processus lancés sur Ubuntu Server 16.04.1 LTS x64 d’un droplet Digital Ocean fraîchement créé

• /sbin/init

  • /sbin/init coordonne le reste du processus de démarrage et configure l’environnement utilisateur
  • Il devient le parent ou le grand-parent des processus lancés automatiquement
  • Le résultat de dpkg -S /sbin/init étant systemd-sysv: /sbin/init, il s’agit de systemd sur ce système
  • Le tuer ne produit aucun effet

• /lib/systemd/systemd-journald

  • systemd-journald est un service système qui collecte et stocke les données de journalisation
  • Il crée et maintient un journal structuré et indexé à partir des informations de log reçues de plusieurs sources
  • Il utilise un format de fichier spécial optimisé pour les messages de log, plutôt que de simples fichiers de log en texte brut
  • Consultation avec journalctl
  • journalctl _COMM=sshd
  • journalctl _COMM=sshd -o json-pretty
  • journalctl --since yesterday
  • journalctl -b
  • journalctl -f
  • journalctl --disk-usage
  • journalctl --vacuum-size=1G
  • Il ne semble pas possible de le supprimer ou de le désactiver ; on peut seulement désactiver la journalisation

• /sbin/lvmetad -f

  • lvmetad met en cache les métadonnées LVM afin que les commandes LVM puissent les lire sans scanner le disque
  • Le scan du disque prend du temps et peut perturber les opérations normales du système et du disque
  • LVM peut être vu comme des « partitions dynamiques » permettant de créer, redimensionner et supprimer des volumes logiques pendant que Linux fonctionne
  • Conclusion : il faut probablement le conserver si LVM est utilisé

• /lib/systemd/udevd

  • systemd-udevd écoute les uevents du noyau et exécute, pour chaque événement, les instructions correspondantes des règles udev
  • udev est le gestionnaire de périphériques du noyau Linux et gère principalement les nœuds de périphériques du répertoire /dev
  • Son utilité sur un serveur virtuel n’est pas certaine

• /lib/systemd/timesyncd

  • systemd-timesyncd est un service système qui synchronise l’horloge locale du système avec un serveur NTP distant
  • Il remplace ntpd
  • Dans le système d’exemple, timedatectl status indique yes pour l’heure réseau et la synchronisation NTP
  • Dans la sortie de netstat, seul le port SSH apparaît en écoute ; contrairement à ntpd sur Ubuntu 14.04, il n’ouvre pas plusieurs ports UDP 123

• /usr/sbin/atd -f

  • atd exécute les tâches placées dans une file pour être lancées plus tard
  • at et batch lisent des commandes depuis stdin ou un fichier pour les exécuter ultérieurement
  • Contrairement à cron, qui planifie des exécutions répétées, at s’exécute une seule fois à un moment précis
  • Dans l’exemple, echo "touch /tmp/yolo.txt" | at now + 1 minute crée un fichier une minute plus tard
  • S’il n’est pas utilisé, le supprimer avec sudo apt remove at -y --purge

• /usr/lib/snapd/snapd

  • Snappy Ubuntu Core est présenté comme une déclinaison d’Ubuntu utilisant des mises à jour transactionnelles
  • snap est décrit comme un format de paquet Linux universel permettant à un même paquet binaire de fonctionner sur desktop, serveur, cloud et appareils Linux
  • On peut le comprendre comme un paquet deb simplifié qui regroupe ses dépendances dans un seul snap
  • Comme aucun déploiement ni distribution d’application avec snappy sur serveur n’a été tenté, il est supprimé avec sudo apt remove snapd -y --purge

• /usr/bin/dbus-daemon

  • D-Bus est un mécanisme IPC et RPC entre plusieurs processus s’exécutant simultanément sur la même machine
  • Il est nécessaire pour un environnement de bureau, mais son utilité sur un serveur exécutant une application web est questionnée
  • Après suppression de dbus, timedatectl status échoue avec Failed to create bus connection: No such file or directory
  • Conclusion : mieux vaut donc le conserver

• /lib/systemd/systemd-logind

  • systemd-logind est un service système qui gère les connexions utilisateur

• /usr/sbin/cron -f

  • cron est un daemon qui exécute des commandes planifiées
  • -f signifie mode foreground, c’est-à-dire sans daemonisation
  • Les tâches à exécuter périodiquement peuvent être planifiées avec cron
  • crontab -e
  • Sous Ubuntu, conclusion : on utilise plutôt /etc/cron.hourly, /etc/cron.daily, etc.
  • Les logs peuvent être consultés de la manière suivante
  • grep cron /var/log/syslog
  • journalctl _COMM=cron
  • journalctl _COMM=cron --since="date" --until="date"
  • Il est probable que cron soit conservé
  • S’il n’est pas supprimé, il peut être arrêté et désactivé avec sudo systemctl stop cron, sudo systemctl disable cron
  • apt remove cron peut tenter d’installer postfix, entre autres
  • C’est parce que cron suggère un agent de transport de courrier

• /usr/sbin/rsyslogd -n

  • rsyslogd est un utilitaire système qui prend en charge la journalisation des messages
  • Il remplit les fichiers de log de /var/log/, comme /var/log/auth.log
  • Les fichiers de configuration se trouvent dans /etc/rsyslog.d
  • Il permet de configurer une journalisation centralisée en envoyant les logs vers un serveur distant
  • La commande logger permet de laisser des messages dans /var/log/syslog depuis un script en arrière-plan
  • Même si systemd-journald est déjà présent, rsyslog et le journal ont des caractéristiques différentes, et les utiliser ensemble peut être utile dans certains cas
  • Il est donc conservé pour le moment

• /usr/sbin/acpid

  • acpid est le daemon d’événements ACPI
  • Il est conçu pour notifier les programmes en espace utilisateur des événements ACPI
  • ACPI sert notamment à la découverte et à la configuration des composants matériels, à la gestion de l’alimentation et à la surveillance de l’état
  • Comme aucun suspend/resume n’est prévu sur le serveur virtuel, un essai de suppression a été effectué
  • reboot a réussi, mais après halt, Digital Ocean considérait toujours la machine comme allumée, et il a fallu utiliser Power Off dans l’interface web
  • Conclusion : il vaut donc mieux le conserver

• /usr/bin/lxcfs /var/lib/lxcfs/

  • lxcfs est un système de fichiers FUSE conçu pour les conteneurs LXC
  • Il fournit une vue virtualisée de certains fichiers de /proc et un accès filtré au système de fichiers cgroup de l’hôte
  • Il rend les résultats d’uptime, top, etc. plus « corrects » depuis l’intérieur d’un conteneur
  • Si aucun conteneur LXC n’est utilisé, il peut être supprimé avec sudo apt remove lxcfs -y --purge

• /usr/lib/accountservice/accounts-daemon

  • AccountsService fournit une interface D-Bus et une implémentation pour interroger et manipuler les informations de comptes utilisateur
  • L’implémentation repose sur les commandes usermod(8), useradd(8), userdel(8)

• Ce qui cassera après suppression est laissé à « Time will tell »

• /sbin/mdadm

  • mdadm est un utilitaire Linux qui gère et surveille les périphériques RAID logiciels
  • Le RAID est une méthode qui permet d’utiliser plusieurs disques durs comme s’ils n’en formaient qu’un
  • Le RAID 0 augmente la capacité des disques
  • Les RAID 1, RAID 5, RAID 6 et RAID 10 visent à éviter la perte de données en cas de défaillance d’un disque
  • Il peut être supprimé avec sudo apt remove mdadm -y --purge

• /usr/lib/policykit-1/polkitd --no-debug

  • polkitd est le daemon PolicyKit, et polkit est un framework d’autorisation
  • On peut le comprendre comme une sorte de sudo à granularité fine
  • Il permet d’accorder à un utilisateur non privilégié le droit d’effectuer certaines actions en tant que root
  • Exemple : autoriser le redémarrage sur un Linux desktop
  • Sur un serveur, il est indiqué qu’on peut le supprimer avec sudo apt remove policykit-1 -y --purge
  • Ce qui cassera reste toutefois une question ouverte

• /usr/sbin/sshd -D

  • sshd est le daemon OpenSSH
  • L’option -D empêche le détachement et le passage en daemon, ce qui facilite la supervision

• /sbin/iscsid

  • iscsid est un daemon en arrière-plan qui fonctionne selon la configuration iSCSI et gère les connexions
  • iSCSI est un standard de réseau de stockage basé sur IP : il transmet des commandes SCSI sur un réseau IP afin d’utiliser un stockage distant comme un disque local
  • Il peut être supprimé avec sudo apt remove open-iscsi -y --purge

• /sbin/agetty --noclear tty1 linux

  • agetty est un getty Linux alternatif
  • getty gère les terminaux physiques ou virtuels ; lorsqu’une connexion est détectée, il affiche une invite de nom d’utilisateur puis exécute le programme login
  • Sur Digital Ocean, il est possible d’interagir avec ce terminal dans le navigateur via Console dans les détails du droplet
  • Après suppression des fichiers liés à [e-mail] puis redémarrage, la connexion SSH fonctionnait encore, mais il était impossible de se connecter via la console web de Digital Ocean

• Sessions SSH, bash, htop

  • sshd: root@pts/0 signifie que la session SSH de l’utilisateur root est configurée sur le pseudoterminal pts/0
  • Un pseudoterminal émule un véritable terminal texte
  • bash est le shell utilisé
  • Lorsqu’un tiret le précède, comme dans -bash, cela signifie qu’il a été lancé comme login shell
  • Un shell dont le premier caractère de l’argument zéro est -, ou qui est lancé avec l’option --login, est un login shell
  • Dans ce cas, il lit un ensemble différent de fichiers de configuration
  • htop est le visualiseur interactif de processus en cours d’exécution dans la capture d’écran

Expérience de suppression de services

• La liste des suppressions standard est la suivante
  • sudo apt remove lvm2 -y --purge
  • sudo apt remove at -y --purge
  • sudo apt remove snapd -y --purge
  • sudo apt remove lxcfs -y --purge
  • sudo apt remove mdadm -y --purge
  • sudo apt remove open-iscsi -y --purge
  • sudo apt remove accountsservice -y --purge
  • sudo apt remove policykit-1 -y --purge
• L’édition Extreme inclut les opérations suivantes
  • sudo apt remove dbus -y --purge
  • sudo apt remove rsyslog -y --purge
  • sudo apt remove acpid -y --purge
  • sudo systemctl stop cron && sudo systemctl disable cron
  • sudo rm /etc/systemd/system/getty.target.wants/[e-mail]
  • sudo rm /lib/systemd/system/getty@.service
• La configuration nginx, PHP7 et MySQL suivant les instructions de unattended installation of WordPress on Ubuntu Server fonctionne

Annexe : outils d’investigation et comportement du shell

• Trouver le code source

  • Quand strace ne suffit pas, on peut consulter le code source
  • On trouve l’emplacement du binaire avec which uptime, puis le package Ubuntu avec dpkg -S /usr/bin/uptime
  • Dans l’exemple, uptime appartient au package procps
  • On peut rechercher le package sur packages.ubuntu.com et trouver le lien vers le dépôt source

• Descripteurs de fichier et redirection

  • Pour rediriger stderr vers stdout, on utilise 2>&1
  • echo something > file écrit stdout dans file, et équivaut à echo something 1> file
  • echo something 2> file écrit stderr dans file
  • echo something 2>1 signifie rediriger stderr vers un fichier nommé 1
  • Dans 2>&1, avec le &, 1 n’est pas un nom de fichier mais un identifiant de flux

• Problème de couleurs dans PuTTY

  • Si des éléments de htop semblent manquer dans PuTTY, cela peut se résoudre dans les réglages Window → Colours
  • Clic droit sur la barre de titre
  • Change settings...
  • Window → Colours
  • Sélectionner le bouton radio Both
  • Apply

• Un shell simple écrit en C

  • Un shell simple écrit en C illustre l’utilisation des appels système fork, exec et wait
  • Si l’entrée est exit, il se termine comme built-in du shell
  • Les autres commandes sont exécutées avec execlp dans le processus enfant après fork, tandis que le parent attend l’état de fin avec waitpid
  • Les exemples d’exécution de date, true et false affichent chacun le code de sortie du processus enfant
  • La raison pour laquelle le message de fin d’un processus en arrière-plan comme sleep 1 & n’apparaît qu’après avoir appuyé sur Entrée est que le shell attend une entrée et vérifie l’état des processus en arrière-plan au moment de la saisie d’une commande

Points restant à étudier et historique des corrections

• Les points que l’auteur souhaite approfondir sont notamment les sous-états des états de processus, les threads noyau, /dev/pts, la mémoire CODE·DATA·SWAP, la durée d’un time slice, l’algorithme du scheduler Linux, le core pinning, les pages de manuel, les couleurs des barres CPU/mémoire, la limite des process ID et les fork bombs, lsof, ionice, schedtool, etc.
• Les principales corrections et mises à jour incluent les points suivants
  • Le temps idle de /proc/uptime est la somme de tous les cœurs
  • Les printf parent/enfant de l’exemple C de zombie ont été corrigés
  • Il a été ajouté que apt remove cron tente d’installer postfix à cause d’une dépendance MTA
  • id peut charger des informations depuis d’autres sources que /etc/passwd via /etc/nsswitch.conf
  • Une explication du format du hash de mot de passe dans /etc/shadow a été ajoutée
  • /etc/sudoers doit être modifié prudemment avec visudo
  • Une explication de MEM% a été ajoutée
  • La section sur la load average a été réécrite
  • Le signal par défaut de kill 1234 a été corrigé : ce n’est pas INT mais TERM
  • Une explication des barres de couleur CPU et mémoire a été ajoutée

[GN⁺]

Avis sur Hacker News

• Je suis passé récemment à btop : son interface est moderne juste comme il faut, utile et suffisamment riche en informations.
  Comme d’autres l’ont dit, il semble aussi afficher la consommation électrique (en watts), ainsi que des informations réseau, GPU et disque.
  https://github.com/aristocratos/btop

  • btop est bien, mais il a aussi des limites : pas de statistiques zram/zswap (htop ne prend en charge que zram), pas de ventilation détaillée des statistiques ZFS, et pas encore de prise en charge des GPU Arc.
    Comme on ne peut pas désactiver les barres d’utilisation disque, le graphe de débit I/O paraît très écrasé si la fenêtre de console n’est pas très grande.
  • J’utilise btop depuis longtemps, et ce qui me manque se résume à peu près à une colonne des ports à côté des autres colonnes.
    Les graphes CPU/GPU prennent trop de place, et j’aimerais globalement que la table des fichiers ouverts occupe davantage d’espace.
  • J’utilise encore parfois Alpine comme image de base de conteneur, et btop semble ne pas prendre en charge musl, donc il est exclu.
  • Je suis un adepte de btop, au point que sur mon nouveau MacBook il a même remplacé iStatMenu.

• Il y a deux réglages que je change à chaque fois que j’utilise htop, et la différence est énorme.
  D’abord, je désactive les threads utilisateur. La plupart du temps, ils ne font qu’encombrer l’affichage de htop et apportent très peu d’informations utiles.
  Ensuite, j’active la vue en arbre des processus. Savoir d’où un processus a été lancé est souvent plus important que le reste, et cela permet aussi de suivre plus facilement des processus de compilation qui traitent beaucoup de fichiers et consomment du CPU.
  Personnellement, je pense que ces deux comportements devraient être les valeurs par défaut de htop.

  • La vue en arbre des processus est pratique, mais une fois activée, la mise à jour dynamique et le tri de la liste des processus s’arrêtent, ce qui est dommage.

• Je suis content de voir l’explication selon laquelle la mémoire virtuelle est un indicateur peu fiable. Le Gestionnaire des tâches de Windows l’affiche par défaut de cette façon, et c’est très mauvais.
  La taille de l’ensemble résident (RSS) est l’indicateur le plus fiable, tandis que les autres valeurs peuvent être artificiellement gonflées par des fichiers mappés en mémoire qui ne posent pas réellement problème.
  Par exemple, même si l’on mappe en mémoire un fichier de logs de 2 Go, seules les parties lues sont chargées en pages ; cela ne signifie donc pas que de la mémoire réelle est utilisée. Pourtant, l’utilisateur regarde le processus et se demande : « pourquoi cette appli utilise-t-elle autant de mémoire ? »
  Chrome a lui aussi subi ce problème pendant un temps et a réduit son usage des fichiers mappés en mémoire, non pas parce que ceux-ci étaient mauvais, mais parce que les utilisateurs réagissaient de façon excessive à une valeur qui ne représentait pas l’utilisation réelle de mémoire physique.
  On trouve même sur le Web des guides conseillant de juger l’utilisation mémoire à partir de la quantité de mémoire virtuelle allouée ; au moins, cet article met correctement le doigt sur ce point.

  • En réalité, la taille proportionnelle de l’ensemble résident (PSS) est plus précise que RSS.
    Référence : https://en.wikipedia.org/wiki/Proportional_set_size
  • Quand on utilise des fichiers mappés en mémoire, les pages mises en cache sont incluses dans la taille de l’ensemble résident du processus.
    Avec des I/O classiques sur fichier, elles ne le sont pas. Sur les clusters HPC qui surveillent l’usage mémoire de chaque tâche et la tuent lorsqu’elle dépasse la quantité demandée, cela produit des résultats assez intéressants.
  • La taille de l’ensemble résident n’est pas la quantité de mémoire que le processus veut, mais la quantité que le système d’exploitation a décidé de lui accorder.
    Dès qu’une pression mémoire apparaît, elle cesse d’être représentative. J’ai vu plusieurs mauvaises décisions dues à ce malentendu, et il m’est même arrivé de retirer cette valeur d’un graphique pour éviter qu’un collègue n’en tire la conclusion inverse.
  • Pour être précis, le Gestionnaire des tâches de Windows utilise par défaut le Private Working Set pour l’utilisation mémoire d’un processus, et n’inclut pas les pages partagées avec d’autres processus, comme les bibliothèques ou les fichiers mappés en mémoire.
    Comme son nom l’indique, il ne montre que la partie mappée vers de la mémoire physique allouée de manière privée à chaque processus, ce qui est plus proche du Resident Set d’Unix.
    Vous faisiez sans doute référence à l’utilisation mémoire dans l’onglet Performances, mais comme cela peut être confondu avec tous les indicateurs d’utilisation mémoire, je fais la distinction.

• Dans top, utiliser le caractère > trie par utilisation mémoire.
  Je m’en sers parfois pour comprendre pourquoi un hôte ralentit, et on peut aussi voir swapd accaparer le CPU.

  • Pour la mémoire, je préfère utiliser M majuscule, et pour le CPU P majuscule.

• Lire ce genre d’article me rappelle que, même après plus de 20 ans d’utilisation quotidienne de Linux, je n’exploite encore qu’une partie de son potentiel. Bon article.

• J’ai l’impression que HN se remet à aller mieux.
  J’espère que ce n’était pas simplement la période du fantôme ambulant de HN.

  • Il y a trois articles liés à l’IA en première page, mais l’un d’eux critique du contenu généré de mauvaise qualité, donc je garde espoir.
  • On dirait que ça se rétablit en revenant aux articles d’avant le slop, il y a sept ans.

• Pour ceux qui ne connaissent pas nmon, ça vaut aussi le coup d’y jeter un œil.
  Appuyez sur h pour afficher la liste des moniteurs disponibles, appuyez de nouveau pour la masquer, et quittez avec q.
  https://nmon.sourceforge.io/pmwiki.php
  En particulier, le débit disque et les I/O visibles avec les touches d et D sont assez utiles.

  • Je l’ai découvert sur les machines AIX au travail, et cela me rappelle aussi topas.
  • C’est un outil très utile, donc je l’installe sur toutes les machines que je peux contrôler.
    Le graphe large d’utilisation CPU gère facilement un grand nombre de cœurs, ce qui est appréciable.

• Pour un usage différent des outils de type *top, j’en suis venu à préférer les rapports différentiels sobres façon ps et les rapports système globaux comme vmstat.
  De cette façon, tout reste dans le tampon de défilement du terminal : https://github.com/c-blake/procs
  C’est écrit en Nim, un langage inhabituellement efficace et expressif.

• J’ai cet article en favori depuis 2016 et j’y suis revenu plusieurs fois au fil des années.