RHCSA Serie: Prozessverwaltung in RHEL 7: Booten, Herunterfahren und alles dazwischen – Teil 5

Wir werden diesen Artikel mit einer allgemeinen und kurzen Überprüfung dessen beginnen, was passiert, seit dem Moment, in dem Sie die Power-Taste drücken, um Ihren RHEL 7-Server einzuschalten, bis Sie mit dem Anmeldebildschirm in einer Befehlszeilenschnittstelle präsentiert werden.

Linux Boot Process

Bitte beachten Sie, dass:

1. die gleichen grundlegenden Prinzipien auch für andere Linux-Distributionen gelten, möglicherweise mit geringfügigen Änderungen, und
2. die folgende Beschreibung soll keine erschöpfende Erklärung des Bootvorgangs darstellen, sondern nur die Grundlagen.

Linux Bootvorgang

1. Der POST (Power On Self Test) initialisiert und führt Hardwarechecks durch.

2. Wenn der POST abgeschlossen ist, wird die Systemsteuerung an den ersten Stufen-Bootloader übergeben, der entweder im Bootsektor einer der Festplatten (für ältere Systeme, die BIOS und MBR verwenden) oder in einer dedizierten (U)EFI-Partition gespeichert ist.

3. Der erste Stufen-Bootloader lädt dann den zweiten Stufen-Bootloader, meistens GRUB (GRand Unified Boot Loader), der sich innerhalb von /boot befindet, der wiederum den Kernel und das initiale RAM-basierte Dateisystem lädt (auch bekannt als initramfs, das Programme und Binärdateien enthält, die die erforderlichen Aktionen ausführen, um letztendlich das tatsächliche Stammdateisystem einzuhängen).

4. Wir werden mit einem Startbildschirm präsentiert, der es uns ermöglicht, ein Betriebssystem und einen Kernel zum Booten auszuwählen:

Boot Menu Screen

5. Der Kernel richtet die an das System angeschlossene Hardware ein und startet, sobald das Stammdateisystem eingebunden wurde, Prozesse mit PID 1, die wiederum andere Prozesse initialisieren und uns mit einer Anmeldemeldung präsentieren.

Hinweis: Wenn wir dies zu einem späteren Zeitpunkt tun möchten, können wir die Einzelheiten dieses Prozesses mithilfe des dmesg-Befehls untersuchen und seine Ausgabe mithilfe der Werkzeuge filtern, die wir in früheren Artikeln dieser Serie erläutert haben.

Login Screen and Process PID

Im obigen Beispiel haben wir den bekannten ps-Befehl verwendet, um eine Liste der aktuellen Prozesse anzuzeigen, deren Elternprozess (oder mit anderen Worten der Prozess, der sie gestartet hat) systemd ist (der System- und Dienst-Manager, den die meisten modernen Linux-Distributionen übernommen haben) während des Systemstarts:

# ps -o ppid,pid,uname,comm --ppid=1

Denken Sie daran, dass das Flag -o (kurz für –format) es Ihnen ermöglicht, die Ausgabe von ps in einem benutzerdefinierten Format darzustellen, das Ihren Anforderungen mit den in Abschnitt STANDARD FORMAT SPECIFIERS in man ps festgelegten Schlüsselwörtern entspricht.

Ein weiterer Fall, in dem Sie die Ausgabe von ps definieren möchten, anstatt die Standardeinstellungen beizubehalten, tritt auf, wenn Sie Prozesse finden müssen, die eine erhebliche CPU- und/oder Speicherauslastung verursachen, und diese entsprechend sortieren müssen:

# 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)
Customize ps Command Output

Eine Einführung in SystemD

Wenige Entscheidungen in der Linux-Welt haben mehr Kontroversen verursacht als die Übernahme von systemd durch wichtige Linux-Distributionen. Die Befürworter von Systemd nennen als seine Hauptvorteile die folgenden Fakten:

Weiterlesen: Die Geschichte hinter ‚init‘ und ’systemd‘

1. Systemd ermöglicht es, mehr Verarbeitung parallel während des Systemstarts durchzuführen (im Gegensatz zu dem älteren SysVinit, der immer langsamer ist, weil er Prozesse nacheinander startet, überprüft, ob einer vom anderen abhängt, und dann auf das Starten von Daemons wartet, damit mehr Dienste gestartet werden können), und

2. Es funktioniert als dynamisches Ressourcenmanagement in einem laufenden System. Daher werden Dienste nur bei Bedarf gestartet (um Systemressourcen nicht zu verbrauchen, wenn sie nicht verwendet werden), anstatt ohne gültigen Grund während des Bootvorgangs gestartet zu werden.

3. Abwärtskompatibilität mit SysVinit-Skripten.

