Komplett veiledning for systemctl-kommandoen i Linux

Å dominere systemctl og systemd Det er praktisk talt obligatorisk i disse dager hvis du administrerer moderne Linux-servere eller -systemer. Dette verktøyet er inngangsporten til å kontrollere hvilke tjenester som starter, hvordan de starter, hva som har feilet, og den faktiske tilstanden til systemet ditt til enhver tid. Når du først har fått taket på det, sparer du deg selv for mye hodebry og mange unødvendige omstarter.

Gjennom hele denne veiledningen vil du på en ordnet måte og med eksempler se hvordan du bruker systemctl for å administrere tjenester, enheter og målHvordan liste opp hva som skjer i systemet, hvordan redigere disker uten å ødelegge noe, hva tilstander som betyr aktivert, maskert o statiskOg også Triks å slå av, starte på nytt eller bytte fra grafisk til tekstmodus med én enkelt kommando. Alt ved hjelp av en Spansk fra Spania, direkte og praktisk, designet slik at du kan bruke det du leser til enhver systemd-basert distro (Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, osv.).

Hva er systemd, og hvilken rolle spiller systemctl?

I de fleste nåværende distribusjoner, systemd fungerer som et oppstartssystem og en basisinfrastrukturDet er prosessen som starter rett etter kjernen (vanligvis som PID 1) og er ansvarlig for å starte resten av tjenestene, montere filsystemer, administrere avhengigheter, kontrollere økter, logge hendelser og mye mer.

systemd består av daemoner, biblioteker og verktøy som tillater kommunikasjon med kjernen og brukerområdet: administrerer kontrollgrupper (cgroups), sokkeler, tidtakere, monteringspunkter, grunnleggende nettverkskonfigurasjon, tidssynkronisering, navneløsning, containere og virtuelle maskinerog er til og med kompatibel med eldre SysV- og LSB-skript, slik at den kan erstatte fullstendig Klassisk Sysvinit.

Innenfor hele dette økosystemet, systemctl er "fjernkontrollen" til systemdDet er et nettbasert verktøy for kommandoer som du bruker til:

• Start, stopp, start på nytt eller last inn tjenester på nytt og andre typer enheter.
• Aktiver eller deaktiver enheter slik at de kan starte (eller ikke) med systemet.
• Sjekk statusen av tjenester, mål og systemet generelt.
• Rediger Disk-filer eller se dens avhengigheter og interne egenskaper.
• Endre global tilstand av systemet (redningsmodus, flerbruker, grafisk, avslutning, omstart…).

Merk at ikke alle distribusjoner bruker systemd. Hvis når du kjører systemctl Du ser en melding som denne: bash: systemctl: command not found Eller noe lignende; systemet ditt bruker sannsynligvis et annet init-system (OpenRC, runit, pure SysV, osv.). I så fall, Kommandoene i denne veiledningen gjelder ikke som det er.

Stasjoner og stasjonsfiler i systemd

Nøkkelkonseptet i systemd er enheterEn enhet representerer enhver ressurs som systemd er i stand til å administrere: en tjeneste, en socket, et monteringspunkt, en enhet, et systemglobalt mål, en timer… Hver enhetstype identifiseres av en suffiks i filnavnet.

Noen av de vanligste typene enheter du vil se når du jobber med systemctl og systemd er:

• .servicetjenester og daemoner (nginx.service, ssh.service, NetworkManager.service…).
• .stikkontakt: stikkontakter tilknyttet tjenester startet på forespørsel.
• .mountmonteringspunkter for filsystemet.
• .automountautomatiske enheter aktivert for bruk.
• .målsystem-"tilstander" (multi-user.target, graphical.target, rescue.target…).
• .timer: tidtakere som starter tjenester til bestemte tidspunkter.
• .enhetenheter administrert av udev.
• .stiruter monitorer på disk som utløser tjenester.

Hver enhet er definert i en enhetsfilsom er en tekstfil med seksjoner som , , , hvor beskrivelsen, avhengighetene og kommandoene til er detaljert boot, brukeren som kjører tjenesten, osv. Disse filene lagres vanligvis i:

• /lib/systemd/system/ o /usr/lib/systemd/system/: enheter som følger med pakkene.
• / Etc / systemd / system /enheter definert eller overskrevet av administratoren.

