Gestionarea serviciilor cu Systemd: Ghidul complet pentru Systemctl

În sistemele Linux moderne , systemd și instrumentul său systemctl sunt în centrul gestionării serviciilor și al pornirii . Dacă lucrați zilnic cu servere sau desktop-uri, stăpânirea acestor utilitare vă va permite să porniți, să opriți, să depanați și să automatizați serviciile cu ușurință.

În acest ghid, veți găsi o prezentare generală cuprinzătoare și practică a gestionării serviciilor cu systemd : de la elementele de bază (pornire, oprire, activare) până la opțiuni avansate, cum ar fi izolarea țintelor, editarea unităților cu suprascrieri, analizarea proceselor de pornire și chiar activarea acesteia în WSL. Toate acestea sunt acoperite cu considerații de compatibilitate între distribuții și alte sisteme init, astfel încât să nu fiți luați prin surprindere.

Ce este systemd și cum organizează sistemul?

Pe scurt, systemd este managerul de sistem și servicii de inițiere care rulează ca PID 1 și coordonează pornirea și ciclul de viață al proceselor utilizatorului. În cadrul ecosistemului său, componentele cheie sunt „unități”, care reprezintă resurse gestionabile, cum ar fi servicii, socketuri, puncte de montare, dispozitive sau ținte.

Unitățile sunt descrise cu fișiere unitare cu sufixe care indică tipul lor: .service (servicii), .socket (socketuri), .target (stări ale sistemului), printre altele. Aceste fișiere se află în căi precum /lib/systemd/system y /etc/systemd/systemși pot fi vizualizate, listate și modificate cu systemctl.

Pe lângă systemctl, ecosistemul este completat cu utilitare precum journalctl (jurnale), loginctl (sesiuni), hostnamectl , localectl , timedatectl și instrumente de inspecție precum systemd-cgls . Toate acestea contribuie la o administrare mai fină și mai centralizată.

Dacă trebuie să modificați setările globale implicite, puteți edita /etc/systemd/system.conf (de exemplu, DefaultTimeoutStartSec) și așa mai departe suprascrie valorile de compilare în tot sistemul fără a atinge unitate cu unitate.

Pornirea, oprirea, repornirea și reîncărcarea serviciilor

Viața de zi cu zi începe cu lucrurile de bază: începe și oprește serviciile. Statele Unite ale Americii sudo systemctl start nombre.service să înceapă și sudo systemctl stop nombre.service a opri. Sufixul .service este opțional; systemd este inteligent și de obicei îl deduce. În mediile ferestre din exista comenzi echivalente pentru Controlul proceselor și serviciilor în Windows.

Când faceți modificări de configurație, de obicei atinge reporniți cu sudo systemctl restart nombre.serviceDacă serviciul acceptă reîncărcarea la cald, economisești o întrerupere cu sudo systemctl reloadDacă nu știți dacă să reîncărcați sau nu, trageți reîncărcați-sau-reporniți și asta este

Rețineți că unii daemoni sunt destinati să reapar după o oprire datorită propriei politici de repornire. Acest lucru este comun în componentele de infrastructură, cum ar fi systemd-networkd, așa că nu fi surprins dacă se ridică din nou.

Atenție la variantele dintre distribuții: pe desktopul Ubuntu este obișnuit să lucrați cu Manager de rețea, astfel încât comenzi precum starea rețelei să poată fi interogate în NetworkManager.service în loc de systemd-networkd.service.

Activarea, dezactivarea și verificarea stării

Pentru un serviciu pornire automată cu sistemul, utilizați sudo systemctl enable nombre.serviceAceasta creează legături simbolice de la fișierul unității către căile .../target.wants a țintei corespunzătoare. În Windows, există instrucțiuni privind serviciile care nu trebuie atinse, de exemplu Servicii Windows 11 pe care nu ar trebui să le dezactivezi.

