5 motivi per cui gli amministratori di sistema amano systemd

Come sanno gli amministratori di sistema, succede molto sui computer moderni. Le applicazioni vengono eseguite in background, gli eventi automatizzati aspettano di essere attivati ​​a un determinato momento, i file di registro vengono scritti, i rapporti sullo stato vengono consegnati. Tradizionalmente, questi processi disparati sono stati gestiti e monitorati con una raccolta di strumenti Unix con grande efficacia e grande efficienza. Tuttavia, i computer moderni sono diversi, con servizi locali in esecuzione insieme ad applicazioni containerizzate, facile accesso ai cloud e ai cluster su cui vengono eseguiti, processi in tempo reale e più dati da elaborare che mai.

Avere un metodo unificato per gestirli è un'aspettativa per gli utenti e un utile lusso per gli amministratori di sistema impegnati. Per questa attività non banale, il demone di sistema o systemd , è stato sviluppato e adottato rapidamente da tutte le principali distribuzioni Linux.

Altro sugli amministratori di sistema

• Abilita blog Sysadmin
• The Automated Enterprise:una guida alla gestione dell'IT con l'automazione
• eBook:Ansible Automation per SysAdmins
• Racconti dal campo:una guida per l'amministratore di sistema all'automazione IT
• eBook:una guida a Kubernetes per SRE e amministratori di sistema
• Ultimi articoli sull'amministratore di sistema

Naturalmente, systemd non è l'unico modo per gestire un sistema Linux. Esistono molti sistemi init alternativi, inclusi sysvinit, OpenRC, runit, s6 e persino BusyBox, ma systemd tratta Linux come un insieme di dati unificato, pensato per essere manipolato e interrogato in modo coerente con strumenti robusti. Per un amministratore di sistema impegnato e molti utenti, la velocità e la facilità di systemd sono una caratteristica importante. Ecco cinque motivi.

Gestione dell'avvio

L'avvio di un computer Linux può essere un evento sorprendentemente raro, se vuoi che lo sia. Certamente nel mondo dei server, i tempi di attività sono spesso contati in anni piuttosto che mesi o settimane. Laptop e desktop tendono a essere spenti e avviati abbastanza frequentemente, anche se è probabile che anche questi vengano sospesi o ibernati come devono essere spenti. In ogni caso, il tempo trascorso dall'evento di avvio più recente può fungere da una sorta di gestore di sessione per un controllo dello stato del computer. È un modo utile per limitare i dati che guardi durante il monitoraggio del sistema o la diagnosi di problemi.

Nel probabile caso in cui non ricordi l'ultima volta che hai avviato il computer, puoi elencare le sessioni di avvio con lo strumento di registrazione di systemd, journalctl :

$ journalctl --list-boots

-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23 

-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13 

[...]

-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29

 0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08

Le ultime sessioni di avvio vengono visualizzate in fondo all'elenco, quindi puoi reindirizzare l'output a tail solo per gli stivali più recenti.

I numeri a sinistra (42, 41, 1 e 0 in questo esempio) sono numeri di indice per ciascuna sessione di avvio. In altre parole, per visualizzare i registri solo per una specifica sessione di avvio, puoi utilizzare il suo numero di indice come riferimento.

Registra le recensioni

L'analisi dei log è un metodo importante per estrapolare informazioni sul tuo sistema. I registri forniscono una cronologia di gran parte delle attività svolte dal computer senza la tua supervisione diretta. Puoi vedere quando i servizi sono stati avviati, quando sono stati eseguiti i lavori a tempo, quali servizi sono in esecuzione in background, quali attività non sono riuscite e altro ancora. Uno dei passaggi iniziali più comuni per la risoluzione dei problemi è la revisione dei registri, operazione facile da eseguire con journalctl :

$ journalctl --pager-end

Il --pager-end (o -e in breve) l'opzione avvia la visualizzazione dei log alla fine del journalctl output, quindi devi scorrere verso l'alto per vedere gli eventi accaduti in precedenza.

Systemd mantiene un "catalogo" di errori e messaggi pieni di record di errori, possibili soluzioni, suggerimenti ai forum di supporto e documentazione per sviluppatori. Ciò può fornire un contesto importante a un evento del registro, che altrimenti potrebbe essere un punto di confusione in un mare di messaggi o, peggio, potrebbe passare del tutto inosservato. Per integrare i messaggi di errore con testo esplicativo, puoi utilizzare il --catalog (o -x in breve) opzione:

$ journalctl --pager-end --catalog

Per limitare ulteriormente l'output del registro che devi attraversare, puoi specificare per quale sessione di avvio desideri visualizzare i registri. Poiché ogni sessione di avvio è indicizzata, puoi specificare determinate sessioni con --boot opzione e visualizzare solo i log che si applicano ad essa:

