Modulul 6 · 6.1
Gestionarea serviciilor cu systemd
Modulul 6: Servicii și jurnale · Timp de citire: 10 minute
Obiectivul lecției: După această lecție veți putea porni, opri și reîncărca servicii și le veți putea configura să pornească la boot. Veți putea citi starea unui serviciu și veți putea modifica în siguranță o setare a unui serviciu cu ajutorul unui drop-in.
Noțiuni cheie: systemd, unit, service, systemctl, start, stop, restart, reload, enable, disable, --now, active, inactive, failed, systemctl --failed, drop-in, systemctl edit, daemon-reload, Restart=
Cine ține totul în funcțiune?
Pe un server rulează zeci de programe care trebuie să fie mereu disponibile: serverul SSH, serverul web, o bază de date, sincronizarea orei. Aceste programe se numesc servicii (services sau daemons). Cineva trebuie să le pornească la boot, să le supravegheze și să le repornească dacă se opresc. Pe Debian, Ubuntu, AlmaLinux și Rocky Linux de acest lucru se ocupă systemd. Este primul program pornit de kernel (procesul 1) și pornește apoi tot restul.
systemd lucrează cu unități (units): descrieri ale unui lucru pe care trebuie să îl gestioneze. Cele mai importante tipuri sunt:
| Tip | Extensie | Exemplu |
|---|---|---|
| Serviciu | .service | nginx.service, ssh.service |
| Timer (sarcină programată) | .timer | apt-daily.timer (lecția 4.2, lecția 6.3) |
| Socket | .socket | ssh.socket pe Ubuntu 24.04 și versiunile ulterioare |
| Țintă (grup de unități) | .target | multi-user.target |
Comunicați cu systemd prin comanda systemctl. Extensia .service poate fi omisă: systemctl status nginx este același lucru cu systemctl status nginx.service.
Citirea stării
Comanda pe care o veți folosi cel mai des:
anna@web1:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-11-09 08:12:44 CET; 3h 2min ago
Docs: man:nginx(8)
Process: 902 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 905 (nginx)
Tasks: 3 (limit: 2275)
Memory: 4.1M (peak: 6.3M)
CPU: 213ms
CGroup: /system.slice/nginx.service
├─905 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
└─906 "nginx: worker process"
nov 09 08:12:44 web1 systemd[1]: Starting nginx.service - A high performance web server...
nov 09 08:12:44 web1 systemd[1]: Started nginx.service - A high performance web server...Citiți rezultatul de sus în jos:
- Bulina din fața numelui este verde pentru un serviciu care rulează, albă pentru unul oprit și roșie pentru unul eșuat.
- Loaded arată unde se află fișierul unității și dacă serviciul pornește la boot (
enabled) sau nu (disabled). - Active arată dacă serviciul rulează acum (
active (running)), este oprit (inactive (dead)) sau a eșuat (failed), precum și de când. - Main PID și CGroup arată ce procese aparțin serviciului.
- În partea de jos apar ultimele rânduri din jurnalul serviciului. Adesea acolo scrie deja de ce ceva nu funcționează; mai multe detalii găsiți cu
journalctl(lecția 6.2).
Pornire, oprire, repornire și reîncărcare
anna@web1:~$ sudo systemctl start nginx # pornire acum
anna@web1:~$ sudo systemctl stop nginx # oprire acum
anna@web1:~$ sudo systemctl restart nginx # oprire și repornire
anna@web1:~$ sudo systemctl reload nginx # recitirea configurației fără oprireDiferența dintre restart și reload este importantă în practică. La un restart serviciul se oprește pentru scurt timp: conexiunile active sunt întrerupte, iar dacă noua configurație conține o eroare, serviciul nu mai pornește și site-ul dumneavoastră cade. La un reload serviciul își citește din nou configurația în timp ce continuă să ruleze; dacă configurația conține o eroare, nginx o păstrează pe cea veche. Prin urmare, pentru nginx, Caddy, SSH și fail2ban folosiți după o modificare a configurației reload și testați mai întâi configurația (nginx -t, sshd -t, fail2ban-client -t). Nu toate serviciile acceptă reload; systemctl reload-or-restart alege singur.
La boot: enable și disable
A porni un serviciu și a-l configura să „pornească la boot” sunt două lucruri diferite:
anna@web1:~$ sudo systemctl enable nginx # pornește de acum la fiecare boot
anna@web1:~$ sudo systemctl disable nginx # nu mai pornește la boot
anna@web1:~$ sudo systemctl enable --now nginx # ambele: pornire acum și la boot
anna@web1:~$ systemctl is-enabled nginx
enabledO greșeală clasică: porniți un serviciu cu start, totul funcționează, iar după următoarea repornire (de exemplu din cauza unei actualizări de kernel, lecția 4.2) serviciul a dispărut. De aceea, pentru un serviciu nou folosiți enable --now.
Dacă doriți să fiți siguri că un serviciu nu pornește niciodată, nici măcar atunci când un alt serviciu îl solicită, există mask: sudo systemctl mask <dienst>. Anulați cu unmask.
Ce nu funcționează?
O singură comandă afișează toate unitățile eșuate:
anna@web1:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● php8.4-fpm.service loaded failed failed The PHP 8.4 FastCGI Process Manager
1 loaded units listed.Faceți din aceasta un obicei, de exemplu după fiecare repornire și după fiecare upgrade (lecția 4.3): lista ar trebui să fie goală. După rezolvarea problemei, eliminați mesajul cu sudo systemctl reset-failed.
O imagine de ansamblu a tuturor serviciilor care rulează:
anna@web1:~$ systemctl list-units --type=service --state=runningDacă rulează ceva ce nu cunoașteți sau nu folosiți, aflați ce este. Fiecare serviciu care nu este necesar reprezintă o suprafață de atac inutilă (lecția 5.1 și 10.1).
Fișiere de unitate și drop-in-uri
Un fișier de unitate este un fișier text. Versiunea din pachet se află în /usr/lib/systemd/system/ (pe sisteme mai vechi /lib/systemd/system/). Pe aceasta nu o modificați niciodată: o actualizare a pachetului o suprascrie. Modificările proprii le puneți într-un drop-in: un fișier mic care conține doar rândurile pe care doriți să le schimbați. Cel mai simplu este cu:
anna@web1:~$ sudo systemctl edit nginxSe deschide un editor cu o zonă goală între două rânduri de comentariu. Ce scrieți acolo ajunge în /etc/systemd/system/nginx.service.d/override.conf. De exemplu: repornirea automată a nginx dacă se oprește neașteptat.
[Service]
Restart=on-failure
RestartSec=5sDupă salvare, systemctl edit reîncarcă automat configurația systemd. Dacă editați un fișier de unitate în alt mod, rulați singuri:
anna@web1:~$ sudo systemctl daemon-reload
anna@web1:~$ sudo systemctl restart nginxdaemon-reload face ca systemd să citească din nou fișierele de unitate; serviciul în sine trebuie apoi repornit pentru a folosi modificarea. Rezultatul complet (originalul plus drop-in-urile) îl vedeți cu systemctl cat nginx.
Restart=on-failure este un obicei bun pentru serviciile importante. Dar nu ascundeți cu el o eroare reală: un serviciu care se blochează la fiecare cinci secunde și repornește trebuie investigat în jurnal. systemd renunță la repornire după câteva eșecuri rapide consecutive (limita implicită este de cinci porniri în zece secunde) și marchează serviciul ca failed.
Pe AlmaLinux și Rocky Linux
systemd și systemctl funcționează exact la fel. Doar numele serviciilor diferă uneori: serviciul SSH se numește sshd, serverul web din distribuție se numește httpd (Apache) sau nginx, iar firewall-ul firewalld.
În practică
Panoul VPS al furnizorului dumneavoastră (la WebOké și în alte părți) poate opri întregul server, îl poate reporni sau îl poate „opri forțat”. Aceasta din urmă echivalează cu scoaterea din priză: serviciile nu au ocazia să se oprească ordonat, iar o bază de date se poate deteriora. În interiorul serverului folosiți sudo systemctl reboot sau sudo shutdown -h now, iar în panou butonul obișnuit de oprire sau repornire.
Rezumat
- systemd pornește și supraveghează toate serviciile; îl comandați cu
systemctl. systemctl statusarată dacă un serviciu rulează, dacă pornește la boot, precum și ultimele rânduri din jurnal.start/stop/restartse aplică pentru acum,enable/disablepentru boot; folosițienable --nowpentru un serviciu nou.- După o modificare a configurației: mai întâi testați, apoi
reload;systemctl --failedar trebui să fie gol. - Nu modificați niciodată fișierul de unitate al unui pachet, ci folosiți un drop-in cu
systemctl edit.
Test (quiz)
Exercițiu
Exercițiul O6.1: Inventarul serviciilor dumneavoastră. Faceți pe serverul dumneavoastră o listă cu toate serviciile care rulează (systemctl list-units --type=service --state=running) și verificați dacă systemctl --failed este gol. Notați pentru fiecare serviciu ce face și dacă aveți nevoie de el. Pentru un serviciu pe care nu îl cunoșteați, aflați ce este (systemctl status, man). Apoi setați pentru un serviciu important Restart=on-failure într-un drop-in și verificați cu systemctl cat că setarea este prezentă.
Exercițiul O6.1: Inventarul serviciilor dumneavoastră
Acest exercițiu îl faceți singur; nimeni nu îl verifică. Bifați ce ați făcut și marcați exercițiul ca finalizat.
Un drop-in se află în /etc/systemd/system/<naam>.service.d/override.conf, nu în /usr/lib/systemd. La reload serviciul continuă să ruleze, iar nginx, de exemplu, păstrează configurația veche în caz de eroare; testați înainte cu nginx -t sau sshd -t. Servicii inutile: disable --now sau eliminați pachetul.
Bifele și notițele dumneavoastră rămân doar în acest browser; nu le trimitem nicăieri. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că ați finalizat exercițiul.
Lecturi suplimentare
- Manualul
systemctl(1): https://manpages.debian.org/trixie/systemd/systemctl.1.en.html - Manualul
systemd.service(5)(Restart=): https://manpages.debian.org/trixie/systemd/systemd.service.5.en.html - Manualul
systemd.unit(5)(drop-in-uri): https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html
