Difference between revisions of "Systemd/User (Italiano)"

From ArchWiki
Jump to: navigation, search
m (Utilizzare {{ic|systemd --user}} per gestire la propria sessione)
(Nota per le applicazioni X11)
(14 intermediate revisions by the same user not shown)
Line 20: Line 20:
 
Si faccia gestire la propria sessione da {{ic|systemd-logind}}. Se [[systemd (Italiano)|systemd]] è stato eseguito come sistema di init, allora non è necessario compiere alcuna operazione.
 
Si faccia gestire la propria sessione da {{ic|systemd-logind}}. Se [[systemd (Italiano)|systemd]] è stato eseguito come sistema di init, allora non è necessario compiere alcuna operazione.
  
L'utente dovrà ora lanciare un'istanza di systemd inserendo quanto segue nel proprio {{ic|~/.xinitrc}}, '''prima della riga che inizia con exec''' (si noti che questo comando avrà effetto solo se si avvia il proprio DE/WM tramite {{ic|startx}} o {{ic|xinit}}):
+
L'utente dovrà ora lanciare un'istanza di systemd inserendo quanto segue nel proprio {{ic|~/.xinitrc}}:
  
systemd --user &
+
{{bc|/usr/lib/systemd/systemd --user &}}
 +
 
 +
Se l'utente non lancia il proprio window manager tramite {{ic|/usr/lib/systemd/systemd --user}}, sarà invece necessario inserire {{ic|systemd --user &}} in modo da lanciare systemd come qualsiasi altra applicazione prima di eseguire il window manager.
  
 
Dopo l'avvio di X, è possibile controllare se la sessione è gestita da {{ic|systemd-logind}} utilizzando il seguente comando:
 
Dopo l'avvio di X, è possibile controllare se la sessione è gestita da {{ic|systemd-logind}} utilizzando il seguente comando:
Line 32: Line 34:
 
===Display Managers===
 
===Display Managers===
  
I principali Display Manager utilizzano {{ic|systemd-logind}} di default, perciò il comando {{ic|loginctl}} menzionato nella sezione precedente dovrebbe funzionare come previsto. Sarà semplicemente necessario aggiungere {{ic|systemd --user}} all'elenco dei programmi che l'ambiente desktop avvia automaticamente.
+
I principali Display Manager utilizzano {{ic|systemd-logind}} di default, perciò il comando {{ic|loginctl}} menzionato nella sezione precedente dovrebbe funzionare come previsto. Sarà semplicemente necessario aggiungere {{ic|/usr/lib/systemd/systemd --user}} all'elenco dei programmi che l'ambiente desktop avvia automaticamente.
  
 
====GNOME 3 (Utilizzando GDM)====
 
====GNOME 3 (Utilizzando GDM)====
  