når du jobber med systemctlDu refererer nesten alltid til enheter av typen .serviceHvis du imidlertid utelater suffikset, antar systemd som standard at du refererer til en tjeneste. Det vil si, systemctl start ssh y systemctl start ssh.service er likeverdige.

Det finnes spesialenheter som kalles maler, hvis navn inkluderer @for eksempel name@.serviceNår du instansierer en mal som name@miinstancia.serviceDet du gjør er å lage en en spesifikk forekomst som sender en identifikator; innenfor enhetsfilen, variabelen %i Den erstattes av den identifikatoren. Dette brukes ofte i SSH-tunneler, nettverksgrensesnitttjenester osv.

Sjekk om systemet ditt bruker systemd

Før du går amok med kommandoene, er det lurt å sjekke om distroen din faktisk bruker systemd som PID 1Mange guider foreslår noe så enkelt som:

pstree | head -5

Hvis du ser en prosess på toppen av treet systemdDu kan fortsette uten problemer. Hvis du ser et annet oppstartssystem, må du bruke de spesifikke verktøyene for det oppstartssystemet.

Grunnleggende tjenestehåndtering med systemctl

Daglig drift med systemd fokuserer vanligvis på Start, stopp, start på nytt og last inn tjenester på nyttDisse kommandoene påvirker tjenestens gjeldende tilstand, ikke om den starter automatisk med systemet eller ikke.

Til sjekk statusen til en tjeneste, du kan bruke:

systemctl status nombre_servicio.service

For eksempel for å se hvordan nettverkstjenesten yter systemd-nettverkd på et tekstmodus Ubuntu-system:

systemctl status systemd-networkd.service

Denne kommandoen viser ganske detaljert informasjon: status (aktiv, inaktiv, mislykket…), da den ble aktivert, hoved-PID, CPU-bruk og noen få nylige loggmeldinger som er svært nyttige for å diagnostisere problemer.

Hvis du ønsker noe mer direkte, kan du bruke disse spesifikke variasjonene:

• systemctl er aktiv navn.tjeneste: indikerer om den er aktiv (kjører) eller ikke.
• systemctl er aktivert name.service: indikerer om den vil starte fra begynnelsen.
• systemctl mislyktes navn.tjeneste: sjekker om den har gått inn i en feiltilstand.

For eksempel, for å se om systemd-networkd er aktivert ved oppstart, kan du kjøre:

systemctl is-enabled systemd-networkd.service

Og for å finne ut om den ikke startet på noe tidspunkt:

systemctl is-failed systemd-networkd.service

Starte, stoppe, starte på nytt og laste inn tjenester på nytt

Til stoppe en tjeneste som kjørerDen typiske rekkefølgen er:

sudo systemctl stop nombre_servicio.service

Husk at siden dette er en handling som påvirker systemet, må du administrasjonsrettigheter, vanligvis ved bruk av sudoI noen "gjenstridige" tjenester, som for eksempel systemd-networkd, vil det å stoppe dem føre til at de starter på nytt umiddelbart hvis det finnes en enhet som krever dem og har automatiske omstartspolicyer.

Hvis tjenesten er stoppet og du ønsker start detDu bruker det samme mønsteret med start:

sudo systemctl start systemd-networkd.service

Når du har endret en konfigurasjonsfil og vil bruke endringene, er det vanligste å gjøre start tjenesten på nytt:

sudo systemctl restart nombre_servicio.service

Mange demoner tillater Last inn innstillingene på nytt uten å starte helt på nyttunngå å kutte aktive forbindelser. I disse tilfellene brukes følgende:

sudo systemctl reload nombre_servicio.service

Hvis du er usikker på om tjenesten støtter påfylling, kan du prøve:

sudo systemctl reload-or-restart nombre_servicio.service

Med denne kommandoen, systemctl prøver å laste inn på nytt først Og hvis enheten ikke utfører en ny omlasting, fortsetter den med en fullstendig omstart. Dette er veldig nyttig når du ikke husker den spesifikke oppførselen til hver daemon.

Aktiver og deaktiver tjenester ved oppstart

Alt vi har sett så langt påvirker bare gjeldende øktHvis du vil at en tjeneste skal starte automatisk når systemet starter opp, må du aktiver denDen grunnleggende kommandoen er:

