La commande ps permet d’afficher les processus actifs. Sans option, elle fournit – pour chaque processus utilisant l’identité de l’utilisateur et rattaché à un terminal – l’identifiant du processus (pid), le terminal associé (tname), le temps CPU cumulé consommé (time) et le nom du binaire utilisé pour lancer le processus (ucmd). Cette commande permet d’afficher l’ensemble des informations relatives aux processus. Elle est particulièrement riche (la page de manuel compte 1151 lignes).

Les processus, outre leur filiation (PID et PPID), sont réunis par groupe afin de faciliter leur gestion : suspension, interruption, annulation, pause, continuation, … Cette gestion s’effectue par l’envoi d’un signal du noyau au processus. La commande kill permet d’envoyer manuellement un signal donné à un processus ou groupe de processus donné.

Cf man 7 signal !

Tout processus en cours dans un terminal peut être interrompu avec la combinaison de touches C-z.

Ce processus est alors suspendu et le prompt de l’interpréteur de commandes est proposé à l’utilisateur.

Les commandes suivantes permettent de gérer ces processus suspendus ou placés en tâche de fond :

jobs

liste les processus suspendus et en tâche de fond

fg

éventuellement suivi du numéro du processus (pas le PID !) rappelle le processus en avant-plan. Il redevient actif.

bg

éventuellement suivi du numéro du processus réactive un processus suspendu, mais en tâche de fond.

Une commande lancée avec le suffixe & est lancée en tâche de fond.

Le fichier de configuration d’init est /etc/inittab définit le niveau de fonctionnement attendu du système (runlevel), situé entre 0 et 6 (0 : arrêt, 1 : monoutilisateur, 2 à 5 : personnalisable, 6 : redémarrage) auquel sont associés des programmes et services à démarrer et arrêter. À chaque runlevel correspond un répertoire /etc/rcX.d qui contient des liens symboliques. Le nom des fichiers indique l’ordre d’exécution et l’action à réaliser (S : start, K : kill). Exemples : /etc/rc3.d/S20apache et /etc/rc6.d/K05apache. Les cibles des liens sont des scripts situés dans /etc/init.d.

Aujourd’hui la plupart des distributions (dans l’ordre chronologique : Gentoo, Debian, Archlinux, openSuse, Mandriva, Fedora) ont migré vers systemd qui permet une gestion plus fine des dépendances entre les services, un démarrage en parallèle, une utilisation moindre des scripts et la prise en charge des groupes de contrôle (cgroups).

Là où le processus init de system V utilisait un démarrage séquentiel des services, systemd assure un démarrage parallèle des services, tout en gérant les dépendances à un niveau très fin. Ainsi si le service A requiert que le service B ait ouvert une socket, systemd sera capable de démarrer A dès que la socket est disponible, potentiellement avant la fin du démarrage de B.

Les scripts utilisés par init sont situés dans le répertoire /etc/init.d et permettent d’arrêter ou démarrer manuellement les services. La commande service, si elle est présente, permet de réaliser ces mêmes opérations.

systemd est piloté par la commande systemctl. Les services sont gérés par systemd sous la forme d’unité de type… service. Il existe d’autres types d’unités (target, mount, automount, device, slice, path, scope, socket, timer, snapshot, swap).

La commande systemctl -t service list-units permet d’afficher les services connus.

La commande systemctl start <nom_du_service> permet de démarrer le service, systemctl status <nom_du_service> d’afficher son état (et plein d’autres informations utiles), systemctl enable <nom_du_service> d’activer le démarrage automatique du service. NB : la commande service est réécrite pour utiliser systemctl :

[root@olm ~]# service sshd status
Redirecting to /bin/systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-10-06 03:45:54 EDT; 1min 21s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 853 (sshd)
    Tasks: 1 (limit: 4940)
   Memory: 3.8M
   CGroup: /system.slice/sshd.service
           └─853 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc -oMACs=hmac-sha2-256-etm>

