LFCS: Administrere systemoppstartsprosesser og -tjenester (SysVinit, Systemd og Upstart) - Del 7

For et par måneder siden kunngjorde Linux Foundation LFCS (Linux Foundation Certified Sysadmin)-sertifiseringen, et spennende nytt program som har som mål å la individer fra alle ender av verden bli sertifisert i å utføre grunnleggende til middels systemadministrasjonsoppgaver på Linux-systemer. Dette inkluderer støtte for allerede kjørende systemer og tjenester, sammen med førstehånds problemsøking og analyse, pluss muligheten til å bestemme når man skal ta opp problemer til ingeniørteam.

Følgende video beskriver en kort introduksjon til The Linux Foundation Certification Program.

Dette innlegget er del 7 av en serie med 10 opplæringsprogrammer, her i denne delen vil vi forklare hvordan du administrerer Linux System Startup Process and Services, som kreves for LFCS-sertifiseringseksamenen.

Administrere Linux-oppstartsprosessen

Oppstartsprosessen til et Linux-system består av flere faser, hver representert av en annen komponent. Følgende diagram oppsummerer kort oppstartsprosessen og viser alle hovedkomponentene som er involvert.

Når du trykker på Power-knappen på maskinen, initialiserer fastvaren som er lagret i en EEPROM-brikke på hovedkortet POST ( Power-On Self Test) for å sjekke statusen til systemets maskinvareressurser. Når POST er fullført, søker og laster fastvaren 1st stage oppstartslasteren, som ligger i MBR eller i EFI partisjon av den første tilgjengelige disken, og gir kontroll til den.

MBR metode

MBR er plassert i den første sektoren på disken merket som oppstartbar i BIOS-innstillingene og er 512 byte stor.

Første 446 byte: Oppstartslasteren inneholder både kjørbar kode og feilmeldingstekst.
Neste 64 byte: Partisjonstabellen inneholder en post for hver av fire partisjoner (primær eller utvidet). Blant annet indikerer hver post status (aktiv/ikke aktiv), størrelse og start-/sluttsektorer for hver partisjon.
Siste 2 byte: Det magiske tallet fungerer som en valideringssjekk av MBR.

Følgende kommando utfører en sikkerhetskopi av MBR (i dette eksemplet er /dev/sda den første harddisken). Den resulterende filen, mbr.bkp kan komme til nytte hvis partisjonstabellen blir korrupt, for eksempel gjør systemet uoppstartbart.

Selvfølgelig, for å bruke det senere hvis behovet oppstår, må vi lagre det og lagre det et annet sted (som en USB-stasjon, for eksempel). Den filen vil hjelpe oss med å gjenopprette MBR og vil få oss i gang igjen hvis og bare hvis vi ikke endrer harddiskoppsettet i mellomtiden.

Sikkerhetskopier MBR

dd if=/dev/sda of=mbr.bkp bs=512 count=1

Gjenoppretter MBR

dd if=mbr.bkp of=/dev/sda bs=512 count=1

EFI/UEFI-metode

For systemer som bruker EFI/UEFI-metoden, leser UEFI-fastvaren sine innstillinger for å bestemme hvilken UEFI-applikasjon som skal startes og hvorfra (dvs. på hvilken disk og partisjon EFI-partisjonen er lokalisert).

Deretter lastes og kjøres 2nd stage boot loader (også kalt boot manager). GRUB [GRand Unified Boot] er den mest brukte oppstartsbehandleren i Linux. En av to forskjellige versjoner finnes på de fleste systemer som brukes i dag.

Eldre GRUB-konfigurasjonsfil: /boot/grub/menu.lst (eldre distribusjoner, støttes ikke av EFI/UEFI-fastvare).
GRUB2-konfigurasjonsfil: mest sannsynlig /etc/default/grub.

Selv om målene for LFCS-eksamenen ikke eksplisitt ber om kunnskap om GRUB-internaler, hvis du er modig og har råd til å ødelegge systemet ditt (kan det være lurt å prøve det først på en virtuell maskin, bare i tilfelle), må du kjøre.

update-grub

Som root etter å ha endret GRUBs konfigurasjon for å bruke endringene.

I utgangspunktet laster GRUB standard kjernen og initrd- eller initramfs-bildet. Med få ord hjelper initrd eller initramfs til å utføre maskinvaredeteksjonen, lasting av kjernemodulen og enhetsoppdagelsen som er nødvendig for å få det virkelige rotfilsystemet montert.