sudo systemctl enable nombre_servicio.service

Ved å gjøre det, oppretter systemd symboliske lenker fra systemtjenestefilen (vanligvis i /lib/systemd/system o /etc/systemd/system) opp til en katalog .wants som tilsvarer målet der den skal aktiveres. For eksempel noe sånt som:

/etc/systemd/system/multi-user.target.wants/nombre_servicio.service

Hvis du vil ha det stikk motsatte, altså forhindre at en tjeneste starter automatisk Deaktiver den ved neste oppstart:

sudo systemctl disable nombre_servicio.service

Dette fjerner de symbolske oppstartslenkene, men Den stopper ikke tjenesten som allerede kjørerPå samme måte starter ikke aktivering av en tjeneste den umiddelbart: den vil først tre i kraft etter neste omstart, med mindre du kombinerer følgende:

sudo systemctl enable nombre_servicio.service
sudo systemctl start nombre_servicio.service

Noen distribusjoner og verktøy tilbyr snarveier for aktivere og starte samtidigStandardmåten med systemctl er imidlertid vanligvis å kjøre begge kommandoene.

Se enhetenes generelle status

systemctl er ikke bare nyttig for å berøre individuelle tjenester; det tillater også å ha oversikt over systemetDen mest typiske kommandoen er:

systemctl list-units

Denne listen viser alle aktive enheter som systemd har i minnet. Hovedkolonnene er:

• ENHET: enhetsnavn (for eksempel, sshd.service).
• LASTom stasjonsfilen er lastet inn riktig (lastet inn, ikke funnet, feil…).
• AKTIVgenerell status (aktiv, inaktiv, mislykket…).
• SUB: mer beskrivende undertilstand (kjører, avsluttet, død, mislyktes…).
• BESKRIVELSEkort beskrivelse av enheten.

Hvis du ringer systemctl uten argumenterDu vil se så godt som den samme listen, siden det er standardoppførselen. Siden bare aktive enheter vises, vil nesten alt vises med LAST=lastet og AKTIV=aktiv.

For å også inkludere inaktive enheter, kan du legge til indikatoren --all:

systemctl list-units --all

Du kan også filtrere etter stat med --state=For eksempel, for å bare se inaktive stasjoner:

systemctl list-units --all --state=inactive

Eller filtrer etter enhetstype med --type=For eksempel, for å bare se aktive tjenester:

systemctl list-units --type=service

List opp alle installerte stasjonsfiler

Listen ovenfor viser bare enheter som systemd har forsøkt å laste inn. Hvis du vil vite mer. alle stasjonene som finnes på diskenEnten du bruker dem eller ikke, må du ty til:

systemctl list-unit-files

Her er fokuset på selve enhetsfilene, ikke tilstanden deres i minnet. Du vil se to hovedkolonner: ENHETSFIL y STATI STATE vises verdier som følgende:

• aktivertEnheten er konfigurert til å starte automatisk.
• deaktivertDen er ikke konfigurert for automatisk oppstart.
• statiskEnheten har ingen seksjon , Slik at kan ikke aktivere seg selvDet er vanligvis en avhengighet av andre enheter eller for å utføre en spesifikk handling.
• maskertEnheten er helt låst; den kan ikke startes på noen måte.

Du kan også filtrere etter status, for eksempel for å bare se aktiverte enheter:

systemctl list-unit-files --state=enabled

Eller kombiner flere tilstander i én enkelt spørring ved å skille dem med komma:

systemctl list-unit-files --state=enabled,failed

Vis detaljer, egenskaper og avhengigheter for en enhet

Hvis du vil se det faktiske innholdet i stasjonsfilen Siden systemd bruker den mest praktiske kommandoen, er det:

systemctl cat nombre.service

Dette viser filen slik systemd ser den, inkludert eventuelle overstyringsfragmenter fra /etc/systemd/systemDet er veldig nyttig for å bekrefte at endringene dine faktisk er tatt hensyn til.

Å inspisere avhengighetstre Fra én enhet kan du bruke:

systemctl list-dependencies nombre.service

Utdataene er hierarkiske og viser hvilke mål og tjenester som driver den aktuelle tjenesten. Enhetene av typen .mål De fungerer som grupperingspunkter, og bare de viser rekursivt avhengighetene sine som standard. Hvis du vil utvide hele treet, legg til --all.