oct. 06 03:45:54 olm.lpasrsi.net systemd[1]: Starting OpenSSH server daemon...
oct. 06 03:45:54 olm.lpasrsi.net sshd[853]: Server listening on 0.0.0.0 port 22.
oct. 06 03:45:54 olm.lpasrsi.net sshd[853]: Server listening on :: port 22.
oct. 06 03:45:54 olm.lpasrsi.net systemd[1]: Started OpenSSH server daemon.
oct. 06 03:46:49 olm.lpasrsi.net sshd[4991]: Accepted password for root from 10.192.96.12 port 42880 ssh2
oct. 06 03:46:49 olm.lpasrsi.net sshd[4991]: pam_unix(sshd:session): session opened for user root by (uid=0)

Un autre type d’unité important est target. La cible par défaut, visée au démarrage du système est généralement un lien symbolique. La commande systemctl show -p Wants -p Requires <target> permet d’afficher les besoins et pré-requis d’une cible.

[root@olm ~]# ls -l /etc/systemd/system/default.target 
lrwxrwxrwx. 1 root root 41  6 oct.  03:43 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target
[root@olm ~]# ls -1 /usr/lib/systemd/system/multi-user.target.wants/
dbus.service
getty.target
systemd-ask-password-wall.path
systemd-logind.service
systemd-update-utmp-runlevel.service
systemd-user-sessions.service

De nombreux autres concepts et commandes étendent la portée de systemd (journalctl, systemd-cgls, systemd-cgtop)

[root@olm ~]# journalctl -u sshd
-- Logs begin at Wed 2021-10-06 03:45:48 EDT, end at Wed 2021-10-06 03:46:49 EDT. --
oct. 06 03:45:54 olm.lpasrsi.net systemd[1]: Starting OpenSSH server daemon...
oct. 06 03:45:54 olm.lpasrsi.net sshd[853]: Server listening on 0.0.0.0 port 22.
oct. 06 03:45:54 olm.lpasrsi.net sshd[853]: Server listening on :: port 22.
oct. 06 03:45:54 olm.lpasrsi.net systemd[1]: Started OpenSSH server daemon.
oct. 06 03:46:49 olm.lpasrsi.net sshd[4991]: Accepted password for root from 10.192.96.12 port 42880 ssh2
oct. 06 03:46:49 olm.lpasrsi.net sshd[4991]: pam_unix(sshd:session): session opened for user root by (uid=0)
[root@olm ~]# systemd-cgtop --order=cpu --iterations=1
Control Group                            Tasks   %CPU   Memory  Input/s Output/s
/                                          104      -   393.0M        -        -
/init.scope                                  1      -    44.1M        -        -
/system.slice                               31      -   258.9M        -        -
/system.slice/NetworkManager.service         3      -     7.6M        -        -
/system.slice/auditd.service                 2      -     3.0M        -        -

Le gestionnaire de paquetages des distributions de la lignée Redhat est yum (Yellowdog Updater Modified). C’est une surcouche de l’outil de gestion de paquetage unitaire rpm qui permet de gérer :

• plusieurs sources de paquetages,
• la mise à jour des listes de paquetages fournis par les sources (yum check-update),
• la gestion de la liste globale des paquetages (yum search ou yum provides par exemple),
• les dépendances entre paquetages,
• le téléchargement des paquetages,
• l’installation de nouveaux paquetages (yum install),
• la mise à jour des paquetages eux-même (yum update),
• la mise à jour de l’ensemble du système (yum upgrade).

On veillera à configurer le proxy si nécessaire :

[root@olm ~]# cat >> /etc/yum.conf 
proxy=http://192.168.144.1:3128

Tout système Linux enregistre son activité et celle des processus fonctionnant en tâche de fond dans des journaux (log). Ceux-ci sont disponibles sous forme de simples fichiers dans le répertoire /var/log.

Un processus dédié à la journalisation, appelé démon de journalisation système (le plus souvent syslogd) est chargé de recevoir les enregistrements à journaliser. La cible d’un enregistrement est déterminée par la configuration du démon.

La journalisation des événements est une technique de sécurité majeure. Elle permet d’effectuer des analyses diverses, en temps réel ou a posteriori, en corrélant les journaux avec d’autres événements. La mise en œuvre d’une centralisation de la journalisation permet d’accéder à des niveaux fonctionnels et de sécurité optimaux.

Sur un système enregistrant les événements dans des fichiers, la connaissance des commandes de recherche et de manipulation de texte et de fichiers texte est essentiel pour l’exploitation des journaux : grep et tail principalement ; voire cut, awk, ou – mieux encore – perl.