LFCS: Administration af opstartsprocesser og tjenester (SysVinit, Systemd og Upstart) - Del 7


For et par måneder siden annoncerede Linux Foundation LFCS-certificeringen (Linux Foundation Certified Sysadmin), et spændende nyt program, hvis mål er at give enkeltpersoner fra alle ender af verden mulighed for at blive certificeret i at udføre grundlæggende til mellemliggende systemadministrationsopgaver på Linux-systemer. Dette inkluderer understøttelse af allerede kørende systemer og tjenester sammen med førstehånds problemløsning og analyse samt muligheden for at beslutte, hvornår man skal rejse problemer til ingeniørteams.

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

Dette indlæg er del 7 af en 10-tutorial-serie, her i denne del vil vi forklare, hvordan man styrer Linux-systemets opstartsproces og -tjenester, der kræves til LFCS-certificeringseksamen.

Administration af Linux-startprocessen

Startprocessen for et Linux-system består af flere faser, hver repræsenteret af en anden komponent. Følgende diagram opsummerer kort opstartsprocessen og viser alle de involverede hovedkomponenter.

Når du trykker på knappen Tænd/sluk på din maskine, initialiserer firmwaren, der er gemt i en EEPROM -chip på bundkortet, POST ( Power-On Self Test ) for at kontrollere tilstanden af systemets hardwarressourcer. Når POST er færdig, søger og indlæser firmwaren bootloaderen 1. trin , der er placeret i MBR eller i EFI partition af den første tilgængelige disk og giver kontrol over den.

MBR er placeret i den første sektor af disken, der er markeret som startbar i BIOS indstillingerne og er 512 bytes i størrelse.

  1. Første 446 bytes : Bootloaderen indeholder både eksekverbar kode og fejlmeddelelsestekst.
  2. Næste 64 byte : Partitionstabellen indeholder en post for hver af fire partitioner (primær eller udvidet). Blandt andet angiver hver post status (aktiv/ikke aktiv), størrelse og start/slut sektor for hver partition.
  3. Sidste 2 byte : Det magiske nummer fungerer som en valideringskontrol af MBR.

Den følgende kommando udfører en sikkerhedskopi af MBR (i dette eksempel er /dev/sda den første harddisk). Den resulterende fil, mbr.bkp , kan komme til nytte, hvis partitionstabellen bliver ødelagt, for eksempel gør systemet ikke startbart.

For at kunne bruge det senere, hvis behovet opstår, bliver vi selvfølgelig nødt til at gemme det og gemme det et andet sted (f.eks. Et USB -drev). Denne fil hjælper os med at gendanne MBR og får os til at gå igen, hvis og kun hvis vi ikke ændrer harddisklayoutet i mellemtiden.

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

For systemer, der bruger metoden EFI / UEFI , læser UEFI-firmwaren dens indstillinger for at bestemme, hvilken UEFI-applikation der skal startes, og hvorfra (dvs. i hvilken disk og partition EFI-partition er placeret).

Derefter indlæses og køres 2. trin boot loader (også kaldet boot manager). GRUB [ GRand Unified Boot ] er den mest anvendte boot manager i Linux. En af to forskellige versioner findes på de fleste systemer, der bruges i dag.

  1. GRUB ældre konfigurationsfil : /boot/grub/menu.lst (ældre distributioner, understøttes ikke af EFI/UEFI firmwares).
  2. GRUB2-konfigurationsfil : sandsynligvis/etc/default/grub.

Selvom målene for LFCS eksamen ikke udtrykkeligt anmoder om viden om GRUB interner, hvis du er modig og har råd til at ødelægge dit system (det kan være en god idé at prøve det først på en virtuel maskine, bare i tilfælde), skal du køre.

# update-grub

Som rod efter ændring af GRUBs konfiguration for at anvende ændringerne.

Grundlæggende indlæser GRUB standard kernen og initrd eller initramfs -billedet. I få ord hjælper initrd eller initramfs med at udføre hardwaredetektering, kernemodulindlæsning og enhedsopdagelse, der er nødvendig for at få det rigtige rodfilsystem monteret.

Når det virkelige rodfilsystem er op, udfører kernen system- og servicemanageren ( init eller systemd , hvis procesidentifikation eller PID altid er 1) for at starte den normale bruger- space boot-proces for at præsentere en brugergrænseflade.

Både init og systemd er dæmoner (baggrundsprocesser), der administrerer andre dæmoner, som den første tjeneste, der starter (under opstart) og den sidste service, der afsluttes (under nedlukning).

Starttjenester (SysVinit)

Begrebet runlevels i Linux specificerer forskellige måder at bruge et system ved at kontrollere, hvilke tjenester der kører. Med andre ord styrer et runlevel, hvilke opgaver der kan udføres i den aktuelle eksekveringstilstand = runlevel (og hvilke der ikke kan).

Traditionelt blev denne opstartsproces udført baseret på konventioner, der stammer fra System V UNIX , hvor systemet passerer udførelse af samlinger af scripts, der starter og stopper tjenester, når maskinen gik ind i et specifikt runlevel (som med andre ord , er en anden måde at køre systemet på).