Dacă nu îl doriți la pornire, dezactivați-l cu sudo systemctl disableRețineți că activarea/dezactivarea nu pornește sau oprește serviciul în sesiunea curentă; veți combina activarea/dezactivarea cu pornirea/oprirea, după caz.

Pentru a verifica starea în detaliu, starea systemctl Îți oferă datele despre sarcină, activitate, PID, cgroup și cele mai recente linii de jurnal pentru unitate. Dacă vrei doar un verdict rapid: systemctl is-active (alergând sau nu), systemctl is-enabled (activat sau dezactivat) și systemctl is-failed (eșuat, inactiv, necunoscut) cu coduri de ieșire utile pentru scripturi.

Explorează sistemul: listă-unități și fișiere-listă-unități

Când aveți nevoie de o prezentare generală, comanda `systemctl list-units` afișează unitățile active. Veți vedea coloane pentru UNIT, LOAD, ACTIVE, SUB și DESCRIPTION, oferindu-vă o imagine de ansamblu rapidă asupra a ceea ce se întâmplă. Pe Windows, comanda `tasklist` oferă o vizualizare similară.

Dacă vrei să fii mai exhaustiv, adaugă -toate Pentru a include inactivii, filtrați după stare cu --state= și după tip cu --type=serviceÎn acest fel, puteți lista, de exemplu, toate unitățile de servicii, indiferent de activitatea lor.

Pentru a vedea ce este instalat și politica sa de bootare, comanda systemctl list-unit-files listează fișierele unitare cu starea lor: activat, disactivat, static sau mascat. „Static” indică unități fără secțiune, destinate dependențelor sau execuției ocazionale.

Inspectați unitățile, anexele și proprietățile

Folosirea comenzii `systemctl cat name.service` vă va afișa fișierul unitar exact pe care l-a încărcat systemd (inclusiv suprascrierile). Acest lucru este ideal pentru a verifica ce directive sunt de fapt active.

Dependențele sunt afișate cu dependențe-listă systemctl. poti sa adaugi --all pentru recursiune, --reverse pentru dependențe inverse sau --before/--after pentru ordinea relativă dintre unități.

Dacă aveți nevoie de detalii de nivel scăzut, afișare systemctl elimină proprietățile cheie în format clave=valorPentru ceva anume, folosește -p Propiedad și primești doar ceea ce te interesează (de exemplu, conflicte sau relații de ordine).

Când un serviciu nici măcar nu ar trebui pornit, maschează-l cu sudo systemctl mask nombre.service (indică /dev/null). Apoi, pur și simplu unmask Îl readuce la starea anterioară. O mască blochează pornirile manuale și automate. În mediile Windows, puteți restaura serviciile deteriorate și din consola Servicii, de exemplu. Restaurați serviciile șterse din services.msc.

Editarea unităților: suprascrieri și reîncărcări daemon

Pentru a personaliza fără a atinge fișierul original, systemctl editează numele.service deschide o suprascriere în /etc/systemd/system/nombre.service.d/override.confOrice ai pune acolo prevalează fără a pierde baza furnizorilor.

Dacă vrei să rescrii întreaga unitate, folosește -deplin și va salva o copie în /etc/systemd/systemCând eliminați suprascrieri sau unități personalizate, rețineți reîncărcați daemonul cu sudo systemctl daemon-reload astfel încât să nu mai facă referire la ele.

Dacă nu mai aveți nevoie de modificări, puteți ștergeți directorul .d a suprareglării sau a întregii unități din /etc/systemd/systemDupă aceea, o daemon-reload iar sistemul va reveni la definițiile sistemului de bază.

Ținte și relația cu nivelurile de execuție

Țintele reprezintă stări ale sistemului (de exemplu, multi-user.target sau graphical.target) și grupează unitățile necesare pentru a atinge acea stare. Sunt similare cu nivelurile de execuție mai vechi, dar sunt mai flexibile și mai compozabile.

Interogați ținta implicită cu systemctl get-default și schimbați-l cu set-implicit (de exemplu, graphical.target pentru a începe într-un mediu grafic). Puteți lista țintele instalate cu list-unit-files --type=target și active cu list-units --type=target.