Hvis det du trenger å vite er hvilke enheter avhenger av den du anga, Legge til --reverse til kommandoen. Og hvis du vil fokusere på oppstartsrekkefølgen, flaggene --before y --after De viser enheter som må starte før eller etter målenheten.

For å se alt interne egenskaper for en enhet i key=value-format, bruk:

systemctl show nombre.service

Og hvis du bare er interessert i en bestemt eiendom, kan du filtrere med -pFor eksempel, for å se sshd-konflikter:

systemctl show sshd.service -p Conflicts

Maskering og avmaskering av enheter

I tillegg til å deaktivere, tillater systemd maskere en enhet slik at det er fullstendig umulig å starte den oppDenne teknikken brukes når du vil være 100 % sikker på at noe ikke vil starte, selv ved et uhell. Dette kan gjøres manuelt eller ved å bruke en annen enhet.

Maskeringen implementeres ved å opprette en symbolsk lenke til /dev/null i stedet for den faktiske stasjonsfilen. For å maskere en tjeneste, for eksempel nginx:

sudo systemctl mask nginx.service

Hvis du da løper systemctl list-unit-files, du vil se det nginx.service vises som maskertOg hvis du prøver å starte den:

sudo systemctl start nginx.service

Du vil motta en melding som denne: Klarte ikke å starte nginx.service: Enheten nginx.service er maskert. Med andre ord, enheten er pansret. For å gjøre den brukbar igjen, er det nødvendig å avslør henne:

sudo systemctl unmask nginx.service

Etter dette går enheten tilbake til sin forrige tilstand (aktivert, deaktivert, statisk osv.) og kan deretter startes eller aktiveres normalt.

Rediger diskfiler uten å ødelegge systemet

Noen ganger må du justere virkemåten til en tjeneste: endre brukeren som kjører den, legge til kommandolinjealternativer, endre avhengigheter ... I stedet for å redigere filene manuelt i /lib/systemd/systemDet tryggeste er å bruke din egen systemctl for å generere overstyringer.

Den grunnleggende kommandoen er:

sudo systemctl edit nombre.service

Dette åpner standardredigeringsprogrammet ditt med en tom fragmentfilNår du lagrer og avslutter, vil systemd opprette en katalog i /etc/systemd/system/nombre.service.d/ og inni en fil override.confNår du laster inn harddisken, slår systemd sammen den opprinnelige filen med dette fragmentet, og overstyringsdirektivene de har prioritet på de i basisfilen.

Hvis du vil redigere den komplette stasjonsfilen I stedet for en overstyring kan du gjøre det med:

sudo systemctl edit --full nombre.service

I dette tilfellet vil det du lagrer bli skrevet til /etc/systemd/system/nombre.servicesom har forrang over systemversjonen i /lib/systemd/systemDet er en måte å «klone» og fullstendig tilpasse en disk uten å berøre filene som følger med pakken.

Hvis du senere bestemmer deg for å angre endringene, er det bare å slett .d-katalogen av overstyringen eller den endrede tjenestefilen i /etc/systemd/system. For eksempel:

sudo rm -r /etc/systemd/system/nginx.service.d
sudo rm /etc/systemd/system/nginx.service

Etter at du har slettet disse elementene, er det svært viktig å kjøre:

sudo systemctl daemon-reload

Dette tvinger systemet til å Last inn alle Disk-filene på nyttGlem de fjernede overstyringene og gå tilbake til å bruke de opprinnelige systemdefinisjonene.

Mål og tilpasning på løpenivå

den systemd-mål er den moderne ekvivalenten til runlevels fra SysV. De er spesialenheter (de ender på .target) som grupperer andre enheter for å representere «tilstander» eller synkroniseringspunkter i systemet.

For eksempel:

• flerbrukermålflerbrukerkonsollmodus, typisk for servere uten grafisk miljø.
• grafisk.mål: grafisk modus; avhenger vanligvis av multi-user.target og legger til det grafiske grensesnittlaget.
• redning.mål: redningsmodus, lik «enkeltbrukermodus».
• swap.target: punktet der utvekslingsområdet er klart til bruk.

Enheter kan deklarere relasjoner som ØnskesAv=, PåkrevdAv=, Ønsker=, Krever=, Etter= med disse målene for å indikere hva de er avhengige av og i hvilken rekkefølge de skal oppnås.