Inden for hvert runlevel kan individuelle tjenester indstilles til at køre eller blive lukket ned, hvis de kører. Seneste versioner af nogle større distributioner bevæger sig væk fra System V -standarden til fordel for en ret ny service- og systemadministrator kaldet systemd (som står for systemdemon), men normalt understøtter sysv kommandoer til kompatibilitetsformål. Dette betyder, at du kan køre de fleste af de velkendte sysv init-værktøjer i en systemd-baseret distribution.

Læs også : Hvorfor 'systemd' erstatter 'init' i Linux

Udover at starte systemprocessen ser init til filen /etc/inittab for at afgøre, hvilket runlevel der skal indtastes.

For at skifte mellem runlevels kan vi blot udstede en runlevel-ændring ved hjælp af kommandoen init : init N (hvor N er en af ovenstående runlevels). Vær opmærksom på, at dette ikke er den anbefalede måde at føre et kørende system til et andet kørselsniveau, fordi det ikke giver nogen advarsel til eksisterende indloggede brugere (hvilket får dem til at miste arbejde og processer til at ophøre unormalt).

I stedet skal kommandoen lukning bruges til at genstarte systemet (som først sender en advarselsmeddelelse til alle indloggede brugere og blokerer for yderligere login; det signalerer derefter init for at skifte runlevels); standard runlevel (den, systemet starter til) skal dog redigeres i filen /etc/inittab .

Af denne grund skal du følge disse trin for at skifte korrekt mellem runlevels. Som root skal du kigge efter følgende linje i /etc/inittab .

id:2:initdefault:

og skift nummeret 2 for det ønskede runlevel med din foretrukne teksteditor, såsom vim (beskrevet i Sådan bruges vi/vim editor i Linux - Del 2 i denne serie).

Kør derefter som root.

# shutdown -r now

Den sidste kommando genstarter systemet, hvilket får det til at starte i det angivne runlevel under næste opstart og kører de scripts, der findes i /etc/rc [runlevel ].d katalog for at bestemme, hvilke tjenester der skal startes, og hvilke der ikke skal. For eksempel til runlevel 2 i det følgende system.

For at aktivere eller deaktivere systemtjenester ved opstart bruger vi kommandoen chkconfig i CentOS/openSUSE og sysv-rc-conf i Debian og derivater. Dette værktøj kan også vise os, hvad der er den forudkonfigurerede tilstand for en tjeneste til et bestemt runlevel.

Læs også : Sådan stoppes og deaktiveres uønskede tjenester i Linux

Notering af runlevel-konfigurationen for en tjeneste.

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

På ovenstående billede kan vi se, at postfix er indstillet til at starte, når systemet går ind i runniveauer 2 til 5 , mens mysqld kører som standard for runlevels 2 til 4 . Antag nu, at dette ikke er den forventede adfærd.

For eksempel er vi nødt til at aktivere mysqld for runlevel 5 også og deaktivere postfix for runlevels 4 og 5. Her er hvad vi ville gøre i hvert tilfælde (kør følgende kommandoer som root).

# chkconfig --level [level(s)] service on
# chkconfig --level 5 mysqld on
# chkconfig --level [level(s)] service off
# chkconfig --level 45 postfix off

Vi udfører nu lignende opgaver i et Debian-baseret system ved hjælp af sysv-rc-conf .

Konfiguration af en tjeneste, der starter automatisk på et bestemt runlevel og forhindrer, at den starter på alle andre.

1. Lad os bruge følgende kommando til at se, hvad der er runlevels, hvor mdadm er konfigureret til at starte.

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

2. Vi bruger sysv-rc-conf til at forhindre mdadm i at starte på alle runlevels undtagen 2 . Marker eller fjern markeringen (med mellemrumstasten) efter ønske (du kan flytte op, ned, til venstre og til højre med piletasterne).

# sysv-rc-conf

Tryk derefter på q for at afslutte.

3. Vi genstarter systemet og kører kommandoen fra TRIN 1 igen.

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

På ovenstående billede kan vi se, at mdadm er konfigureret til kun at starte på køreplan 2 .

Hvad med systemd?

systemd er en anden service- og systemmanager, der er ved at blive vedtaget af flere store Linux-distributioner. Det sigter mod at tillade mere behandling at ske parallelt under systemstart (i modsætning til sysvinit , som altid har en tendens til at være langsommere, fordi det starter processer en ad gangen, kontrollerer om man er afhængig af en anden og venter på dæmoner til lancering, så flere tjenester kan starte) og til at fungere som en dynamisk ressourcehåndtering til et kørende system.

Således startes tjenester, når det er nødvendigt (for at undgå at forbruge systemressourcer) i stedet for at blive lanceret uden en solid grund under opstart.

Visning af status for alle de processer, der kører på dit system, både systemd native og SysV tjenester, kør følgende kommando.

# systemctl

