Când un server Linux pornește „aproape bine”, problemele apar exact acolo unde ordinea serviciilor a fost gândită superficial: aplicația pornește înainte ca volumul să fie montat, containerul vine înainte ca runtime-ul să fie pregătit sau serviciul așteaptă inutil rețeaua și încetinește tot boot-ul. În systemd, dependențele nu înseamnă doar cine pornește primul, ci și cine trebuie să existe, cine poate întârzia și cine trebuie oprit împreună cu alt serviciu.
Prima confuzie apare între network.target și network-online.target. Documentația systemd explică limpede că network.target indică faptul că stack-ul de rețea a fost pornit, nu că interfața are deja conectivitate utilă. Cu alte cuvinte, dacă o aplicație trebuie doar să se oprească ordonat după rețea, After=network.target este de obicei suficient. Dacă însă serviciul depinde de o adresă configurată și de conectivitate reală la pornire — de exemplu pentru a accesa un API, o bază de date la distanță sau un storage de rețea — atunci are sens combinația Wants=network-online.target și After=network-online.target. Important: network-online.target adaugă un punct de sincronizare și poate întârzia boot-ul, deci nu trebuie folosit din reflex.
Al doilea punct critic este stocarea. Pentru volume locale, systemd adaugă implicit relații către local-fs.target, însă pentru aplicațiile care depind de o cale concretă este mai sigur să descrii explicit relația cu RequiresMountsFor=/calea/de/date. Conform documentației systemd.unit, această opțiune adaugă automat Requires= și After= pentru mount-urile necesare acelei căi. Practic, în loc să legi manual o aplicație de mai multe unități .mount, legi serviciul de directorul de care are nevoie. Pentru volume de rețea, systemd.mount precizează că mount-urile de tip network primesc automat relații cu network.target, network-online.target și remote-fs.target, ceea ce reduce mult nevoia de improvizații în fișierele de service.
Containerele complică lucrurile pentru că introduc încă un strat între storage și aplicație. Dacă folosești Docker, documentația oficială arată că daemonul poate fi activat la boot prin systemctl enable docker.service și containerd.service, dar asta nu înseamnă automat că aplicația ta trebuie să depindă doar de docker.service. În practică, dacă rulezi o aplicație într-un container, relația corectă este adesea față de unitatea containerului, nu doar față de engine. La Podman, documentația pentru unități systemd arată și un alt detaliu important: pornirea poate depăși limita implicită de 90 de secunde dacă imaginea trebuie trasă la boot, caz în care e recomandată preluarea imaginii în avans sau ajustarea TimeoutStartSec.
Pentru administratori, regula sănătoasă este aceasta: folosește After= pentru ordine, Requires= când lipsa unei componente trebuie să oprească pornirea, Wants= când dependența este dorită dar nu obligatorie și PartOf= când vrei ca restartul sau oprirea unui serviciu principal să se propage către cel secundar. BindsTo= trebuie folosit mai atent, doar atunci când un serviciu nu are voie să rămână activ fără unitatea de care depinde. Documentația systemd avertizează că această relație este mai strictă decât Requires=.
O schemă sigură pentru multe medii de producție arată astfel: storage-ul local sau de rețea este montat corect prin unități dedicate sau prin fstab compatibil cu systemd, runtime-ul de containere pornește separat, containerul depinde de volumele de care are nevoie, iar aplicația din afara containerului sau serviciul auxiliar depinde de containerul concret, nu de presupuneri despre „starea generală” a sistemului. Astfel eviți unități fragile, cu sleep-uri artificiale sau bucle de retry ascunse.
Înainte să modifici dependențele, merită să verifici ce vede deja systemd. Comenzi precum systemctl list-dependencies nume-serviciu și systemd-analyze critical-chain sunt utile pentru diagnostic și nu schimbă nimic în sistem. Dacă observi că un serviciu așteaptă inutil rețeaua, folosește o dependență mai slabă. Dacă pornește prea devreme față de un volum, descrie explicit calea cu RequiresMountsFor=. Dacă un container întârzie pentru că trage imaginea la boot, mută acel pas în procesul de actualizare, nu în secvența de pornire.
Pe scurt, ordinea corectă în systemd nu se obține prin cât mai multe dependențe, ci prin dependențe precise. Cu cât legi mai clar rețeaua, volumele, containerele și aplicațiile de ceea ce folosesc în realitate, cu atât sistemul pornește mai previzibil, se repară mai ușor și produce mai puține incidente greu de explicat.