Gli utenti che desiderano che GDM 3 avvii automaticamente la propria sessione di {{ic|systemd --user}} devono semplicemente creare una sessione di login speciale:
+
Gli utenti che desiderano che GDM 3 avvii automaticamente la propria sessione di {{ic|/usr/lib/systemd/systemd --user}} devono semplicemente creare una sessione di login speciale:
  
 
{{hc|/usr/share/xsessions/gnome-systemd.desktop|<nowiki>
 
{{hc|/usr/share/xsessions/gnome-systemd.desktop|<nowiki>
Line 50: Line 52:
 
{{Nota|Quanto sopra è stato testato con una installazione pura di GNOME 3 e GDM. In caso di configurazioni alternative, la vostra esperienza potrebbe variare. Questo metodo non richiede l'installazione degli script user-session di systemd.}}
 
{{Nota|Quanto sopra è stato testato con una installazione pura di GNOME 3 e GDM. In caso di configurazioni alternative, la vostra esperienza potrebbe variare. Questo metodo non richiede l'installazione degli script user-session di systemd.}}
  
===Utilizzare {{ic|systemd --user}} per gestire la propria sessione===
+
===Utilizzare {{ic|/usr/lib/systemd/systemd --user}} per gestire la propria sessione===
  
 
Systemd ha molte caratteristiche utili, una delle quali è la capacità di tracciare i programmi utilizzando i cgroups (si esegua {{ic|systemctl status}}). Benchè ciò sia veramente utile per un sistema di init il cui processo ha '''pid 1''', anche la modalità utente può avvalersi di questa caratteristica per avviare automaticamente i programmi dello stesso, tracciando al tempo stesso il contenuto di ogni cgroup.
 
Systemd ha molte caratteristiche utili, una delle quali è la capacità di tracciare i programmi utilizzando i cgroups (si esegua {{ic|systemctl status}}). Benchè ciò sia veramente utile per un sistema di init il cui processo ha '''pid 1''', anche la modalità utente può avvalersi di questa caratteristica per avviare automaticamente i programmi dello stesso, tracciando al tempo stesso il contenuto di ogni cgroup.
Line 64: Line 66:
 
Description=Window manager target
 
Description=Window manager target
 
Wants=xorg.target
 
Wants=xorg.target
Wants=myStuff.target
+
Wants=mystuff.target
 
Requires=dbus.socket
 
Requires=dbus.socket
 
AllowIsolate=true
 
AllowIsolate=true
Line 83: Line 85:
 
</nowiki>}}
 
</nowiki>}}
  
Si crei un link simbolico di nome {{ic|default.target}}, che punta al target di cui sopra. Quando si esegue {{ic|systemd --user}}, questo sarà il target avviato.
+
Si crei un link simbolico di nome {{ic|default.target}}, che punta al target di cui sopra. Quando si esegue {{ic|/usr/lib/systemd/systemd --user}}, questo sarà il target avviato.
  
 
Infine, si scrivano i vari files .service corrispondenti ai servizi da avviare. Si inizi con quello del window manager:
 
Infine, si scrivano i vari files .service corrispondenti ai servizi da avviare. Si inizi con quello del window manager:
Line 106: Line 108:
 
</nowiki>}}
 
</nowiki>}}
  
