RHCSA-serien: Processtyring i RHEL 7: Boot, nedlukning og alt imellem - Del 5

Vi starter denne artikel med en samlet og kort revision af hvad der sker siden det øjeblik, du trykker på tænd/sluk-knappen for at tænde din RHEL 7-server, indtil du får vist loginskærmen i en kommandolinjegrænseflade.

Bemærk, at:

1. de samme grundlæggende principper gælder, med måske mindre ændringer, også for andre Linux-distributioner og
2. den følgende beskrivelse er ikke beregnet til at repræsentere en udtømmende forklaring på opstartsprocessen, men kun det grundlæggende.

Linux-startproces

1. POST (Power On Self Test) initialiserer og udfører hardwarekontrol.

2. Når POST er færdig, overføres systemkontrollen til første trin bootloader, som er gemt på enten boot-sektoren på en af harddiskene (til ældre systemer, der bruger BIOS og MBR) eller en dedikeret (U) EFI skillevæg.

3. Boot loader i første trin indlæser derefter boot loader i anden fase, normalt GRUB (GRand Unified Boot Loader), som ligger inde i/boot, som igen indlæser kernen og det oprindelige RAM-baserede filsystem (også kendt som initramfs , som indeholder programmer og binære filer, der udfører de nødvendige handlinger, der er nødvendige for i sidste ende at montere det faktiske rodfilsystem).

4. Vi får en stænkskærm, der giver os mulighed for at vælge et operativsystem og en kerne, der skal startes:

5. Kernen opretter den hardware, der er knyttet til systemet, og når rodfilsystemet er blevet monteret, starter processen med PID 1, som igen vil initialisere andre processer og give os en loginprompt.

Bemærk: At hvis vi ønsker at gøre det på et senere tidspunkt, kan vi undersøge detaljerne i denne proces ved hjælp af dmesg-kommandoen og filtrere dens output ved hjælp af de værktøjer, som vi har forklaret i tidligere artikler i denne serie.

I eksemplet ovenfor brugte vi den velkendte ps-kommando til at vise en liste over aktuelle processer, hvis overordnede proces (eller med andre ord den proces, der startede dem) er systemd (system- og servicemanager, som de fleste moderne Linux-distributioner har skiftet til) under systemstart:

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

Husk, at -o-flag (kort for –format) giver dig mulighed for at præsentere output af ps i et tilpasset format, der passer til dine behov ved hjælp af de nøgleord, der er specificeret i afsnittet STANDARD FORMAT SPECIFIERS i man ps.

Et andet tilfælde, hvor du vil definere output af ps i stedet for at gå med standard, er når du skal finde processer, der forårsager en betydelig CPU og/eller hukommelsesbelastning, og sorter dem i overensstemmelse hermed:

# 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)

En introduktion til SystemD

Få beslutninger i Linux-verdenen har forårsaget flere kontroverser end vedtagelsen af systemd ved større Linux-distributioner. Systemds talsmænd navngiver følgende fakta som sine største fordele:

Læs også: Historien bag 'init' og 'systemd'

1. Systemd gør det muligt at udføre mere behandling parallelt under systemstart (i modsætning til ældre SysVinit, som altid har en tendens til at være langsommere, fordi den starter processer en efter en, kontrollerer om den ene er afhængig af en anden og venter derefter på, at dæmoner starter så flere tjenester kan starte), og

2. Det fungerer som en dynamisk ressourcehåndtering i et kørende system. Således startes tjenester, når det er nødvendigt (for at undgå at forbruge systemressourcer, hvis de ikke bruges) i stedet for at blive lanceret uden en gyldig grund under opstart.

3. Bagudkompatibilitet med SysVinit-scripts.

Systemd styres af systemctl-værktøjet. Hvis du kommer fra en SysVinit-baggrund, er chancerne for, at du vil være fortrolig med:

serviceværktøjet, som - i de ældre systemer - blev brugt til at administrere SysVinit-scripts, og
værktøjet chkconfig, der tjente formålet med at opdatere og forespørge runlevel-information om systemtjenester.
nedlukning, som du skal have brugt flere gange for enten at genstarte eller standse et kørende system.

Følgende tabel viser lighederne mellem brugen af disse ældre værktøjer og systemctl:

Systemd introducerede også begreberne enheder (som enten kan være en service, et monteringspunkt, en enhed eller et netværksstik) og mål (hvilket er, hvordan systemd formår at starte flere relaterede processer på samme tid og kan overvejes - dog ikke lig- som svarende til runlevels i SysVinit-baserede systemer.

Opsummering

Andre opgaver relateret til processtyring inkluderer, men er muligvis ikke begrænset til, evnen til at:

Dette opnås gennem renice-hjælpeprogrammet, som ændrer planlægningsprioriteten for en eller flere kørende processer. Enkelt sagt er planlægningsprioriteten en funktion, der gør det muligt for kernen (til stede i versioner => 2.6) at tildele systemressourcer i henhold til den tildelte eksekveringsprioritet (alias i et interval fra -20 til 19) for en given proces.

Den grundlæggende syntaks for renice er som følger:

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

I den generiske kommando ovenfor er det første argument den prioritetsværdi, der skal bruges, mens det andet argument kan fortolkes som proces-id'er (hvilket er standardindstillingen), procesgruppe-id'er, bruger-id'er eller brugernavne. En normal bruger (bortset fra root) kan kun ændre planlægningsprioriteten for en proces, han eller hun ejer, og kun øge pænhedsniveauet (hvilket betyder at tage mindre systemressourcer).

I mere præcise termer giver aflivning af en proces ret til at sende den et signal til enten at afslutte dens udførelse yndefuldt (SIGTERM = 15) eller straks (SIGKILL = 9) gennem kommandoerne kill eller pkill.

Forskellen mellem disse to værktøjer er, at førstnævnte bruges til at afslutte en bestemt proces eller en procesgruppe helt, mens sidstnævnte giver dig mulighed for at gøre det samme baseret på navn og andre attributter.

Derudover leveres pkill med pgrep, som viser dig de PID'er, der vil blive påvirket, hvis pkill bruges. For eksempel før du kører:

# pkill -u gacanepa

Det kan være nyttigt at få vist et overblik, hvilke PID'er der ejes af gacanepa:

# pgrep -l -u gacanepa

Som standard sender både kill og pkill SIGTERM-signalet til processen. Som vi nævnte ovenfor, kan dette signal ignoreres (mens processen er færdig med at udføre eller for godt), så når du seriøst har brug for at stoppe en kørende proces med en gyldig årsag, skal du angive SIGKILL-signalet på kommandolinjen:

# 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

Konklusion

I denne artikel har vi forklaret det grundlæggende i opstartsprocessen i et RHEL 7-system og analyseret nogle af de værktøjer, der er tilgængelige for at hjælpe dig med styring af processer ved hjælp af almindelige hjælpeprogrammer og systemd-specifikke kommandoer.

Bemærk, at denne liste ikke er beregnet til at dække alle klokker og fløjter i dette emne, så du er velkommen til at tilføje dine egne foretrukne værktøjer og kommandoer til denne artikel ved hjælp af nedenstående kommentarformular. Spørgsmål og andre kommentarer er også velkomne.