Processus, services et logs

Les processus

Un processus est un programme en cours d'exécution. Il peut donc y avoir simultanément plusieurs processus du même programme en exécution en mémoire. Le noyau Linux lance, gère les processus et contrôle leurs échanges avec les périphériques. 

Le premier processus, ancêtre de tous les autres, est init. Tous les autres sont créés par un processus parent et appartiennent à un utilisateur. Ainsi en règle générale, à chaque nouvelle commande, le système lance un nouveau processus.

Chaque processus est identifié par un numéro unique, son PID qu'il peut être important de connaître 

Pour lancer un processus en tâche de fond (en arrière-plan), faire suivre la commande du symbole &, cela ordonne au processus parent de "reprendre la main", sans attendre la fin du processus "fils".

Ainsi, dans une console où on a lancé par exemple synaptic &, on dispose toujours du processus shell pour lancer d'autres commandes. 

Pour connaître tous les processus en cours de fonctionnement 

• ps : liste les processus actifs lancés dans la console courante. 

• ps aux : affiche la liste de tous les processus, avec leur numéro PID, le terminal tty où ils ont été lancés (sinon ?). Voici la liste des colonnes du tableau obtenu . 

  •  "USER" à quel utilisateur appartient le processus. 

  •  "PID" est le numéro qui identifie le processus 

  •  "%CPU" en % les ressources du microprocesseur utilisées par le processus. 

  •  "%MEM" en % les ressources en mémoire vive utilisées par le processus. 

  •  "RSS"  mémoire réellement utilisée en ko par le processus. 

  •  "START" l'heure à laquelle le processus a été lancé. 

• ps aux | less : pour contrôler le défilement 

• ps aux | grep httpd : pour n'afficher que les lignes concernant le processus cherché. 

• pstree permet de visualiser la filiation des processus sous forme arborescente.
  

• pidof httpd, pour connaître la liste des PID des processus d'un programme 

• Le numéro PID d'un service est souvent stocké dans un fichier qui porte son nom, dans le répertoire /var/run 

En plus des processus exécutés dans une session de travail en avant-plan (foreground), mode habituel de fonctionnement et ceux qui sont lancés en tâche de fond, il existe des processus dits détachés qui ne sont exécutés dans aucune console (ps affiche alors un ? au lieu du nom de console tty-).

Les processus détachés qui sont les exécutions de services du système (en particulier services réseaux) sont appelés daemons, francisés en "démons".L'administrateur n'a pas directement la main sur un démon (où taper Crtl-C pour stopper le programme ?). Il doit lui envoyer un signal pour le supprimer ou agir sur sa configuration. Cela s'effectue par la commande kill.

Pour modifier l'état d'un processus

On peut gérer les processus en leur envoyant des signaux par l'intermédiaire des commandes kill et killall, suivant que l'on connaisse le numéro PID du processus, ou bien son nom.

Voici les principales actions que l'administrateur peut être amené à utiliser 

• kill -15 PID : demande normale d'arrêt au processus, il peut refuser (-15 peut être remplacé par SIGTERM) 