{{Nota|La sezione {{ic|[Install]}} include il valore {{ic|WantedBy}}, che permetterà al servizio di essere linkato come {{ic|$HOME/.config/systemd/user/wm.target.wants/VOSTRO_WM.service}}, quando si utilizza {{ic|systemd --user enable}}, consentendone l'avvio al login. È consigliabile abilitare questo servizio con systemctl e non linkarlo manualmente.}}
+
{{Nota|La sezione {{ic|[Install]}} include il valore {{ic|WantedBy}}, che permetterà al servizio di essere linkato come {{ic|$HOME/.config/systemd/user/wm.target.wants/VOSTRO_WM.service}}, quando si utilizza {{ic|systemctl --user enable}}, consentendone l'avvio al login. È consigliabile abilitare questo servizio con systemctl e non linkarlo manualmente.}}
  
 
È ora possibile riempire la directory delle unità con tutti i servizi di cui si potrebbe aver bisogno, come ad esempio '''mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys''' e '''xmodmap'''.
 
È ora possibile riempire la directory delle unità con tutti i servizi di cui si potrebbe aver bisogno, come ad esempio '''mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys''' e '''xmodmap'''.
Line 114: Line 116:
 
Se si vuole utilizzare il login automatico al boot, è possibile utilizzare la relativa unit fornita dal pacchetto {{Aur|user-session-units}}. Si consideri l'idea di abilitare uno screen locker per evitare che qualcuno possa avvalersi della sessione appena avviata.
 
Se si vuole utilizzare il login automatico al boot, è possibile utilizzare la relativa unit fornita dal pacchetto {{Aur|user-session-units}}. Si consideri l'idea di abilitare uno screen locker per evitare che qualcuno possa avvalersi della sessione appena avviata.
  
Se si è installato il pacchetto {{Aur|user-session-units}}, sarà necessario copiare {{ic|user-session@service}} in {{ic|/etc/systemd/system}} e modificarlo cambiando la seguente linea:
+
Si aggiunga questa linea ai files {{ic|/etc/pam.d/login}} e {{ic|/etc/pam.d/system-auth}}:
  
  Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
+
  session    required    pam_systemd.so
  
In:
+
Dal momento che {{ic|user-session@.service}} viene avviato sulla tty1, sarà necessario aggiungere {{ic|1=Conflicts=getty@tty1.service}} al .service in questione, se non è già presente.
  
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket
+
Una volta fatto quanto sopra, si esegua {{ic|systemctl --user enable}} {{ic|WM_SCELTO.service}}
  
{{Nota|Si noti la modifica di {{ic|%I}} in {{ic|%U}}.}}
+
{{Nota|È necessario prestare attenzione alle tty, in modo che la sessione di systemd sia marcata come attiva. Una sessione viene segnata come inattiva quando la tty nella quale ci si trova è diversa da quella in cui è stato effettuato il login, il che significa che il server X dovrà essere avviato nella stessa tty specificata in {{ic|user-session@.service}}, altrimenti potrebbero verificarsi diversi problemi con le applicazioni grafiche, come l'impossibilità di montare dispositivi removibili USB.}}
  
Si modifichi anche la sezione {{ic|[Install]}}:
+
Una delle cose più importanti da aggiungere ai propri .service è l'utilizzo di {{ic|1=Before=}} e {{ic|1=After=}} nella sezione {{ic|[Unit]}}, che permettono di determinare l'ordine di avvio dei servizi.
 +
Si supponga di disporre di una applicazione grafica che si vuole avviare al boot: sarà possibile farlo aggiungendo {{ic|1=After=xorg.target}} al proprio .service.
 +
Si supponga inoltre di voler avviare {{ic|ncmpcpp}} che richiede {{ic|mpd}} per funzionare: in tal caso si dovrà aggiungere {{ic|1=After=mpd.service}} al .service di {{ic|ncmpcpp}}.
  
[Install]
+
Col tempo e l'esperienza si capirà come gestire l'ordine di avvio delle applicazioni, oppure leggendo le pagine di man di systemd. Iniziare con [http://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)] è una buona idea.
WantedBy=graphical.target
+
  
O, se non si utilizza un login manager:
+
===Altri casi d'uso===
  
 +
====Multiplexer di terminale persistente====
 +
 +
Si potrebbe voler utilizzare la propria sessione utente per avviare un multiplexer di terminale come [[GNU Screen|GNU Screen]] o [[Tmux|Tmux]] in background invece di una sessione grafica. La separazione del login dal login grafico è probabilmente utile solamente per gli utenti che effettuano il boot in TTY invece di utilizzare un display manager (nel cui caso è possibile inserire tutti i programmi da avviare nel target {{ic|mystuff.target}}).
 +
 +
Per creare questo tipo di sessione utente si proceda come sopra, creando però {{ic|multiplexer.target}} invece di {{ic|wm.target}}:
 +
 +
[Unit]
 +
Description=Terminal multiplexer
 +
Documentation=info:screen man:screen(1) man:tmux(1)
 +
After=cruft.target
 +
Wants=cruft.target
 +
 
  [Install]
 
  [Install]
  WantedBy=getty.target
+
  Alias=default.target
  
Sarà necessario patchare systemd per utilizzare questa funzionalità, utilizzando '''systemd-git''' dopo il [http://cgit.freedesktop.org/systemd/systemd/commit/?id=067d851d30386c553e3a84f59d81d003ff638b91 commit 067d851d] o patchandolo direttamente utilizzando [[Arch Build System (Italiano)|ABS]].
+
Il target {{ic|cruft.target}}, similmente a {{ic|mystuff.target}}, dovrebbe occuparsi dell'avvio di tutti quei programmi che si pensa debbano essere lanciati prima di tmux o screen (o che si intende avviare al boot indifferentemente dal momento di avvio), come una sessione demone di GnuPG.
La modifica dovrebbe essere inclusa in systemd a partire dalla versione 197.
+
  
Si aggiunga questa linea ai files {{ic|/etc/pam.d/login}} e {{ic|/etc/pam.d/system-auth}}:
+
Sarà quindi necessario creare un servizio per la propria sessione multiplexer. Di seguito un servizio di esempio che utilizza tmux ed effettua il source di una sessione di gpg-agent che scrive le proprie informazioni in {{ic|/tmp/gpg-agent-info}}. La sessione proposta è inoltre in grado di avviare programmi grafici previo avvio del server X, dal momento che la variabile {{ic|DISPLAY}} è impostata.
  
session    required    pam_systemd.so
+
{{bc|<nowiki>
 +
[Unit]
 +
Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
 +
After=gpg-agent.service
 +
Wants=gpg-agent.service
  
Dal momento che {{ic|user-session@.service}} viene avviato sulla tty1, sarà necessario aggiungere {{ic|1=Conflicts=getty@tty1.service}} al .service in questione.
+
[Service]
 +
Type=forking
 +
ExecStart=/usr/bin/tmux start
 +
ExecStop=/usr/bin/tmux kill-server
 +
Environment=DISPLAY=:0
 +
EnvironmentFile=/tmp/gpg-agent-info
  
Una delle cose più importanti da aggiungere ai propri .service è l'utilizzo di {{ic|1=Before=}} e {{ic|1=After=}} nella sezione {{ic|[Unit]}}, che permettono di determinare l'ordine di avvio dei servizi.
+
[Install]
Si supponga di disporre di una applicazione grafica che si vuole avviare al boot: sarà possibile farlo aggiungendo {{ic|1=After=xorg.target}} al proprio .service.
+
WantedBy=multiplexer.target
Si supponga inoltre di voler avviare {{ic|ncmpcpp}} che richiede {{ic|mpd}} per funzionare: in tal caso si dovrà aggiungere {{ic|1=After=mpd.service}} al .service di {{ic|ncmpcpp}}.
+
</nowiki>}}
  
Col tempo e l'esperienza si capirà come gestire l'ordine di avvio delle applicazioni, oppure leggendo le pagine di man di systemd. Iniziare con [http://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)] è una buona idea.
+
Una volta fatto, si esegua {{ic|systemctl --user activate}} su {{ic|tmux.service}}, {{ic|multiplexer.target}} ed eventuali altri servizi che debbano essere avviati da cruft.target. Si abiliti inoltre {{ic|user-session@.service}} come spiegato sopra, ma assicurarsi di rimuovere la linea {{ic|1=Conflicts=getty@tty1.service}}, dal momento che la propria sessione utente non gestirà una TTY.
 +
 
 +
Congratulazioni! Si dispone ora di un multiplexer di terminale ed altri programmi utili che vengono avviati automaticamente al boot!
 +
 
 +
=====Avviare X=====
 +
 
 +
Si avrà notato che, essendo il multiplexer di terminale il nuovo {{ic|default.target}}, X non sarà avviato automaticamente al boot. Per avviare X, si proceda come sopra ma non si attivi o linki manualmente {{ic|wm.target}} a {{ic|default.target}}, bensì utilizzare un semplice alias per {{ic|startx}}:
 +
 
 +
alias startx='systemctl --user start wm.target'
  
 
==Servizi Utente==
 
==Servizi Utente==
Line 194: Line 225:
  
 
Come spiegato in {{ic|man systemd.unit}}, la variabile {{ic|%h}} contiene il valore della home directory dell'utente che esegue il servizio. È possibile utilizzare altre variabili, il cui elenco è disponibile nelle pagine di man di systemd.
 
Come spiegato in {{ic|man systemd.unit}}, la variabile {{ic|%h}} contiene il valore della home directory dell'utente che esegue il servizio. È possibile utilizzare altre variabili, il cui elenco è disponibile nelle pagine di man di systemd.
 +
 +
===Nota per le applicazioni X11===
 +
 +
La maggior parte delle applicazioni grafiche richiedono che la variabile d'ambiente {{ic|DISPLAY}} sia impostata per essere avviate (se i propri servizi non si avviano, questa è la prima cosa da controllare). Assicurarsi quindi di includerla nei propri servizi:
 +
 +
{{hc|$HOME/.config/systemd/user/parcellite.service|<nowiki>
 +
 +
[Unit]
 +
Description=Parcellite clipboard manager
 +
 +
[Service]
 +
ExecStart=/usr/bin/parcellite
 +
Environment=DISPLAY=:0 # <= !
 +
 +
[Install]
 +
WantedBy=mystuff.target
 +
</nowiki>}}
 +
 +
Sarebbe però preferibile non inserire direttamente il valore della variabile {{ic|DISPLAY}} nei servizi (specialmente se si hanno più schermi):
 +
 +
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 +
 +
[Unit]
 +
Description=Your amazing and original description
 +
 +
[Service]
 +
ExecStart=/full/path/to/the/app
 +
Environment=DISPLAY=%i # <= !
 +
 +
[Install]
 +
WantedBy=mystuff.target
 +
</nowiki>}}
 +
 +
È ora possibile avviarli con:
 +
 +
systemctl --user {start|enable} x-app@display-in-uso.service # <= :0 nella maggior parte dei casi
 +
 +
Alcune applicazioni grafiche potrebbero non avviarsi correttamente poichè il display socket non è ancora disponibile. È possibile ovviare il proglema aggiungendo quanto segue ai propri servizi:
 +
 +
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 +
[Unit]
 +
After=xorg.target
 +
Requires=xorg.target
 +
 +
...
 +
</nowiki>}}
 +
 +
Il target {{ic|xorg.target}} fa parte del pacchetto {{AUR|xorg-launch-helper}}.
  
 
==Articoli correlati==
 
==Articoli correlati==
  
* [http://blog.gtmanfred.com/?p=26 guida originale di gtmanfred]
+
* [http://blog.gtmanfred.com/?p=26 guida originale di gtmanfred]{{Linkrot|2013|04|12}}
 
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home il wiki di KaiSforza, su BitBucket]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home il wiki di KaiSforza, su BitBucket]
 +
* [https://github.com/zoqaeski/systemd-user-units/wiki/home Wiki di zoqaeski su GitHub]
 
* [https://github.com/grawity/systemd-user-units Utile raccolta di units per systemd]
 
* [https://github.com/grawity/systemd-user-units Utile raccolta di units per systemd]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units Altre units utente per systemd]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units Altre units utente per systemd]

Revision as of 18:45, 12 June 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary end

systemd offre agli utenti la possibilità di eseguire un'istanza di systemd per gestire i propri processi e servizi, consentendo di avviare, fermare, abilitare e disabilitare le unità che si trovano in certe directory quando systemd viene eseguito dall'utente. Ciò è utile per demoni e altri servizi che comunemente non vengono avviati da root oppure utilizzano un utente apposito, come avviene con mpd.

Setup

startx

Nota: Questo passaggio non è necessario se si intende utilizzare l'autologin.

Si faccia gestire la propria sessione da systemd-logind. Se systemd è stato eseguito come sistema di init, allora non è necessario compiere alcuna operazione.

L'utente dovrà ora lanciare un'istanza di systemd inserendo quanto segue nel proprio ~/.xinitrc:

/usr/lib/systemd/systemd --user &

Se l'utente non lancia il proprio window manager tramite /usr/lib/systemd/systemd --user, sarà invece necessario inserire systemd --user & in modo da lanciare systemd come qualsiasi altra applicazione prima di eseguire il window manager.

Dopo l'avvio di X, è possibile controllare se la sessione è gestita da systemd-logind utilizzando il seguente comando:

$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active

Se l'output corrisponde a Active=yes, allora si sta utilizzando systemd-logind per gestire la sessione. Rimuovere eventuali occorrenze di ck-launch-session o dbus-launch dal proprio ~/.xinitrc, dal momento che tali comandi non sono più richiesti.

Display Managers

I principali Display Manager utilizzano systemd-logind di default, perciò il comando loginctl menzionato nella sezione precedente dovrebbe funzionare come previsto. Sarà semplicemente necessario aggiungere /usr/lib/systemd/systemd --user all'elenco dei programmi che l'ambiente desktop avvia automaticamente.

GNOME 3 (Utilizzando GDM)

Gli utenti che desiderano che GDM 3 avvii automaticamente la propria sessione di /usr/lib/systemd/systemd --user devono semplicemente creare una sessione di login speciale:

/usr/share/xsessions/gnome-systemd.desktop
[Desktop Entry]
Type=Application
Name=systemd
Comment=Avvia un'istanza utente di 'systemd'
Exec=/usr/lib/systemd/systemd --user

Assicurarsi di scegliere la sessione systemd al login.

Nota: Quanto sopra è stato testato con una installazione pura di GNOME 3 e GDM. In caso di configurazioni alternative, la vostra esperienza potrebbe variare. Questo metodo non richiede l'installazione degli script user-session di systemd.

Utilizzare /usr/lib/systemd/systemd --user per gestire la propria sessione

Systemd ha molte caratteristiche utili, una delle quali è la capacità di tracciare i programmi utilizzando i cgroups (si esegua systemctl status). Benchè ciò sia veramente utile per un sistema di init il cui processo ha pid 1, anche la modalità utente può avvalersi di questa caratteristica per avviare automaticamente i programmi dello stesso, tracciando al tempo stesso il contenuto di ogni cgroup.

Tutte le units dell'utente andranno inserite in $HOME/.config/systemd/user ed avranno la precedenza sulle altre unità contenute nelle directory di sistema.

Sarà necessario installare due pacchetti per avvalersi di questa funzionalità, entrambi reperibili su AUR: xorg-launch-helperAUR e user-session-unitsAUR, se si desidera utilizzare l'autologin.

Inizializzare quindi i propri targets. È consigliabile crearne due: una per il window manager e l'altra come target di default. Il target del window manager dovrebbe essere simile al seguente:

$HOME/.config/systemd/user/wm.target
[Unit]
Description=Window manager target
Wants=xorg.target
Wants=mystuff.target
Requires=dbus.socket
AllowIsolate=true

[Install]
Alias=default.target

Si crei un secondo target chiamato mystuff.target, che andrà poi inserito nel campo WantedBy (sezione [Install]) di tutti i servizi che si intende avviare ad eccezione del window manager:

$HOME/.config/systemd/user/mystuff.target
[Unit]
Description=Xinitrc Stuff
Wants=wm.target

[Install]
Alias=default.target

Si crei un link simbolico di nome default.target, che punta al target di cui sopra. Quando si esegue /usr/lib/systemd/systemd --user, questo sarà il target avviato.

Infine, si scrivano i vari files .service corrispondenti ai servizi da avviare. Si inizi con quello del window manager:

$HOME/.config/systemd/user/mystuff.target
[Unit]
Description=your window manager service
Before=mystuff.target
After=xorg.target
Requires=xorg.target
 
[Service]
Requires=xorg.target
#Environment=PATH=decommentare:per:sovrascrivere:PATH
Environment=DISPLAY=:0
ExecStart=/percorso/assoluto/ad/eseguibile/wm
Restart=always
RestartSec=10
 
[Install]
WantedBy=wm.target
Nota: La sezione [Install] include il valore WantedBy, che permetterà al servizio di essere linkato come $HOME/.config/systemd/user/wm.target.wants/VOSTRO_WM.service, quando si utilizza systemctl --user enable, consentendone l'avvio al login. È consigliabile abilitare questo servizio con systemctl e non linkarlo manualmente.

È ora possibile riempire la directory delle unità con tutti i servizi di cui si potrebbe aver bisogno, come ad esempio mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys e xmodmap.

Login automatico

Se si vuole utilizzare il login automatico al boot, è possibile utilizzare la relativa unit fornita dal pacchetto user-session-unitsAUR. Si consideri l'idea di abilitare uno screen locker per evitare che qualcuno possa avvalersi della sessione appena avviata.

Si aggiunga questa linea ai files /etc/pam.d/login e /etc/pam.d/system-auth:

session    required    pam_systemd.so

Dal momento che user-session@.service viene avviato sulla tty1, sarà necessario aggiungere Conflicts=getty@tty1.service al .service in questione, se non è già presente.

Una volta fatto quanto sopra, si esegua systemctl --user enable WM_SCELTO.service

Nota: È necessario prestare attenzione alle tty, in modo che la sessione di systemd sia marcata come attiva. Una sessione viene segnata come inattiva quando la tty nella quale ci si trova è diversa da quella in cui è stato effettuato il login, il che significa che il server X dovrà essere avviato nella stessa tty specificata in user-session@.service, altrimenti potrebbero verificarsi diversi problemi con le applicazioni grafiche, come l'impossibilità di montare dispositivi removibili USB.

Una delle cose più importanti da aggiungere ai propri .service è l'utilizzo di Before= e After= nella sezione [Unit], che permettono di determinare l'ordine di avvio dei servizi. Si supponga di disporre di una applicazione grafica che si vuole avviare al boot: sarà possibile farlo aggiungendo After=xorg.target al proprio .service. Si supponga inoltre di voler avviare ncmpcpp che richiede mpd per funzionare: in tal caso si dovrà aggiungere After=mpd.service al .service di ncmpcpp.

Col tempo e l'esperienza si capirà come gestire l'ordine di avvio delle applicazioni, oppure leggendo le pagine di man di systemd. Iniziare con systemd.unit(5) è una buona idea.

Altri casi d'uso

Multiplexer di terminale persistente

Si potrebbe voler utilizzare la propria sessione utente per avviare un multiplexer di terminale come GNU Screen o Tmux in background invece di una sessione grafica. La separazione del login dal login grafico è probabilmente utile solamente per gli utenti che effettuano il boot in TTY invece di utilizzare un display manager (nel cui caso è possibile inserire tutti i programmi da avviare nel target mystuff.target).

Per creare questo tipo di sessione utente si proceda come sopra, creando però multiplexer.target invece di wm.target:

[Unit]
Description=Terminal multiplexer
Documentation=info:screen man:screen(1) man:tmux(1)
After=cruft.target
Wants=cruft.target

[Install]
Alias=default.target

Il target cruft.target, similmente a mystuff.target, dovrebbe occuparsi dell'avvio di tutti quei programmi che si pensa debbano essere lanciati prima di tmux o screen (o che si intende avviare al boot indifferentemente dal momento di avvio), come una sessione demone di GnuPG.

Sarà quindi necessario creare un servizio per la propria sessione multiplexer. Di seguito un servizio di esempio che utilizza tmux ed effettua il source di una sessione di gpg-agent che scrive le proprie informazioni in /tmp/gpg-agent-info. La sessione proposta è inoltre in grado di avviare programmi grafici previo avvio del server X, dal momento che la variabile DISPLAY è impostata.

[Unit]
Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
After=gpg-agent.service
Wants=gpg-agent.service

[Service]
Type=forking
ExecStart=/usr/bin/tmux start
ExecStop=/usr/bin/tmux kill-server
Environment=DISPLAY=:0
EnvironmentFile=/tmp/gpg-agent-info

[Install]
WantedBy=multiplexer.target

Una volta fatto, si esegua systemctl --user activate su tmux.service, multiplexer.target ed eventuali altri servizi che debbano essere avviati da cruft.target. Si abiliti inoltre user-session@.service come spiegato sopra, ma assicurarsi di rimuovere la linea Conflicts=getty@tty1.service, dal momento che la propria sessione utente non gestirà una TTY.

Congratulazioni! Si dispone ora di un multiplexer di terminale ed altri programmi utili che vengono avviati automaticamente al boot!

Avviare X

Si avrà notato che, essendo il multiplexer di terminale il nuovo default.target, X non sarà avviato automaticamente al boot. Per avviare X, si proceda come sopra ma non si attivi o linki manualmente wm.target a default.target, bensì utilizzare un semplice alias per startx:

alias startx='systemctl --user start wm.target'

Servizi Utente

Gli utenti possono ora interagire con le unità poste nelle seguenti directory proprio come farebbero con i servizi di sistema (ordinate in modo ascendente di preferenza):

  • /usr/lib/systemd/user/
  • /etc/systemd/user
  • ~/.config/systemd/user

Per controllare l'istanza di systemd, si utilizzi il comando systemctl --user.

Servizi installati da pacchetti

I pacchetti che forniscono servizi pensati per essere avviati dall'utente, possono installarli in /usr/lib/systemd/user/. L'amministratore di sistema può quindi modificare l'unità copiandola in /etc/systemd/user/ e quest'ultima potrà a sua volta essere modificata dall'utente copiandola in ~/.config/systemd/user.

Esempio

Quanto segue è una versione utente del servizio di mpd:

mpd.service
[Unit]
Description=Music Player Daemon

[Service]
ExecStart=/usr/bin/mpd --no-daemon

[Install]
WantedBy=default.targets

Esempio con variabili

Quanto segue è una versione utente del servizio sickbeard.service, che utilizza una variabile contenente il valore della home directory dell'utente che lo esegue, utilizzata da SickBeard per trovare alcuni files:

sickbeard.service
[Unit]
Description=SickBeard Daemon

[Service]
ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard

[Install]
WantedBy=default.target

Come spiegato in man systemd.unit, la variabile %h contiene il valore della home directory dell'utente che esegue il servizio. È possibile utilizzare altre variabili, il cui elenco è disponibile nelle pagine di man di systemd.

Nota per le applicazioni X11

La maggior parte delle applicazioni grafiche richiedono che la variabile d'ambiente DISPLAY sia impostata per essere avviate (se i propri servizi non si avviano, questa è la prima cosa da controllare). Assicurarsi quindi di includerla nei propri servizi:

$HOME/.config/systemd/user/parcellite.service

[Unit]
Description=Parcellite clipboard manager

[Service]
ExecStart=/usr/bin/parcellite
Environment=DISPLAY=:0 # <= !

[Install]
WantedBy=mystuff.target

Sarebbe però preferibile non inserire direttamente il valore della variabile DISPLAY nei servizi (specialmente se si hanno più schermi):

$HOME/.config/systemd/user/x-app-template@.service

[Unit]
Description=Your amazing and original description

[Service]
ExecStart=/full/path/to/the/app
Environment=DISPLAY=%i # <= !

[Install]
WantedBy=mystuff.target

È ora possibile avviarli con:

systemctl --user {start|enable} x-app@display-in-uso.service # <= :0 nella maggior parte dei casi

Alcune applicazioni grafiche potrebbero non avviarsi correttamente poichè il display socket non è ancora disponibile. È possibile ovviare il proglema aggiungendo quanto segue ai propri servizi:

$HOME/.config/systemd/user/x-app-template@.service
[Unit]
After=xorg.target
Requires=xorg.target

...

Il target xorg.target fa parte del pacchetto xorg-launch-helperAUR.

Articoli correlati