$ journalctl --pager-end --catalog --boot 42

Puoi anche vedere i registri per un'unità di sistema specifica. Ad esempio, per risolvere un problema con il tuo servizio Secure Shell (SSH), puoi specificare --unit sshd per vedere solo i log che si applicano a sshd demone:

$ journalctl --pager-end \

--catalog --boot 42 \

--unit sshd

Gestione del servizio

Il primo compito di systemd è avviare il computer e generalmente lo fa in modo rapido, efficiente ed efficace. Ma il compito che non finisce mai è la gestione del servizio. In base alla progettazione, systemd garantisce che i servizi che si desidera eseguire vengano effettivamente avviati e continuino a essere eseguiti durante la sessione. Questo è abbastanza robusto, perché in teoria anche un servizio bloccato può essere riavviato senza il tuo intervento.

La tua interfaccia per aiutare systemd a gestire i servizi è systemctl comando. Con esso, puoi visualizzare i file di unità che definiscono un servizio:

$ systemctl cat sshd

# /usr/lib/systemd/system/sshd.service

[Unit]

Description=OpenSSH server daemon

Documentation=man:sshd(8) man:sshd_config(5)

After=network.target sshd-keygen.target

Wants=sshd-keygen.target



[Service]

Type=notify

EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config

EnvironmentFile=-/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

RestartSec=42s



[Install]

WantedBy=multi-user.target

La maggior parte dei file di unità esiste in /usr/lib/systemd/system/ ma, come con molte configurazioni importanti, sei incoraggiato a modificarle con modifiche locali. C'è anche un'interfaccia per questo:

$ systemctl edit sshd

Puoi vedere se un servizio è attualmente attivo:

$ systemctl is-active sshd

active

$ systemctl is-active foo

inactive

Allo stesso modo, puoi vedere se un servizio ha fallito con is-failed .

L'avvio e l'arresto dei servizi è molto intuitivo:

$ systemctl stop sshd

$ systemctl start sshd

E consentire a un servizio di avviarsi all'avvio è semplice:

$ systemctl enable sshd

Aggiungi il --now opzione per abilitare l'avvio di un servizio all'avvio o per avviarlo per la sessione corrente.

Timer

Molto tempo fa, quando volevi automatizzare un'attività su Linux, lo strumento canonico per il lavoro era cron . C'è ancora un posto per il comando cron, ma ci sono anche alcune alternative interessanti. Ad esempio, l'anacron command è un sistema versatile simile a cron in grado di eseguire attività che altrimenti sarebbero state perse durante i tempi di inattività.

Gli eventi programmati sono poco più che servizi attivati ​​in un momento specifico, quindi systemd gestisce una funzione simile a cron chiamata timer. Puoi elencare i timer attivi:

$ systemctl list-timers

NEXT                          LEFT       

Tue 2021-03-30 12:37:54 NZDT  16min left [...]

Wed 2021-03-31 00:00:00 NZDT  11h left [...]

Wed 2021-03-31 06:42:02 NZDT  18h left [...]



3 timers listed.

Pass --all to see loaded but inactive timers, too.

Puoi abilitare un timer nello stesso modo in cui abiliti un servizio:

$ systemctl enable myMonitor.timer

Obiettivi

I target sono l'ultimo componente principale della matrice systemd. Un target è definito da un file unit, lo stesso di servizi e timer. I target possono anche essere avviati e abilitati allo stesso modo. Ciò che rende gli obiettivi unici è che raggruppano altri file di unità in modo arbitrariamente significativo. Ad esempio, potresti eseguire l'avvio da una console di testo anziché da un desktop grafico, quindi multi-user l'obiettivo esiste. Tuttavia, il multi-user target è solo il graphical target senza i file dell'unità desktop come dipendenze.

In breve, i target sono un modo semplice per raccogliere servizi, timer e persino altri target insieme per rappresentare uno stato previsto per la tua macchina.

In effetti, all'interno di systemd, un riavvio, uno spegnimento o un'azione di spegnimento sono solo un altro obiettivo.

Puoi elencare tutti i target disponibili usando list-unit-files opzione, vincolandola con il --type opzione impostata su target :

$ systemctl list-unit-files --type target

Prendere il controllo con systemd

Linux moderno utilizza systemd per la gestione dei servizi e l'introspezione dei log. Fornisce di tutto, dai sistemi Linux personali ai server aziendali, con un meccanismo moderno per il monitoraggio e una facile manutenzione. Più lo usi, più systemd diventa comodamente prevedibile e intuitivo e più scopri come parti disparate del tuo sistema sono interconnesse.

Per conoscere meglio systemd, devi usarlo. E per prendere confidenza con l'utilizzo, scarica il nostro cheat sheet e consultalo spesso.