RHCSA-serien: Prosessledelse i RHEL 7: Oppstart, avslutning og alt i mellom – del 5

Vi starter denne artikkelen med en overordnet og kort revisjon av hva som skjer siden du trykker på strømknappen for å slå på RHEL 7-serveren til du blir presentert med påloggingsskjermen i et kommandolinjegrensesnitt.

Vær oppmerksom på at:

1. de samme grunnleggende prinsippene gjelder, med kanskje mindre modifikasjoner, også for andre Linux-distribusjoner, og
2. Den følgende beskrivelsen er ikke ment å representere en uttømmende forklaring av oppstartsprosessen, men bare det grunnleggende.

Linux oppstartsprosess

1. POST (Power On Self Test) initialiserer og utfører maskinvaresjekker.

2. Når POST er ferdig, sendes systemkontrollen til første trinns oppstartslaster, som er lagret på enten oppstartssektoren til en av harddiskene (for eldre systemer som bruker BIOS og MBR), eller en dedikert (U)EFI skillevegg.

3. Første trinns oppstartslaster laster deretter andre trinns oppstartslaster, vanligvis GRUB (GRand Unified Boot Loader), som ligger inne i /boot, som igjen laster inn kjernen og det innledende RAM-baserte filsystemet (også kjent som initramfs , som inneholder programmer og binære filer som utfører de nødvendige handlingene som trengs for til slutt å montere det faktiske rotfilsystemet).

4. Vi blir presentert med en splash-skjerm som lar oss velge et operativsystem og kjerne for å starte opp:

5. Kjernen setter opp maskinvaren som er koblet til systemet, og når rotfilsystemet er montert, starter prosessen med PID 1, som igjen vil initialisere andre prosesser og gi oss en påloggingsforespørsel.

Merk: Hvis vi ønsker å gjøre det på et senere tidspunkt, kan vi undersøke detaljene i denne prosessen ved å bruke dmesg-kommandoen og filtrere utdataene ved å bruke verktøyene som vi har forklart i tidligere artikler i denne serien.

I eksemplet ovenfor brukte vi den velkjente ps-kommandoen for å vise en liste over gjeldende prosesser hvis overordnede prosess (eller med andre ord, prosessen som startet dem) er systemd (system- og servicebehandleren som de fleste moderne Linux-distribusjoner har byttet om til) under systemoppstart:

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

Husk at -o-flagget (forkortelse for –format) lar deg presentere utdataene til ps i et tilpasset format for å passe dine behov ved å bruke nøkkelordene som er spesifisert i STANDARD FORMAT SPECIFIERS-delen i man ps.

Et annet tilfelle der du vil definere utdataene til ps i stedet for å gå med standarden, er når du trenger å finne prosesser som forårsaker en betydelig CPU- og/eller minnebelastning, og sortere dem deretter:

# 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 introduksjon til SystemD

Få avgjørelser i Linux-verdenen har forårsaket flere kontroverser enn bruken av systemd ved store Linux-distribusjoner. Systemds talsmenn nevner som sine viktigste fordeler følgende fakta:

Les også: Historien bak 'init' og 'systemd'

1. Systemd lar mer prosessering utføres parallelt under systemoppstart (i motsetning til eldre SysVinit, som alltid har en tendens til å være tregere fordi den starter prosesser én etter én, sjekker om en er avhengig av en annen og venter på at demoner skal starte så flere tjenester kan starte), og

2. Det fungerer som en dynamisk ressursstyring i et kjørende system. Dermed startes tjenester ved behov (for å unngå å forbruke systemressurser hvis de ikke blir brukt) i stedet for å bli lansert uten gyldig grunn under oppstart.

3. Bakoverkompatibilitet med SysVinit-skript.

Systemd styres av systemctl-verktøyet. Hvis du kommer fra en SysVinit-bakgrunn, er sjansen stor for at du vil bli kjent med:

tjenesteverktøyet, som -i de eldre systemene- ble brukt til å administrere SysVinit-skript, og
chkconfig-verktøyet, som tjente formålet med å oppdatere og spørre om kjørenivåinformasjon for systemtjenester.
avslutning, som du må ha brukt flere ganger for å enten starte på nytt eller stoppe et kjørende system.

Følgende tabell viser likhetene mellom bruken av disse eldre verktøyene og systemctl:

Systemd introduserte også begrepene enheter (som kan være enten en tjeneste, et monteringspunkt, en enhet eller en nettverkskontakt) og mål (som er hvordan systemd klarer å starte flere relaterte prosesser samtidig, og kan vurderes - men ikke lik - som ekvivalent med kjørenivåer i SysVinit-baserte systemer.

Oppsummering

Andre oppgaver knyttet til prosessledelse inkluderer, men er kanskje ikke begrenset til, evnen til å:

Dette oppnås gjennom renice-verktøyet, som endrer planleggingsprioriteten til en eller flere kjørende prosesser. Enkelt sagt er planleggingsprioriteten en funksjon som lar kjernen (tilstede i versjoner => 2.6) allokere systemressurser i henhold til den tildelte utførelsesprioriteten (aka penhet, i et område fra -20 til 19) for en gitt prosess.

Den grunnleggende syntaksen for renice er som følger:

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

I den generiske kommandoen ovenfor er det første argumentet prioritetsverdien som skal brukes, mens det andre argumentet kan tolkes som prosess-IDer (som er standardinnstillingen), prosessgruppe-IDer, bruker-IDer eller brukernavn. En vanlig bruker (annet enn root) kan bare endre planleggingsprioriteten til en prosess han eller hun eier, og bare øke pent nivået (som betyr å ta opp mindre systemressurser).

Mer presist, å drepe en prosess gir rett til å sende den et signal om enten å fullføre utførelsen grasiøst (SIGTERM=15) eller umiddelbart (SIGKILL=9) gjennom kill- eller pkill-kommandoene.

Forskjellen mellom disse to verktøyene er at førstnevnte brukes til å avslutte en spesifikk prosess eller en prosessgruppe helt, mens sistnevnte lar deg gjøre det samme basert på navn og andre attributter.

I tillegg kommer pkill sammen med pgrep, som viser deg PID-ene som vil bli påvirket dersom pkill brukes. For eksempel før du løper:

# pkill -u gacanepa

Det kan være nyttig å se på et øyeblikk hvilke PID-er som eies av gacanepa:

# pgrep -l -u gacanepa

Som standard sender både kill og pkill SIGTERM-signalet til prosessen. Som vi nevnte ovenfor, kan dette signalet ignoreres (mens prosessen fullfører sin kjøring eller for godt), så når du seriøst trenger å stoppe en kjørende prosess med en gyldig grunn, må du spesifisere 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

Konklusjon

I denne artikkelen har vi forklart det grunnleggende om oppstartsprosessen i et RHEL 7-system, og analysert noen av verktøyene som er tilgjengelige for å hjelpe deg med å administrere prosesser ved å bruke vanlige verktøy og systemd-spesifikke kommandoer.

Merk at denne listen ikke er ment å dekke alle klokkene og plystrene i dette emnet, så legg gjerne til dine egne foretrukne verktøy og kommandoer til denne artikkelen ved å bruke kommentarskjemaet nedenfor. Spørsmål og andre kommentarer er også velkomne.