Systemd wird durch das Dienstprogramm systemctl gesteuert. Wenn Sie aus einem SysVinit-Hintergrund kommen, werden Sie wahrscheinlich vertraut sein mit:

  1. dem service-Tool, das -in diesen älteren Systemen- verwendet wurde, um SysVinit-Skripte zu verwalten, und
  2. dem Dienstprogramm chkconfig, das dazu diente, Informationen zu Runleveln für Systemdienste zu aktualisieren und abzufragen.
  3. Abschalten, das Sie sicherlich schon mehrmals verwendet haben, um entweder ein laufendes System neu zu starten oder anzuhalten.

Die folgende Tabelle zeigt die Ähnlichkeiten zwischen der Verwendung dieser traditionellen Tools und 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 hat auch die Konzepte von Einheiten (die entweder ein Dienst, ein Einhängepunkt, ein Gerät oder ein Netzwerk-Socket sein können) und Zielen eingeführt (was bedeutet, dass systemd mehrere verwandte Prozesse gleichzeitig starten kann und als das Äquivalent von Runleveln in auf SysVinit basierenden Systemen betrachtet werden kann, obwohl sie nicht gleich sind.

Zusammenfassend

Andere mit der Prozessverwaltung verbundene Aufgaben umfassen unter anderem die Fähigkeit zu:

1. Die Ausführungspriorität in Bezug auf die Nutzung von Systemressourcen eines Prozesses anpassen:

Dies wird durch das Dienstprogramm renice erreicht, das die Terminierungspriorität eines oder mehrerer laufender Prozesse ändert. Vereinfacht ausgedrückt ist die Terminierungspriorität eine Funktion, die dem Kernel (vorhanden in Versionen => 2.6) ermöglicht, Systemressourcen gemäß der zugewiesenen Ausführungspriorität (auch Nettigkeit genannt, in einem Bereich von -20 bis 19) eines bestimmten Prozesses zuzuweisen.

Die grundlegende Syntax von renice lautet wie folgt:

# renice [-n] priority [-gpu] identifier

Im generischen Befehl oben ist das erste Argument der Prioritätswert, der verwendet werden soll, während das andere Argument als Prozess IDs (die Standardeinstellung) interpretiert werden kann, Gruppen-IDs, Benutzer-IDs oder Benutzernamen. Ein normaler Benutzer (außer root) kann nur die Planungspriorität eines Prozesses ändern, den er oder sie besitzt, und nur die Nettigkeitsebene erhöhen (was bedeutet, dass weniger Systemressourcen verwendet werden).

Process Scheduling Priority
2. Töten (oder Unterbrechen der normalen Ausführung) eines Prozesses bei Bedarf:

Genauer gesagt, das Töten eines Prozesses berechtigt dazu, ihm ein Signal zu senden, um entweder seine Ausführung ordnungsgemäß zu beenden (SIGTERM=15) oder sofort (SIGKILL=9) durch die kill oder pkill Befehle.

Der Unterschied zwischen diesen beiden Werkzeugen besteht darin, dass das erstere verwendet wird, um einen bestimmten Prozess oder eine Prozessgruppe insgesamt zu beenden, während das letztere Ihnen ermöglicht, dasselbe basierend auf Namen und anderen Attributen zu tun.

Zusätzlich wird pkill mit pgrep gebündelt, das Ihnen die PIDs anzeigt, die betroffen sein werden, sollte pkill verwendet werden. Beispielsweise, bevor Sie ausführen:

# pkill -u gacanepa

Es kann nützlich sein, auf einen Blick zu sehen, welche PIDs von gacanepa im Besitz sind:

# pgrep -l -u gacanepa
Find PIDs of User

Standardmäßig senden sowohl kill als auch pkill das SIGTERM-Signal an den Prozess. Wie oben erwähnt, kann dieses Signal ignoriert werden (während der Prozess seine Ausführung beendet oder dauerhaft), sodass Sie, wenn Sie einen laufenden Prozess aus einem triftigen Grund ernsthaft beenden müssen, das SIGKILL-Signal auf der Befehlszeile angeben müssen:

# 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 

Zusammenfassung

In diesem Artikel haben wir die Grundlagen des Bootvorgangs in einem RHEL 7-System erläutert und einige der verfügbaren Tools analysiert, die Ihnen bei der Verwaltung von Prozessen mit gängigen Dienstprogrammen und systemd-spezifischen Befehlen helfen können.

Beachten Sie, dass diese Liste nicht dazu gedacht ist, alle Feinheiten dieses Themas abzudecken. Fühlen Sie sich frei, Ihre bevorzugten Tools und Befehle zu diesem Artikel mit dem Kommentarformular unten hinzuzufügen. Fragen und andere Kommentare sind ebenfalls willkommen.

Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/