systemd vs init.d: differenze pratiche

systemd ha sostituito SysV init in tutte le principali distribuzioni Linux: Debian, Ubuntu, RHEL, Fedora, Arch, SUSE. Capire le differenze pratiche e indispensabile per chi gestisce server, scrive servizi custom o lavora su sistemi legacy.

SysV init: l'approccio classico

L'init storico esegue script in /etc/init.d/ in modo sequenziale, controllati da runlevel (0-6). Ogni script e un file shell che implementa start/stop/restart/status. La sequenza di avvio e lenta (un servizio alla volta) e gli errori sono difficili da diagnosticare.

systemd: orchestrazione moderna

systemd e PID 1 con un modello dichiarativo. I servizi sono unit in /etc/systemd/system/ o /lib/systemd/system/. Supporta parallelismo di avvio, socket activation (servizi avviati su richiesta), cgroup nativi, journal centralizzato, dipendenze esplicite, timer sostituti di cron.

Comandi essenziali

• systemctl start nginx: avvia un servizio.
• systemctl enable --now nginx: avvia e abilita al boot.
• systemctl status nginx: stato dettagliato.
• systemctl restart nginx: riavvio.
• systemctl daemon-reload: ricarica unit modificate.
• journalctl -u nginx -f: log in tempo reale.
• systemctl list-units --failed: servizi in errore.

Anatomia di una unit

Una .service ha tre sezioni: [Unit] con Description, After, Requires; [Service] con ExecStart, Restart, User, WorkingDirectory; [Install] con WantedBy. La gestione cgroup (limiti memoria/CPU) si fa con direttive MemoryMax, CPUQuota, TasksMax.

Procedura passo-passo per migrare uno script init.d

1. Identifica le funzioni start/stop/reload nello script.
2. Identifica il binario e gli argomenti effettivi.
3. Crea /etc/systemd/system/myservice.service.
4. Definisci [Unit] con Description e After=network.target.
5. In [Service] imposta Type, ExecStart, ExecStop, Restart=on-failure.
6. Imposta User/Group dedicati per privilegi minimi.
7. Aggiungi [Install] con WantedBy=multi-user.target.
8. Lancia systemctl daemon-reload e systemctl enable --now myservice.
9. Verifica log con journalctl -u myservice.

Vantaggi pratici di systemd

• Restart automatico con backoff.
• Logging centralizzato via journal.
• Avvio più veloce grazie al parallelismo.
• Resource control nativo.
• Socket/path/timer activation per servizi on-demand.

Errori comuni e come risolverli

• Dimenticare daemon-reload dopo modifica unit: cambi non applicati.
• Type sbagliato: simple per default, forking per demon che si distaccano.
• Logging non visibile: assicurati che StandardOutput sia journal.
• Symlink in /etc/init.d con compatibilità: lavora sempre sull'unit nativa.

Domande frequenti

D: Posso ancora usare script init.d?
R: Si tramite shim di compatibilità, ma sconsigliato per nuovi servizi.

D: systemd e su Alpine?
R: No, Alpine usa OpenRC. Su container minimal anche.

D: timer systemd e meglio di cron?
R: Si per logging, dipendenze e gestione integrata; cron resta semplice per task one-shot.

Approfondimento tecnico: socket e timer activation

La socket activation e un pattern systemd potente: un demone non viene avviato finché non arriva una connessione sulla sua socket. systemd ascolta in vece sua e fa "handoff" del file descriptor quando serve. Riduce uso memoria per servizi raramente usati e abilita avvio parallelo. Esempio: sshd.socket + sshd@.service avvia sshd solo on demand.

I timer sono il cron systemd-native, ma con vantaggi: dipendenze esplicite (es. Requires=network-online.target), retry automatici (OnFailure=), specifica calendario molto più espressiva, logging integrato in journal. Una unit .timer attiva una .service: separazione di scheduling e azione.

Scenari d'uso reali

Un backup quotidiano migra da cron a systemd timer: log centralizzati, retry on failure, dipendenze da network e mount remoto chiaramente espresse.

Un servizio web ad alta concorrenza usa socket activation per scalare orizzontalmente in template @.service.

Un laptop developer usa unit user (~/.config/systemd/user/) per ricarica automatica di servizi locali.

Checklist operativa systemd

• daemon-reload dopo ogni modifica di unit.
• Type corretto (simple, forking, notify) per ogni servizio.
• Restart=on-failure con backoff appropriato.
• User/Group dedicati per privilegi minimi.
• MemoryMax e CPUQuota per resource control.
• Logging in journal con StandardOutput=journal.
• Verifica con systemctl list-units --failed.

Risorse e riferimenti

freedesktop.org/wiki/Software/systemd. systemd by example tutorial. Man pages: systemd.unit, systemd.service, systemd.timer. systemctl edit per drop-in override. Per debugging: systemd-analyze blame, systemd-analyze critical-chain.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su systemd vs init.d richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.