• killall -9 httpd : suppression plus radicale, en cas de processus récalcitrant ! (Le signal -9 par exemple s'appelle SIGKILL)

• kill $(pidof ypserv) : supprime le processus serveur NIS, dont le pid est obtenu le résultat de la commande pidof 

• killall -HUP httpd : ordonne au processus de relire son fichier de configuration, ce qui évite de le relancer. 

• kill -l : pour connaitre la liste des signaux qu'on peut passer à kill. 

Pour connaitre les ressources utilisées par les processus, la commande top affiche une page d'information, périodiquement mise à jour (taper q pour quitter), pour gérer les processus et être informé de la charge de travail du CPU et de l'utilisation mémoire.

Démarrage et gestion des services

Cinq phases de démarrage du système

Le processus de démarrage est quasiment le même quelque soit la distribution Linux. Il peut toutefois exister des petites différences en particulier dans le déroulement de la phase 5 ci-dessous. 

2. Chargement du BIOS de la carte mère (inventaire des périphériques)

3. Initialisation des périphériques

4. Lecture du secteur de démarrage du disque d'amorçage : Le BIOS charge en mémoire le MBR (Master Boot Record) : 1er secteur de la 1ère piste du 1er disque dur, 512 octets). Si un chargeur de boot (LILO, Grub ...) est présent, il est exécuté et va attendre plus ou moins longtemps qu'on lui dise quoi faire.

5. Chargement du noyau en mémoire et exécution. Le noyau va charger tous les périphériques pour lequel il a été configuré.

6. 5. Exécution de /sbin/init : Init prend en charge le reste de la procédure. Il va se charger de plusieurs tâches :

   1. montage et vérification du système de fichiers racine

   2. montage des différents systèmes de fichiers

   3. activation du swap

   4. initialisation des services
      

   5. connexion

Les scripts de démarrage utilisés

/etc/inittab est le premier script exécuté dans la phase 5.

Inittab va définir le niveau d'exécution (runlevel), c'est à dire les services et le mode de lancement de la machine. La plupart des distributions utilisent le processus de démarrage System V qui définit 7 niveaux d'exécution :

  0 :   machine à l'arrêt l'alimentation peut être   coupée.
  1 :   machine mono-utilisateur.
  2, 3, 4 : ne se distinguent pas sous Debian : mode multi-utilisateurs complet
  5 :   idem 2,3 et 4 + lancement de Xwindow (serveur graphique) au démarrage.
  6 :   arrêt et redémarrage du système (la commande reboot lance le niveau 6).

La ligne qui suit définit le niveau de fonctionnement par défaut au démarrage (Default runlevel), ici le niveau 2 par défaut sous débian :
id:2:initdefault:
Donc pour changer de niveau par défaut, il suffit tout simplement de changer ce numéro !

Ou, pour basculer en mode console, d'un niveau à un autre il suffit de taper init N (où N représente le runlevel souhaité).

si::sysinit:/etc/init.d/rcS

il y a ensuite exécution du script rcS qui contient une boucle d'exécution de tous les scripts du répertoire /etc/rcS.d/  : 

cela assure la configuration du système : initialisation du PATH, activation swap, montage des systèmes de fichiers, activation du réseau, de la résolution des noms, etc .. 

Puis, exécution du script etc/rc.d/rc avec le niveau en paramètre : lancement des divers services du niveau choisi, ici 2.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2    → ceci lance tous les liens symboliques (théoriquement des scripts) du rép /etc/rc2.d
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

Comment ça marche ?

/etc/init.d/rc est lancé avec comme paramètre le niveau d'exécution. Les scripts du répertoire /etc/rcN.d, où N désigne le niveau d'exécution sont alors exécutés. En fait les répertoires rcN.d contiennent des liens symboliques vers les scripts du répertoire /etc/init.d/. Ceci évite de dupliquer les fichiers sur les différents répertoires rcN.d 

Ces fichiers de scripts permettent d'arrêter ou de lancer des démons. Les noms de ces fichiers commencent par K lorsqu'on veut arrêter un démon et par S lorsqu'on veut le lancer.

Comme il existe des dépendances entre différents démons, les noms comportent un numéro d'ordre.

Par exemple :

/etc/rc2.d/S01usb fait référence au script /etc/init.d/usb et sera lancé en premier.
/etc/rc2.d/S91apache qui fait référence au script /etc/init.d/apache sera lancé avec un numéro d'ordre 91.

La structure de ces fichiers de script est commune mais rien de vous empêche de créer vos propres scripts...

À vous de modifier éventuellement le contenu de votre répertoire « de lancement », suivant le niveau que vous avez choisit dans inittab.

Suite du fichier :

# Things to run in every runlevel.
ud::once:/sbin/update

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
...
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon

Les 6 lignes sous « # Run gettys in standard runlevels » définissent le nombre de consoles virtuelles. On passe d'une console  à l'autre par les combinaisons de touches CTRL+ALT+F1 à F6 .

Les services

Gestion des services dans init.d

Tous les scripts de lancement d'un service comme un serveur web, un serveur ftp, etc... se trouvent donc dans le répertoire /etc/init.d que ces services soient lancés au démarrage ou non.

Exemple de service disponible : 

adsl	internet	smb apache
alsa	iptables	snortd php7
squid	crond	networking

• Pour lancer un service, il faut donc se positionner dans le répertoire /etc/init.d et taper nom_service start
• Pour arrêter un service : /etc/init.d/nom_service stop
• Pour redémarrer un service : /etc/init.d/nom_service restart
• Pour relire les fichiers de configuration d'un service : /etc/init.d/nom_service reload

Gérez les services de votre système avec systemd

systemd est le système d’initialisation adopté par toutes les dernières distributions Linux. Tout comme Upstart, il est basé sur des  événements, ce qui rend son fonctionnement souple et dynamique. Il permet un démarrage en parallèle des processus avec une gestion très fine des dépendances. Il peut même redémarrer un processus qui se serait arrêté par erreur, gérer la planification des tâches, les logs système, les périphériques et plus encore. Dans ce chapitre, vous allez apprendre à utiliser les principales fonctions de systemd relatives à la gestion des processus.

Gérez le démarrage et l’arrêt de vos processus

systemd est fourni avec la commande systemctl qui permet de gérer les “unités” (units en anglais). Pour systemd, une unité est un terme générique qui désigne tout objet sur lequel il va pouvoir agir. Les unités peuvent être de différents types : service, montage, périphérique, etc. Les daemons sont de type “service”. Vous appréhenderez d’autres types d’unités dans la suite de ce chapitre.

Par exemple, vous aviez démarré Samba par la commande : sudo systemctl start smbd

De la même façon, vous pouvez arrêter le serveur smbd par la commande : sudo systemctl stop smbd

D’autres actions possibles sont :

• restart pour stop puis start en une seule commande
• reload pour mettre à jour la configuration sans couper le service (pour les services qui en sont capables)
• status pour connaître l’état de votre service
• enable pour lancer le service au démarrage
• disable pour ne pas lancer le service au démarrage
• Si vous lancez la commande systemctl sans argument, ça équivaut à lancer la commande suivante qui liste toutes les unités “actives” : systemctl list-units

Il y a beaucoup d’unités de toutes sortes. Si vous chercher le nom exact d’un service à lancer, vous pouvez filtrer cette liste pour n’afficher que les unités de type “service” : systemctl list-units --type=service

Toutes les unités se terminent par “.service”. C’est parce que la configuration de chaque unité est définie dans un fichier dont le nom est du type NOM_DE_L_UNITE.TYPE_DE_L_UNITE. 

Presque tous les fichiers des unités sont dans /lib/systemd/system mais en fait vous n’avez pas besoin de connaître l’emplacement réel des fichiers car la commande systemctl permet de lire et d’éditer les fichiers d’unité. Je ne vais pas rentrer dans le détail de la syntaxe de ces fichiers mais sachez que vous pouvez afficher le contenu du fichier unité smbd.service par la commande : systemctl cat smbd.service

Vous pouvez également éditer cette configuration par la commande : systemctl edit smbd.service

Cette commande ne va pas réellement modifier le fichier original mais plutôt créer un fichier de “surcharge” qui aura la priorité sur le fichier original. L’avantage est de pouvoir revenir à la configuration par défaut en cas de besoin en supprimant cette surcharge

Si vous savez ce que vous faites et voulez éditer directement le fichier de configuration, utilisez systemctl edit - - full smbd.service

Quand vous modifiez un fichier de configuration de service, ne pas oublier de reload le service