Når det virkelige rotfilsystemet er oppe, kjører kjernen system- og tjenestebehandlingen (init eller systemd, hvis prosessidentifikasjon eller PID alltid er 1) for å starte den normale bruker- space boot prosess for å presentere et brukergrensesnitt.

Både init og systemd er demoner (bakgrunnsprosesser) som administrerer andre demoner, som den første tjenesten som starter (under oppstart) og den siste tjenesten som avsluttes (under avslutning).

Starttjenester (SysVinit)

Konseptet runlevels i Linux spesifiserer forskjellige måter å bruke et system på ved å kontrollere hvilke tjenester som kjører. Med andre ord, et kjørenivå styrer hvilke oppgaver som kan utføres i gjeldende utførelsestilstand=kjørenivå (og hvilke som ikke kan).

Tradisjonelt ble denne oppstartsprosessen utført basert på konvensjoner som har sin opprinnelse med System V UNIX, hvor systemet passerer utførende samlinger av skript som starter og stopper tjenester når maskinen gikk inn i et spesifikt kjørenivå (som med andre ord , er en annen modus for å kjøre systemet).

Innenfor hvert kjørenivå kan individuelle tjenester settes til å kjøre, eller til å bli stengt hvis de kjører. De siste versjonene av noen store distribusjoner beveger seg bort fra System V-standarden til fordel for en ganske ny tjeneste og systembehandler kalt systemd (som står for system daemon), men vanligvis støtte sysv-kommandoer for kompatibilitetsformål. Dette betyr at du kan kjøre de fleste av de velkjente sysv init-verktøyene i en systembasert distribusjon.

Les også: Hvorfor 'systemd' erstatter 'init' i Linux

I tillegg til å starte systemprosessen, ser init på /etc/inittab-filen for å bestemme hvilket kjørenivå som må angis.

Runlevel: Beskrivelse
0: Stopp systemet. Runlevel 0 er en spesiell overgangstilstand som brukes til å slå av systemet raskt.
1: Også kalt s, eller S, kalles dette kjørenivået noen ganger vedlikeholdsmodus. Hvilke tjenester, om noen, som startes på dette kjørenivået varierer etter distribusjon. Den brukes vanligvis til systemvedlikehold på lavt nivå som kan bli svekket av normal systemdrift.
2: Flerbruker. På Debian-systemer og derivater er dette standard kjørenivå, og inkluderer -hvis tilgjengelig- en grafisk pålogging. På Red-Hat-baserte systemer er dette flerbrukermodus uten nettverk.
3: På Red-Hat-baserte systemer er dette standard flerbrukermodus, som kjører alt bortsett fra det grafiske miljøet. Dette kjørenivået og nivå 4 og 5 brukes vanligvis ikke på Debian-baserte systemer.
4: Vanligvis ubrukt som standard og derfor tilgjengelig for tilpasning.
5: På Red-Hat-baserte systemer, full flerbrukermodus med GUI-pålogging. Dette kjørenivået er som nivå 3, men med en GUI-pålogging tilgjengelig.
6: Start systemet på nytt.

For å bytte mellom kjørenivåer kan vi ganske enkelt utstede en kjørenivåendring ved å bruke init-kommandoen: init N (der N er et av kjørenivåene som er oppført ovenfor). Vær oppmerksom på at dette ikke er den anbefalte måten å ta et kjørende system til et annet kjørenivå, fordi det ikke gir noen advarsel til eksisterende påloggede brukere (og dermed føre til at de mister arbeid og prosesser avsluttes unormalt).

I stedet bør kommandoen shutdown brukes til å starte systemet på nytt (som først sender en advarsel til alle påloggede brukere og blokkerer ytterligere pålogginger; den signaliserer deretter init for å bytte kjørenivå); standard kjørenivå (det systemet vil starte opp til) må imidlertid redigeres i filen /etc/inittab først.

Av den grunn, følg disse trinnene for å bytte riktig mellom kjørenivåer. Som root, se etter følgende linje i /etc/inittab.

id:2:initdefault:

og endre tallet 2 for ønsket kjørenivå med ditt foretrukne tekstredigeringsprogram, for eksempel vim (beskrevet i Hvordan bruke vi/vim-redigering i Linux – del 2 av denne serien).

Deretter kjører du som root.

