Sembra un po’ il mood del momento, ma dopo il bootloader e le home directory oramai pare che il buon systemd stia diventando il punto di controllo di tutto.

Questa settimana è il turno di GNOME che ha annunciato come, dalla versione 3.34 rilasciata il mese scorso, la sessione del famoso Desktop Environment sarà ora gestita interamente da systemd. Perchè interamente? Perchè al momento già utilizzava un’istanza personale di systemd per le applicazioni che utilizzavano DBus per le comunicazioni tra processi.

Cosa cambia dunque? Per gli utenti finali praticamente nulla, ma sotto il cofano parecchio. Ma andiamo sul tecnico: se siete su un sistema gestito da systemd al vostro utente sono già stati assegnati due componenti:

• una Systemd.Slice (di fatto un CGroup dedicato al vostro utente da cui tutti i processi attingono risorse)
• un Systemd.Scope (un metodo interno di systemd che permette di raggruppare processi al fine di limitare la loro visibilità, ad esempio, ad una singola Systemd.Slice)

Per fare un esempio pratico, la sessione del vostro utente viene eseguita all’interno di questo Systemd.Scope. Inoltre, se andate a vedere alle Unit di systemd, vedrete anche un user@X.service (dove X è l’UID dell’utente), ovvero l’istanza di systemd dedicata al vostro utente (e che viene stoppata nel momento in cui il vostro utente non è più loggato al sistema).

Come dicevamo, prima di questa release di GNOME le applicazioni parte del desktop che necessitavano di DBus venivano eseguite all’interno del Systemd.Scope dell’utente, il che si traduceva (se consideriamo una media di sessione in uso) in qualcosa di più di 200 processi al suo interno (esatto, solo per il Desktop Environment). Spostando l’intera sessione dentro questo componente di systemd (invece che le singole applicazioni), il numero di processi si riduce a 4, il che rende più snella la gestione degli stessi da parte di systemd, ma un pochino più difficile identificare di quale sessione uno specifico processo fa parte.

Dall’altra parte, è possibile ora utilizzare i comandi systemd per controllare anche le sessioni di GNOME, permettendo quindi di unificare la gestione delle utenze (in termini di sessioni) indipendentemente dal fatto che una login sia testuale o con interfaccia grafica (ad esempio utilizzando loginctl).

Altro vantaggio è la gestione dei log, che adesso potrà essere fatta utilizzando il consueto comando journalctl, unificando anche quella gestione.

Insomma, che sia un bene o un male, che piaccia o meno questo “centro stella” che sta diventando il sistema di Lennart Poettering, il passaggio a systemd sembra portare per lo meno uniformità nell’uso del sistema.

Per maggiori informazioni vi rimandiamo all’articolo nel blog di GNOME in cui si parla in maniera più dettagliata delle novità. Cosa ne pensate di questo ulteriore passaggio?

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.