Nous commencerons cet article par une révision globale et brève de ce qui se passe depuis le moment où vous appuyez sur le bouton Power pour allumer votre serveur RHEL 7 jusqu’à ce que vous soyez présenté à l’écran de connexion dans une interface en ligne de commande.
Veuillez noter que :
1. les mêmes principes de base s’appliquent, avec peut-être des modifications mineures, à d’autres distributions Linux également, et
2. la description suivante n’a pas pour but de représenter une explication exhaustive du processus de démarrage, mais seulement les principes fondamentaux.
Processus de démarrage de Linux
1. Le POST (Power On Self Test) initialise et effectue des vérifications matérielles.
2. Lorsque le POST est terminé, le contrôle du système est transféré au chargeur d’amorçage de première étape, qui est stocké soit sur le secteur d’amorçage de l’un des disques durs (pour les anciens systèmes utilisant BIOS et MBR), soit sur une partition (U)EFI dédiée.
3. Le chargeur d’amorçage de première étape charge ensuite le chargeur d’amorçage de deuxième étape, le plus souvent GRUB (GRand Unified Boot Loader), qui réside à l’intérieur de /boot, lequel charge ensuite le noyau et le système de fichiers initial basé sur RAM (également connu sous le nom de initramfs, qui contient des programmes et des fichiers binaires qui effectuent les actions nécessaires pour monter finalement le système de fichiers racine réel).
4. Nous sommes présentés à un écran de démarrage qui nous permet de choisir un système d’exploitation et un noyau à démarrer :
5. Le noyau configure le matériel attaché au système et une fois que le système de fichiers racine a été monté, lance le processus avec l’ID de processus 1, qui à son tour initialisera d’autres processus et nous présentera un invite de connexion.
Note: Si nous souhaitons le faire ultérieurement, nous pouvons examiner les spécificités de ce processus en utilisant la commande dmesg et en filtrant sa sortie à l’aide des outils que nous avons expliqués dans les articles précédents de cette série.
Dans l’exemple ci-dessus, nous avons utilisé la célèbre commande ps pour afficher une liste des processus actuels dont le processus parent (ou en d’autres termes, le processus qui les a démarrés) est systemd (le gestionnaire de système et de services vers lequel la plupart des distributions Linux modernes ont basculé) lors du démarrage du système:
# ps -o ppid,pid,uname,comm --ppid=1
N’oubliez pas que le drapeau -o (abrégé de –format) vous permet de présenter la sortie de ps dans un format personnalisé selon vos besoins en utilisant les mots-clés spécifiés dans la section SPÉCIFICATEURS DE FORMAT STANDARD dans man ps.
Un autre cas dans lequel vous voudrez définir la sortie de ps plutôt que d’opter pour la valeur par défaut est lorsque vous avez besoin de trouver les processus qui causent une charge CPU et / ou mémoire significative, et de les trier en conséquence:
# ps aux --sort=+pcpu # Sort by %CPU (ascending) # ps aux --sort=-pcpu # Sort by %CPU (descending) # ps aux --sort=+pmem # Sort by %MEM (ascending) # ps aux --sort=-pmem # Sort by %MEM (descending) # ps aux --sort=+pcpu,-pmem # Combine sort by %CPU (ascending) and %MEM (descending)
Une introduction à SystemD
Peu de décisions dans le monde Linux ont causé plus de controverses que l’adoption de systemd par les principales distributions Linux. Les partisans de Systemd citent comme principaux avantages les faits suivants :
Lire aussi : L’histoire derrière « init » et « systemd »
1. Systemd permet un traitement plus parallèle lors du démarrage du système (par opposition à l’ancien SysVinit, qui tend toujours à être plus lent car il lance les processus un par un, vérifie si l’un dépend de l’autre, puis attend le lancement des démons pour que d’autres services puissent démarrer), et
2. Il fonctionne comme une gestion dynamique des ressources dans un système en cours d’exécution. Ainsi, les services sont démarrés lorsqu’ils sont nécessaires (pour éviter de consommer des ressources système s’ils ne sont pas utilisés) au lieu d’être lancés sans raison valable au démarrage.
3. Compatibilité ascendante avec les scripts SysVinit.
Systemd est contrôlé par l’utilitaire systemctl. Si vous venez d’un environnement SysVinit, il y a de fortes chances que vous soyez familier avec :
- l’outil service, qui – dans ces anciens systèmes – était utilisé pour gérer les scripts SysVinit, et
- l’utilitaire chkconfig, qui servait à mettre à jour et à interroger les informations sur les niveaux d’exécution des services système.
- arrêt, que vous avez dû utiliser plusieurs fois pour redémarrer ou arrêter un système en cours d’exécution.
Le tableau suivant montre les similitudes entre l’utilisation de ces outils hérités et systemctl:
| Legacy tool | Systemctl equivalent | Description |
| service name start | systemctl start name | Start name (where name is a service) |
| service name stop | systemctl stop name | Stop name |
| service name condrestart | systemctl try-restart name | Restarts name (if it’s already running) |
| service name restart | systemctl restart name | Restarts name |
| service name reload | systemctl reload name | Reloads the configuration for name |
| service name status | systemctl status name | Displays the current status of name |
| service –status-all | systemctl | Displays the status of all current services |
| chkconfig name on | systemctl enable name | Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory. |
| chkconfig name off | systemctl disable name | Disables name to run on startup as specified in the unit file (the file to which the symlink points) |
| chkconfig –list name | systemctl is-enabled name | Verify whether name (a specific service) is currently enabled |
| chkconfig –list | systemctl –type=service | Displays all services and tells whether they are enabled or disabled |
| shutdown -h now | systemctl poweroff | Power-off the machine (halt) |
| shutdown -r now | systemctl reboot | Reboot the system |
Systemd a également introduit les concepts d’unités (qui peuvent être soit un service, un point de montage, un périphérique ou un socket réseau) et de cibles (qui permet à systemd de démarrer plusieurs processus liés en même temps, et peut être considéré – bien que non équivalent – comme l’équivalent des niveaux d’exécution dans les systèmes basés sur SysVinit.
Résumé
D’autres tâches liées à la gestion des processus comprennent, mais ne se limitent pas à, la capacité de :
1. Ajuster la priorité d’exécution en ce qui concerne l’utilisation des ressources système d’un processus :
Cela est accompli grâce à l’utilitaire renice, qui modifie la priorité de planification d’un ou de plusieurs processus en cours d’exécution. En termes simples, la priorité de planification est une fonctionnalité qui permet au noyau (présent dans les versions => 2.6) d’allouer des ressources système en fonction de la priorité d’exécution attribuée (également appelée « niceness », dans une plage de -20 à 19) d’un processus donné.
La syntaxe de base de renice est la suivante:
# renice [-n] priority [-gpu] identifier
Dans la commande générique ci-dessus, le premier argument est la valeur de priorité à utiliser, tandis que l’autre argument peut être interprété comme des IDs de processus (qui est le paramètre par défaut), des IDs de groupe de processus, des IDs d’utilisateur ou des noms d’utilisateur. Un utilisateur normal (autre que root) ne peut modifier que la priorité de planification d’un processus qu’il possède, et uniquement augmenter le niveau de « niceness » (ce qui signifie utiliser moins de ressources système).
2. Arrêter (ou interrompre l’exécution normale) d’un processus si nécessaire:
En termes plus précis, arrêter un processus consiste à lui envoyer un signal pour soit terminer son exécution de manière propre (SIGTERM=15), soit immédiatement (SIGKILL=9) à travers les commandes kill ou pkill.
La différence entre ces deux outils est que le premier est utilisé pour terminer un processus spécifique ou un groupe de processus entier, tandis que le second vous permet de le faire en fonction du nom et d’autres attributs.
De plus, pkill est livré avec pgrep, qui vous montre les PIDs qui seront affectés si pkill est utilisé. Par exemple, avant d’exécuter:
# pkill -u gacanepa
Il peut être utile de voir d’un coup d’œil quels sont les PIDs possédés par gacanepa:
# pgrep -l -u gacanepa
Par défaut, à la fois kill et pkill envoient le signal SIGTERM au processus. Comme mentionné précédemment, ce signal peut être ignoré (pendant que le processus termine son exécution ou définitivement), donc lorsque vous avez vraiment besoin d’arrêter un processus en cours avec une raison valable, vous devrez spécifier le signal SIGKILL> sur la ligne de commande :
# kill -9 identifier # Kill a process or a process group # kill -s SIGNAL identifier # Idem # pkill -s SIGNAL identifier # Kill a process by name or other attributes
Conclusion
Dans cet article, nous avons expliqué les bases du processus de démarrage dans un système RHEL 7, et analysé certains des outils disponibles pour vous aider à gérer les processus en utilisant des utilitaires courants et des commandes spécifiques à systemd.
Remarquez que cette liste n’a pas pour but de couvrir tous les aspects de ce sujet, alors n’hésitez pas à ajouter vos propres outils et commandes préférés à cet article en utilisant le formulaire de commentaire ci-dessous. Les questions et autres commentaires sont également les bienvenus.
Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/