shutdown -r now

Den siste-kommandoen vil starte systemet på nytt, noe som får det til å starte på det angitte kjørenivået ved neste oppstart, og vil kjøre skriptene som ligger i /etc/rc[runlevel].d katalog for å bestemme hvilke tjenester som skal startes og hvilke som ikke skal. For eksempel for kjørenivå 2 i følgende system.

Administrer tjenester ved hjelp av chkconfig

For å aktivere eller deaktivere systemtjenester ved oppstart, vil vi bruke kommandoen chkconfig i CentOS/openSUSE og sysv-rc-conf i Debian og derivater. Dette verktøyet kan også vise oss hva som er den forhåndskonfigurerte tilstanden til en tjeneste for et bestemt kjørenivå.

Les også: Hvordan stoppe og deaktivere uønskede tjenester i Linux

Viser kjørenivåkonfigurasjonen for en tjeneste.

chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld

I bildet ovenfor kan vi se at postfix er satt til å starte når systemet går inn i kjørenivåene 2 til 5, mens mysqld b> kjører som standard for kjørenivåene 2 til 4. Anta nå at dette ikke er den forventede oppførselen.

For eksempel må vi slå på mysqld for kjørenivå 5 også, og slå av postfix for kjørenivå 4 og 5. Her er hva vi ville gjort i hvert tilfelle (kjør følgende kommandoer som root).

Aktivering av en tjeneste for et bestemt kjørenivå

chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on

Deaktivering av en tjeneste for bestemte kjørenivåer

chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off

Vi vil nå utføre lignende oppgaver i et Debian-basert system ved å bruke sysv-rc-conf.

Administrer tjenester ved å bruke sysv-rc-conf

Konfigurere en tjeneste til å starte automatisk på et bestemt kjørenivå og forhindre at den starter på alle andre.

1. La oss bruke følgende kommando for å se hvilke kjørenivåer mdadm er konfigurert til å starte.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

2. Vi vil bruke sysv-rc-conf for å forhindre at mdadm starter på alle kjørenivåer unntatt 2. Bare merk av eller fjern merket (med mellomromstasten) etter ønske (du kan flytte opp, ned, til venstre og høyre med piltastene).

sysv-rc-conf

Trykk deretter q for å avslutte.

3. Vi starter systemet på nytt og kjører kommandoen fra TRINN 1 igjen.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

I bildet ovenfor kan vi se at mdadm er konfigurert til å starte bare på kjørenivå 2.

Hva med systemd?

systemd er en annen tjeneste- og systembehandler som blir tatt i bruk av flere store Linux-distribusjoner. Den tar sikte på å tillate mer prosessering å gjøres parallelt under systemoppstart (i motsetning til sysvinit, som alltid har en tendens til å være tregere fordi den starter prosesser én om gangen, sjekker om én er avhengig av en annen og venter på daemoner for å starte slik at flere tjenester kan starte), og for å tjene som en dynamisk ressursadministrasjon til et kjørende system.

Dermed startes tjenester ved behov (for å unngå forbruk av systemressurser) i stedet for å bli lansert uten en solid grunn under oppstart.

Kjør følgende kommando for å se statusen til alle prosessene som kjører på systemet ditt, både systemd native og SysV tjenester.

systemctl

Kolonnen LOAD viser om enhetsdefinisjonen (se UNIT-kolonnen, som viser tjenesten eller noe vedlikeholdt av systemd) ble korrekt lastet, mens ACTIVE- og SUB-kolonnene viser gjeldende status for en slik enhet.

Viser informasjon om gjeldende status for en tjeneste

Når AKTIV-kolonnen indikerer at en enhets status er annerledes enn aktiv, kan vi sjekke hva som skjedde ved å bruke.

systemctl status [unit]

For eksempel, i bildet ovenfor, er media-samba.mount i mislykket tilstand. La oss løpe.

systemctl status media-samba.mount

Vi kan se at media-samba.mount mislyktes fordi monteringsprosessen på verten dev1 ikke klarte å finne nettverksandelen på //192.168.0.10/gacanepa.

Starte eller stoppe tjenester

Når nettverksdelingen //192.168.0.10/gacanepa blir tilgjengelig, la oss prøve å starte, deretter stoppe og til slutt starte enheten media-samba.mount på nytt. Etter å ha utført hver handling, la oss kjøre systemctl status media-samba.mount for å sjekke statusen.

systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount

Aktivere eller deaktivere en tjeneste for å starte under oppstart

Under systemd kan du aktivere eller deaktivere en tjeneste når den starter opp.

systemctl enable [service] 		# enable a service 
systemctl disable [service] 		# prevent a service from starting at boot

Prosessen med å aktivere eller deaktivere en tjeneste for å starte automatisk ved oppstart består i å legge til eller fjerne symbolske lenker i katalogen /etc/systemd/system/multi-user.target.wants.

Alternativt kan du finne ut en tjenestes nåværende status (aktivert eller deaktivert) med kommandoen.

systemctl is-enabled [service]

For eksempel,

systemctl is-enabled postfix.service

I tillegg kan du starte på nytt eller slå av systemet med.

systemctl reboot
systemctl shutdown

Oppkomling

Upstart er en hendelsesbasert erstatning for /sbin/init-demonen og ble født ut av behovet for å starte tjenester kun når de er nødvendige (også overvåker dem mens de kjører), og håndtere hendelser etter hvert som de oppstår, og dermed overgå det klassiske, avhengighetsbaserte sysvinit-systemet.

Den ble opprinnelig utviklet for Ubuntu-distribusjonen, men brukes i Red Hat Enterprise Linux 6.0. Selv om det var ment å være egnet for distribusjon i alle Linux-distribusjoner som en erstatning for sysvinit, ble det med tiden overskygget av systemd. Den 14. februar 2014 kunngjorde Mark Shuttleworth (grunnlegger av Canonical Ltd.) at fremtidige utgivelser av Ubuntu ville bruke systemd som standard init-daemon.

Fordi SysV-oppstartsskriptet for system har vært så vanlig så lenge, inkluderer et stort antall programvarepakker SysV-oppstartsskript. For å imøtekomme slike pakker tilbyr Upstart en kompatibilitetsmodus: Den kjører SysV-oppstartsskript på de vanlige stedene (/etc/rc.d/rc?.d, /etc/init.d/ rc?.d, /etc/rc?.d eller et lignende sted). Derfor, hvis vi installerer en pakke som ennå ikke inkluderer et Upstart-konfigurasjonsskript, bør den fortsatt starte på vanlig måte.

Videre, hvis vi har installert verktøy som chkconfig, bør du kunne bruke dem til å administrere dine SysV-baserte tjenester akkurat som vi ville gjort på sysvinit-baserte systemer.

Upstart-skript støtter også oppstart eller stopp av tjenester basert på et bredere utvalg av handlinger enn SysV-oppstartsskript; for eksempel kan Upstart starte en tjeneste når en bestemt maskinvareenhet er koblet til.

Et system som bruker Upstart og dets opprinnelige skript erstatter eksklusivt /etc/inittab-filen og de runlevel-spesifikke SysV oppstartsskriptkatalogene med .conf skript i katalogen /etc/init.

Disse *.conf-skriptene (også kjent som jobbdefinisjoner) består vanligvis av følgende:

Beskrivelse av prosessen.
Kjørenivåer der prosessen skal kjøre eller hendelser som skal utløse den.
Kjørenivåer der prosessen skal stoppes eller hendelser som skal stoppe den.
Alternativer.
Kommando for å starte prosessen.

For eksempel,

My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas

#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2

For å bruke endringer, må du be oppstarten om å laste inn konfigurasjonen på nytt.

initctl reload-configuration

Start deretter jobben ved å skrive følgende kommando.

sudo start yourjobname

Hvor jobbnavnet ditt er navnet på jobben som ble lagt til tidligere med skriptet jobbnavnet ditt.conf.

En mer fullstendig og detaljert referanseguide for Upstart er tilgjengelig på prosjektets nettside under menyen "Kokebok".

Sammendrag

Kunnskap om Linux-oppstartsprosessen er nødvendig for å hjelpe deg med feilsøkingsoppgaver samt med å tilpasse datamaskinens ytelse og kjøre tjenester til dine behov.

I denne artikkelen har vi analysert hva som skjer fra det øyeblikket du trykker på Strøm-bryteren for å slå på maskinen til du får et fullt operativt brukergrensesnitt. Jeg håper du har lært å lese den like mye som jeg gjorde mens du satt den sammen. Legg gjerne igjen kommentarer eller spørsmål nedenfor. Vi ser alltid frem til å høre fra våre lesere!