Kolonnen LOAD viser, om enhedsdefinitionen (se kolonnen ENHED , som viser tjenesten eller andet, der opretholdes af systemd) var korrekt indlæst, mens AKTIV og SUB kolonner viser den aktuelle enheds aktuelle status.

Når kolonnen AKTIV angiver, at en enheds status er anden end aktiv, kan vi kontrollere, hvad der skete ved hjælp af.

# systemctl status [unit]

For eksempel er media-samba.mount i mislykket tilstand på billedet ovenfor. Lad os løbe.

# systemctl status media-samba.mount

Vi kan se, at media-samba.mount mislykkedes, fordi monteringsprocessen på vært dev1 ikke kunne finde netværksandelen på //192.168.0.10/gacanepa .

Start eller stop af tjenester

Når netværksandelen //192.168.0.10/gacanepa bliver tilgængelig, lad os prøve at starte, derefter stoppe og til sidst genstarte enheden media-samba.mount . Efter at have udført hver handling, lad os køre systemctl status media-samba.mount for at kontrollere dens status.

# 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

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

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

Processen med at aktivere eller deaktivere en tjeneste, der starter automatisk ved opstart, består i at tilføje eller fjerne symbolske links i mappen /etc/systemd/system/multi-user.target.wants .

Alternativt kan du finde ud af en tjenestes aktuelle status (aktiveret eller deaktiveret) med kommandoen.

# systemctl is-enabled [service]

For eksempel,

# systemctl is-enabled postfix.service

Derudover kan du genstarte eller lukke systemet med.

# systemctl reboot
# systemctl shutdown

Opstart

Upstart er en begivenhedsbaseret erstatning for /sbin/init dæmonen og blev kun født af behovet for kun at starte tjenester, når de er nødvendige (også overvåge dem, mens de kører) og håndterer begivenheder, når de opstår, og overgår dermed det klassiske afhængighedsbaserede sysvinit-system.

Det blev oprindeligt udviklet til Ubuntu-distribution, men bruges i Red Hat Enterprise Linux 6.0. Selvom det var beregnet til at være egnet til implementering i alle Linux-distributioner som erstatning for sysvinit , blev det med tiden overskygget af systemd . Den 14. februar 2014 meddelte Mark Shuttleworth (grundlægger af Canonical Ltd.), at fremtidige udgivelser af Ubuntu ville bruge systemd som standard init-dæmon.

Fordi SysV start-scriptet til systemet har været så almindeligt i så lang tid, inkluderer et stort antal softwarepakker SysV-opstartsskripter. For at imødekomme sådanne pakker tilbyder Upstart en kompatibilitetstilstand: Den kører SysV-opstartsskripter på de sædvanlige placeringer ( /etc/rc.d/rc?.d , /etc/init.d/ rc? .d , /etc/rc?.d eller en lignende placering). Således, hvis vi installerer en pakke, der endnu ikke indeholder et Upstart-konfigurationsscript, skal den stadig starte på den sædvanlige måde.

Desuden, hvis vi har installeret hjælpeprogrammer som f.eks. Chkconfig, skal du kunne bruge dem til at administrere dine SysV-baserede tjenester, ligesom vi ville gøre det på sysvinit-baserede systemer.

Upstart-scripts understøtter også start eller stop af tjenester baseret på en bredere vifte af handlinger end SysV-opstartsscripter; For eksempel kan Upstart starte en tjeneste, når en bestemt hardwareenhed er tilsluttet.

Et system, der bruger Upstart og dets oprindelige scripts, erstatter udelukkende /etc/inittab -filen og de runlevel-specifikke SysV start-scriptmapper med .conf scripts i mappen /etc/init .

Disse * .conf scripts (også kendt som jobdefinitioner) består generelt af følgende:

    1. Beskrivelse af processen.
    2. Runniveauer, hvor processen skal køre, eller begivenheder, der skal udløse den.
    3. Runniveauer, hvor processen skal stoppes, eller begivenheder, der skal stoppe den.
    4. Valgmuligheder.
    5. Kommando til at starte processen.

    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
    

    Hvis du vil anvende ændringer, skal du bede upstart om at genindlæse konfigurationen.

    # initctl reload-configuration
    

    Start derefter dit job ved at skrive følgende kommando.

    $ sudo start yourjobname
    

    Hvor dit jobnavn er navnet på jobbet, der blev tilføjet tidligere med scriptet dit jobnavn.konf .

    En mere komplet og detaljeret referencevejledning til Upstart er tilgængelig på projektets websted under menuen "Kogebog".

    Resumé

    En viden om Linux-opstartsprocessen er nødvendig for at hjælpe dig med fejlfinding af opgaver såvel som med at tilpasse computerens ydeevne og køre tjenester til dine behov.

    I denne artikel har vi analyseret, hvad der sker fra det øjeblik, hvor du trykker på Power -knappen for at tænde maskinen, indtil du får en fuldt operativ brugergrænseflade. Jeg håber, du har lært at læse det lige så meget som jeg gjorde, mens jeg sammensatte det. Du er velkommen til at efterlade dine kommentarer eller spørgsmål nedenfor. Vi ser altid frem til at høre fra vores læsere!