Par saber Hva er det forhåndsbestemte målet? av systemet ditt (tilstanden du ønsker å oppnå i en normal oppstart), bruk:

systemctl get-default

Hvis du for eksempel foretrekker at systemet alltid skal starte i grafisk modus, kan du endre det med:

sudo systemctl set-default graphical.target

For å se alle målene som er installert på systemet, med status (aktivert, deaktivert…), kan du kjøre:

systemctl list-unit-files --type=target

Og hvis det du vil er å se hvilke mål er aktive akkurat nåDu gjør det med:

systemctl list-units --type=target

Isoler mål og endre arbeidsmodus

En av de kraftigste tingene systemd tilbyr er muligheten til å endre systemtilstanden ved å «isolere» et målNår du utfører en isolasjon, aktiverer systemd alle enhetene som er nødvendige for det målet og stopper de som ikke lenger passer inn i avhengighetstreet.

Tenk deg at du er i et grafisk miljø (aktivt grafisk.målog du ønsker å gå over til et tekstbasert flerbrukermiljø, for eksempel for vedlikeholdsoppgaver. Du kan først sjekke avhengighetene til multi-user.target:

systemctl list-dependencies multi-user.target

Og når du er sikker på at du ikke kommer til å skade noe kritisk, starter du:

sudo systemctl isolate multi-user.target

Siden graphical.target er avhengig av multi-user.target, men ikke omvendt, vil isolering av flerbrukermålet stoppe det. alle tjenester knyttet til grafikklagetslik at du blir værende i tekstmodus. Det er en ganske radikal endring, så bruk den med omhu.

For svært vanlige hendelser tilbyr systemctl praktiske snarveier kontra å skrive isolert for hånd. Noen av de mest brukte er:

• sudo systemctl redning: bytter til redningsmodus (tilsvarer å isolere rescue.target) og varsler tilkoblede brukere.
• sudo systemctl stopp: stopper systemet (ligner på å slå av CPU-en uten å kutte strømmen).
• sudo systemctl poweroffSlå av maskinen helt.
• sudo systemctl omstart: starter systemet på nytt.

Vanligvis klassiske kommandoer som reboot, poweroff o halt De er internt koblet for å snakke med systemd, så de oppfører seg konsekvent med disse snarveiene.

Ytterligere viktige systemctl-kommandoer

I tillegg til alt det ovennevnte finnes det noen kommandoer for systemctl som du bør ha for hånden fordi du vil bruke dem ofte når du jobber med enheter:

Last inn systemd-konfigurasjonen på nytt (ikke tjenestene):

sudo systemctl daemon-reload

Hver gang du endrer eller legger til diskfiler, må du varsle systemd slik at den kan lese dem på nytt. Denne kommandoen tjenestene starter ikke på nyttDen laster bare enhetsdatabasen på nytt.

Sjekk statusen til en tjeneste med detaljer (allerede diskutert):

sudo systemctl status nombre_servicio.service

Her ser du statusen Lastet inn, Aktiv, PID, oppetid og de siste loggmeldingene, noe som er uvurderlig for feilsøking.

Aktiver og deaktiver tjenester (også sett):

sudo systemctl enable nombre_servicio.service
sudo systemctl disable nombre_servicio.service

Start, stopp og start tjenester på nytt eksplisitt:

sudo systemctl start nombre_servicio.service
sudo systemctl stop nombre_servicio.service
sudo systemctl restart nombre_servicio.service

Disse mønstrene gjentas med så godt som alle tjenester, fra apache2, nginx eller ssh, opp til tjenester fra databaser, inntrykksdemoner eller hva du enn kan tenke deg.

Tjenestehåndtering: start, last på nytt, stopp og overvåk

I en virkelig setting vil du bruke systemctl for å holde viktige tjenester alltid oppe og i gangwebservere, databaser, nettverkstjenester, daemoner backuposv. Tanken er å minimere tiden av inaktivitet og implementere konfigurasjonsendringer med minst mulig innvirkning.

Til starte en tjeneste som skal være aktiv (for eksempel Apache), vil den typiske kommandoen være:

sudo systemctl start apache2

Hvis Apache allerede kjørte, vil du ikke merke noe uvanlig. Hvis den ble stoppet, vil daemonen starte underprosesser og begynne å håndtere forespørsler. Når du er usikker på hva som skjedde, kjør følgende kommandoer:

sudo systemctl status apache2

Når du endrer hovedkonfigurasjonsfilen eller noe annet virtuell vert, du vanligvis lade o omstart Tjenesten. Ladingen går jevnere:

sudo systemctl reload apache2

Dette lar tjenesten lese konfigurasjonsfiler på nytt uten å avslutte kjørende prosesser, slik at brukerne knapt merker noe. Hvis tjenesten av en eller annen grunn ikke støtter omlasting, må du:

sudo systemctl restart apache2

I noen tilfeller, hvis tjenesten har problemer eller ikke svarer, kan det være nødvendig med en fullstendig omstart. frigjør ressurser og rydder opp i zombieprosesserDet er et av de typiske diagnostiske trinnene før man undersøker det. logger dypt.

Til midlertidig stanse en tjeneste fordi du utfører vedlikehold eller fordi du rett og slett ikke trenger det på en stund:

sudo systemctl stop apache2

Det hindrer den ikke i å starte på nytt ved neste omstart hvis du har aktivert den. Hvis du vil at den skal forsvinne helt inntil videre, kombinerer du stopp med deaktiver o-maske avhengig av graden av «forbud» du ønsker å anvende.

Etter enhver sensitiv kirurgi anbefales det på det sterkeste Sjekk status av tjenesten og dens nyeste oppføringer med:

sudo systemctl status nombre_servicio

Og hvis du trenger mer kontekst, med journalctl, for eksempel:

sudo journalctl -u nombre_servicio

Feilsøking av vanlige problemer med systemctl

Når noe går galt når man starter en tjeneste med systemctlDet er normalt å se meldinger som «Jobb for X mislyktes» eller statuser mislyktes i statusavslutningen. Den ordnede måten å gå frem på er vanligvis:

1. Se detaljert status av enheten:

sudo systemctl status nombre_servicio

Der vil du se om tjenesten ikke starter på grunn av en kommandofeil, en tidsavbrudd, tillatelsesproblemer, en manglende fil osv. Se på linjer som "Main PID exited" og de faktiske feilmeldingene fra programmet.

2. Gjennomgå de fullstendige postene med journalctl:

sudo journalctl -u nombre_servicio

Dette gir deg logghistorikken som genereres av enheten, noe som er veldig nyttig hvis tjenesten "dør" rett etter oppstart.

3. Sjekk om den er aktivert når du forventer at den skal starte opp:

sudo systemctl is-enabled nombre_servicio

Hvis det vises som deaktivert, gjør du det enkelt:

sudo systemctl enable nombre_servicio

4. Sjekk tillatelser og brukerNoen tjenester må kjøres som en bestemt bruker eller ha tilgang til bestemte stier. Hvis enhetsfilen spesifiserer en User= o Group= feil, eller ruten i ExecStart= Hvis den ikke finnes eller ikke er tilgjengelig, kan tjenesten gå ned umiddelbart.

5. Hvis du har redigert stasjonsfilen manuelt, husk alltid last inn systemd-konfigurasjonen på nytt med:

sudo systemctl daemon-reload

Å glemme dette trinnet er en klassisk feil: du gjør endringer, starter tjenesten på nytt og ser fortsatt den gamle oppførselen fordi systemd ikke har lest den nye filen ennå.

Å opprettholde denne rutinen med kontroller og regelmessig gjennomgå statusen til viktige enheter gjør det mye enklere. Opprettholde et stabilt og forutsigbart Linux-system.

Som du ser, systemctl blir den sveitsiske lommekniven for å administrere systemtjenester, enheter og stater I enhver moderne distribusjon med systemd lar den deg starte og stoppe daemoner med presisjon, kontrollere hva som starter ved oppstart, undersøke feil i detalj, justere konfigurasjoner uten å overskrive systemfiler og bytte fra grafisk modus til redningsmodus på sekunder. Å mestre disse kommandoene gjør det ikke bare mye enklere å administrere Linux-servere eller skrivebord, men gir deg også mye mer trygghet når du feilsøker alvorlige produksjonsproblemer, fordi du vet nøyaktig hva som kjører, hvorfor og hvordan du trygt kan stoppe eller endre det.