Dacă trebuie să faci o navetă drastică, izola oprește ceea ce nu aparține țintei și activează dependențele acesteia. Înainte de a face acest lucru, este o idee bună să revizuiți list-dependencies a țintei pentru a nu doborî accidental ceva critic.

În plus, systemctl expune comenzi rapide cu avertismente pentru utilizatorii conectați: salvare (modul pentru un singur utilizator), oprire, oprire y repornițiPe multe mașini, comenzile tradiționale precum reboot sunt deja legate la systemd.

Creați-vă propriul serviciu (.service) pas cu pas

Pentru un serviciu personalizat, creați unitatea în /etc/systemd/system. De exemplu, ttrssupdate.service Ar putea conține o descriere, dependențe, utilizatorul de execuție și comanda care va fi lansată.

Un exemplu tipic ar fi ceva de genul acesta (ajustați căile reale): cu Description, After, User, ExecStart și WantedBy definiți elementele esențiale pentru ca acesta să pornească cu sistemul multi-utilizator.

În ceea ce privește permisele și proprietatea, este important ca fișierul aparține rădăcină și să aveți permisiuni consecvente. Evitați permisiunile excesiv permisive; deși unele exemple arată chmod 777, practica recomandată este mai restrictivă pentru a nu deschide calea către probleme de securitate.

După crearea sau modificarea unității, executați sudo systemctl daemon-reload, permite cu enable și începe cu start. De acolo, poți opri, reîncepe si consultati StareaPentru depanare, journalctl -u tu-servicio.service vă va arăta busteni asociati.

Echivalente cu SysV și alte inițializări

Dacă vii de la SysV, gândește-te la systemctl pornire/oprire/repornire/reîncărcare/stare ca înlocuitori pentru service nombre start/stop/...Pentru partea de început, permite dezactivarea înlocuiește chkconfig on/off, Și listă-unități-fișiere oferă o imagine de ansamblu asupra a ceea ce este activat.

În sistemele mai vechi, este posibil să întâlniți ` service --status-all` , care listează daemonii cu steaguri precum (activ), (inactiv) sau (necunoscut). Cu Upstart (Ubuntu 14.04, RHEL6), `initctl list` este utilizat pentru a vizualiza stări precum `running`, `stopped` sau `waiting`.

În medii care utilizează OpenRC (Gentoo, Alpin), rc-status Afișează serviciile după nivel de execuție cu stările pornite/oprite/eșuate/blocate. Puteți chiar verifica nivelul de execuție curent cu rc runlevelPentru sarcini avansate de gestionare a proceselor în Windows, există și instrumente terțe, de exemplu Folosește Process Hacker pentru a gestiona prioritatea.

Diagnosticare, jurnale și performanță de pornire

Pentru a verifica definițiile, systemd-analyze oferă funcții de verificare și analiză. Puteți obține o imagine a procesului de pornire, puteți vedea ce a durat cel mai mult și puteți desena un fișier SVG.

Comenzi comune: systemd-analiza vina (ori per serviciu), systemd-analizează lanțul critic (lanțul critic al dependențelor) și graficul systemd-analyze (generează o .svg cu cronologia de pornire).

Când un serviciu eșuează, începeți cu `journalctl -u service.name` pentru a vedea erorile și avertismentele. Puteți lista unitățile eșuate și, dacă oprirea sau repornirea durează mult timp, puteți verifica dacă există joburi blocate și le puteți anula înainte de a încerca din nou.

Dacă editați sau creați unități noi, nu uitați să rulați comanda systemd-analyze verify pentru a detecta erori de sintaxă sau referințe la fișiere inexistente înainte de a activa și porni serviciul.

Bune practici de management

În fișierele unitare, utilizați întotdeauna căi absolute în ExecStart/ExecReload și fișierele de configurare. Nu vă bazați pe variabile de mediu, cum ar fi $PATH deoarece systemd nu le va lua în considerare așa cum ar face-o shell-ul tău.

Defini Reîncărcare executivă dacă serviciul dvs. acceptă reîncărcarea dinamică. În acest fel puteți utiliza systemctl reload fierbinte fără repornire, ceea ce este esențial pentru serverele cu disponibilitate ridicată.

Configurați RestartSec împreună cu politicile de repornire pentru a preveni buclele de repornire frenetice. O mică întârziere ajută la stabilizarea dependențelor și a resurselor partajate.

Documentare și monitorizare: salvare liste ca systemctl listă-fișiere-unități –type serviciu –all > servicii.txt, mapează dependențele cu list-dependencies --reverse și monitorizează starea și consumul. Completați cu soluții Prometheus/Grafana sau APM dacă este cazul dumneavoastră.

Pe sistemele critice la distanță, dezactivați modul de urgență dacă acesta v-ar putea lăsa fără acces la rețea din cauza unei configurări greșite. Și, bineînțeles, validați modificările din staging înainte de a le implementa în producție.

Compatibilitate, adopție și viziune de afaceri

Deși systemd domină în majoritatea distribuțiilor de astăzi , nu este universal. Fedora l-a încorporat devreme; Debian l-a folosit încă din versiunea 8; RHEL și CentOS încă din RHEL 7; Ubuntu l-a adoptat în versiunea 15.04; Arch și openSUSE îl folosesc de ani de zile, printre altele.

Nu au fost toate laude: complexitatea și domeniul său de aplicare au fost criticate , precum și potențialul său de a crea dependență în cadrul ecosistemului și o anumită abatere de la filosofia minimalistă Unix . Pentru administratorii începători, curba de învățare poate părea abruptă.

Printre dezavantajele practice: permisiuni și securitate dacă nu sunt configurate corect, posibile conflicte de dependențe, porniri mai lente din cauza timeout-urilor prost reglate sau defecțiuni după actualizări dacă unitățile nu sunt întreținute.

Acestea fiind spuse, în mediile corporative, oferă consistență, telemetrie și control . Modularitatea, înregistrarea integrată și modelarea declarativă a dependențelor facilitează operarea la scară largă și reduc timpul mediu de reparare.

Systemd în WSL: Cum se activează și ce modificări are

Dacă lucrați pe Windows cu WSL 2, acum puteți activați systemd pentru a ne apropia și mai mult de un Linux bare-metal. Pe Ubuntu actual instalat cu wsl --install Vine deja implicit.

Pentru alte distribuții pe WSL 2, editați /etc/wsl.conf si adauga: într-o linie și systemd=true în altul. Închide și rulează wsl.exe –oprire en PowerShell pentru a reporni WSL; când reveniți, verificați cu systemctl status.

Pe Debian/Ubuntu/Kali, asigurați-vă că aveți instalate systemd și systemd-sysv . Important: Prin atribuirea PID-ului 1 către systemd, WSL își ajustează arhitectura internă; cu toate acestea, serviciile nu mențin instanța WSL activă pe termen nelimitat, ca înainte.

Pentru oricine dezvoltă cu snaps, microk8s sau alte componente care se bazează pe systemd, această integrare reduce frecarea și aduce comportamentul mai aproape de ceea ce veți vedea în producție.

Merită să ne amintim că systemd oferă și utilitare complementare precum journalctl pentru jurnalizare sau systemd-analyze pentru profilarea pornirii și verificarea unităților. Cu puțină organizare și câteva practici bune, devine un instrument foarte puternic pentru administratori și ingineri DevOps.

Articol asociat:

Cum se modifică serviciile în Windows 11: control complet, securitate și performanță

Isaac

Scriitor pasionat despre lumea octeților și a tehnologiei în general. Îmi place să îmi împărtășesc cunoștințele prin scriere și asta voi face în acest blog, să vă arăt toate cele mai interesante lucruri despre gadgeturi, software, hardware, tendințe tehnologice și multe altele. Scopul meu este să vă ajut să navigați în lumea digitală într-un mod simplu și distractiv.