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

From ArchWiki
Jump to: navigation, search
Line 4: Line 4:
 
[[en:Systemd/User]]
 
[[en:Systemd/User]]
 
[[es:Systemd/User]]
 
[[es:Systemd/User]]
[[ja:Systemd/User]]
+
[[fr:Systemd/utilisateur]]
{{Related articles start (Italiano)}}
+
[[ja:Systemd/ユーザー]]
 +
[[zh-CN:Systemd/User]]
 +
{{Related articles start}}
 
{{Related|systemd (Italiano)}}
 
{{Related|systemd (Italiano)}}
 +
{{Related|Automatic login to virtual console (Italiano)}}
 +
{{Related|Start X at Login (Italiano)}}
 
{{Related articles end}}
 
{{Related articles end}}
  
{{Out of date|A partire dalla versione 206 di systemd, {{ic|systemd --user}} non è più supportato. (Si veda [[https://bugs.freedesktop.org/show_bug.cgi?id=67471]]) }}
+
[[systemd (Italiano)|systemd]] offre agli utenti la possibilità di gestire i servizi sotto il controllo dell'utente tramite una istanza di systemd per singolo utente, che consente agli stessi di avviare, fermare, abilitare e disabilitare le proprie unità. Questa caratteristica è utile per demoni e altre operazioni automatiche come lo scaricamento della posta. È inoltre possibile, con alcune modifiche, avviare Xorg e il window manager in uso direttamente tramite i servizi utente.
  
[[systemd (Italiano)|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 (Italiano)|mpd]].
+
==Come funziona==
  
==Setup==
+
Quando un utente effettua il login, systemd avvia automaticamente una istanza di {{ic|systemd --user}}, necessaria per la gestione dei servizi dell'utente. Tale processo rimarrà in esecuzione fin tanto che l'utente sarà coneesso, e verrà terminato quando l'utente effettua il logout. Quando l'[[#Avvio automatico delle istanze utente di systemd]] è abilitato, l'istanza viene avviata al boot e non più terminata. Il comportamento di default è quello di non eseguire alcun servizio utente. I servizi utente possono essere utilizzati per avviare demoni o compiere operazioni automatiche, disponendo comunque di tutti i benefici di systemd, come l'attivazione  socket, timers, dipendenze e controllo processi tramite cgroups. Le unità utente sono situate nelle seguenti directory, similmente a quanto accade con i servizi di sistema (directory ordinate per preferenza crescente)
  
===startx===
+
* {{ic|/usr/lib/systemd/user/}} directory per i servizi forniti dai pacchetti.
 +
* {{ic|/etc/systemd/user/}} directory per i servizi definiti dall'amministratore di sistema.
 +
* {{ic|~/.config/systemd/user/}} directory per i servizi utenti.
  
{{Nota|Questo passaggio non è necessario se si intende utilizzare l'autologin.}}
+
All'avvio di una istanza utente di systemd, viene caricato il target {{ic|default.target}};  da questo punto è possibile controllare tale istanza tramite {{ic|systemctl --user}}.
  
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.
+
{{Nota|
 +
* Si noti che l'istanza utente {{ic|systemd --user}} è un processo dedicato per utente, e non per sessione. Ne consegue che la maggior parte delle risorse gestite dai servizi utenti, come sockets o file di stato, riguardano un singolo utente (sono difatti situati nella home directory dello stesso) e non una sessione. Ciò significa che tutti i servizi utente vengono eseguiti al di fuori di una sessione; per questo motivo, i programmi che necessitano di essere eseguiti per ogni singola sessione probabilmente non funzioneranno con le istanze utente di systemd. La gestione delle sessioni da parte di systemd varia continuamente. Si legga [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] e [http://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html] per avere un'idea generale sullo sviluppo di questa funzionalità.
 +
* {{ic|systemd --user}} viene eseguito come processo separato rispetto a {{ic|systemd --system}}. I servizi utente non possono pertanto riferirsi o dipendere da servizi di sistema.
 +
}}
  
L'utente dovrà ora lanciare un'istanza di systemd inserendo quanto segue nel proprio {{ic|~/.xinitrc}}:
+
==Configurazione di base==
  
{{bc|/usr/lib/systemd/systemd --user &}}
+
Le istanze utente di systemd dovrebbero avviarsi automaticamente al primo login. Per verificare che siano effettivamente in esecuzione, utilizzare {{ic|systemctl --user status}}.
  
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.
+
{{Nota|Se l'istanza utente di systemd non si avvia automaticamente, si controlli il file {{ic|/etc/pam.d/system-login}}. Dovrebbe contenere una riga simile a {{ic|-session  optional  pam_systemd.so}}. Si controlli inoltre l'esistenza di eventuali file ''.pacnew''.}}
  
Dopo l'avvio di X, è possibile controllare se la sessione è gestita da {{ic|systemd-logind}} utilizzando il seguente comando:
+
Tutti i servizi utenti devono essere inseriti in {{ic|~/.config/systemd/user}}. Se si vuole avviare une servizio automaticamente al login, si esegua {{ic|systemctl --user enable ''servizio''}} per ogni servizio.
  
$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active
+
{{Nota|A partire da systemd 206, il meccanismo per le istanze utente è stato modificato. Il modulo {{ic|pam_systemd.so}} lancia ora una istanza utente di default. Non è necessario avviarla manualmente. Il servizio {{ic|user-session@.service}} fornito dal pacchetto {{AUR|user-session-units}} è obsoleto. A partire da questa versione, l'istanza {{ic|systemd --user}} viene eseguita al di fuori di una sessione utente, con le conseguenze del caso.}}
  
Se l'output corrisponde a {{ic|1=Active=yes}}, allora si sta utilizzando {{ic|systemd-logind}} per gestire la sessione. Rimuovere eventuali occorrenze di {{ic|ck-launch-session}} o {{ic|dbus-launch}} dal proprio {{ic|~/.xinitrc}}, dal momento che tali comandi non sono più richiesti.
+
===D-Bus===
  
===Display Managers===
+
Alcune applicazioni necessitano di un messagebus [[D-Bus|D-Bus]], tradizionalmente avviato quando si esegue un desktop environment tramite {{ic|dbus-launch}}. Tuttavia, se si tenta di eseguire qualche applicazione che dipenda da D-Bus come servizio utente, sarà necessario avviare il server D-Bus come servizio di systemd per soddisfare la dipendenza.
  
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.
+
{{Nota|A causa della prossima transizione di systemd a kdbus, systemd diverrà in ogni caso il gestore dei messagebus utente di sistema.}}
  
====GNOME 3 (Utilizzando GDM)====
+
Procedere come segue:
  
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:
+
1. Si crei un servizio e delle unità socket per il server D-Bus in {{ic|/etc/systemd/user}}
  
{{hc|/usr/share/xsessions/gnome-systemd.desktop|<nowiki>
+
{{hc|/etc/systemd/user/dbus.socket|<nowiki>
[Desktop Entry]
+
[Unit]
Type=Application
+
Description=D-Bus User Message Bus Socket
Name=systemd
+
 
Comment=Avvia un'istanza utente di 'systemd'
+
[Socket]
Exec=/usr/lib/systemd/systemd --user
+
ListenStream=%t/bus
 +
 
 +
[Install]
 +
WantedBy=sockets.target
 +
Also=dbus.service
 
</nowiki>}}
 
</nowiki>}}
  
Assicurarsi di scegliere la sessione {{ic|systemd}} al login.
+
{{hc|/etc/systemd/user/dbus.service|<nowiki>
 +
[Unit]
 +
Description=D-Bus User Message Bus
 +
Documentation=man:dbus-daemon(1)
 +
Requires=dbus.socket
 +
 
 +
[Service]
 +
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
 +
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
  
{{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.}}
+
[Install]
 +
Also=dbus.socket
 +
</nowiki>}}
  
===Utilizzare {{ic|/usr/lib/systemd/systemd --user}} per gestire la propria sessione===
+
2. Sarà necessario definire la variabile d'ambiente {{ic|DBUS_SESSION_BUS_ADDRESS}}. È possibile farlo tramite un file di configurazione per il servizio {{ic|user@.service}}, creando il file seguente:
  
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.
+
{{hc|/etc/systemd/system/user@.service.d/dbus.conf|<nowiki>
 +
[Service]
 +
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus
 +
</nowiki>}}
  
Tutte le units dell'utente andranno inserite in {{ic|$HOME/.config/systemd/user}} ed avranno la precedenza sulle altre unità contenute nelle directory di sistema.
+
{{Nota|Per le versioni di systemd precedenti alla 209, la variabile {{ic|DBUS_SESSION_BUS_ADDRESS}} veniva definita nell'unità {{ic|user@.service}} fornita upstream. Per versioni successive, tale funzionalità è stata disabilitata, a causa del futuro passaggio a kdbus, dove sarà il modulo PAM {{ic|pam_systemd.so}} a definire la variabile.}}
  
Sarà necessario installare due pacchetti per avvalersi di questa funzionalità, entrambi reperibili su [[AUR (Italiano)|AUR]]: {{AUR|systemd-xorg-launch-helper-git}} e {{AUR|systemd-user-session-units-git}}, se si desidera utilizzare l'autologin.
+
3. Attivare il socket per tutti gli utenti eseguendo da root:
  
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:
+
# systemctl --global enable dbus.socket
  
{{hc|$HOME/.config/systemd/user/wm.target|<nowiki>
+
===Variabili d'ambiente===
[Unit]
+
 
Description=Window manager target
+
L'istanza utente di systemd non eredita le [[environment variables|variabili d'ambiente]] definite in {{ic|.bashrc}} e similari. Vi sono tre modi per definire variabili d'ambiente per istanze di systemd:
Wants=xorg.target
+
 
Wants=mystuff.target
+
# Utilizzare l'opzione {{ic|DefaultEnvironment}} in {{ic|/etc/systemd/user.conf}}. Viene applicata a tutti i servizi utente.
Requires=dbus.socket
+
# Creare un file di configurazione in {{ic|/etc/systemd/system/user@.service.d/}}. Viene applicata a tutti i servizi utente.
AllowIsolate=true
+
# In qualsiasi momento, tramite i comandi {{ic|systemctl --user set-environment}} o {{ic|systemctl --user import-environment}}. Applicata a tutti i servizi avviati dopo l'esecuzione dei comandi di cui sopra, ma non a quelli già avviati.
 +
:: {{Suggerimento|1=Per definire più variabili contemporaneamente, si crei un file di configurazione contentente una lista di coppie ''chiave=valore'', separate da uno spazio, e si aggiunga {{ic|xargs systemctl --user set-environment < /path/to/file.conf}} al file di configurazione utente della shell in uso.}}
 +
 
 +
Alcune delle variabili che si potrebbe voler definire sono {{ic|DISPLAY}} o {{ic|PATH}}
 +
 
 +
====DISPLAY====
 +
 
 +
{{Nota|1=A partire da systemd 219, "viene fornito uno script sessione X11 che definisce automaticamente {{ic|$DISPLAY}} e {{ic|$XAUTHORITY}} nell'ambiente del demone {{ic|systemd --user}} all'avvio di una nuova sessione, allo scopo di migliorare la compatibilità di eventuali applicazioni X11 eseguite come servizi di utente."
 +
[http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=v219#n194 fonte]) Tale funzionalità non dipende per il momento dall'abilitazione di KDBUS.}}
 +
 
 +
La variabile {{ic|DISPLAY}} viene utilizzata dalle applicazioni X11 per identificare lo schermo da utilizzare. Se si ha intenzione di eseguire applicazioni X11 come servizi utente, sarà necessario definire tale variabile. Ad esempio:
  
[Install]
+
{{hc|/etc/systemd/user.conf|<nowiki>
Alias=default.target
+
...
 +
DefaultEnvironment=DISPLAY=:0
 +
...
 
</nowiki>}}
 
</nowiki>}}
  
Si crei un secondo target chiamato {{ic|mystuff.target}}, che andrà poi inserito nel campo {{ic|WantedBy}} (sezione {{ic|[Install]}}) di tutti i servizi che si intende avviare ad eccezione del window manager:
+
====PATH====
  
{{hc|$HOME/.config/systemd/user/mystuff.target|<nowiki>
+
Come tutte le variabili d'ambiente definite tramite {{ic|.bashrc}} o {{ic|.bash_profile}}, anche {{ic|PATH}} non è visibile a systemd. Se si modifica il valore di tale variabile e si intende avviare applicazioni che se ne avvalgano come servizi di systemd, sarà necessario notificare systemd della sua modifica. È consigliabile farlo aggiungendo la seguente riga al proprio {{ic|.bash_profile}}, dopo aver definito la variabile {{ic|PATH}}:
[Unit]
 
Description=Xinitrc Stuff
 
Wants=wm.target
 
  
[Install]
+
{{hc|~/.bash_profile|<nowiki>
Alias=default.target
+
systemctl --user import-environment PATH
 
</nowiki>}}
 
</nowiki>}}
  
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.
+
===Avvio automatico delle istanze utente di systemd===
 +
 
 +
L'istanza utente di systemd viene avviata dopo il primo login di un utente, e fermata alla chiusura dell'ultima sessione di quell'utente. Potrebbe essere talvolta necesario avviarla subito dopo il boot, e mantenerla attiva alla chiusura dell'ultima sessione utente relativa, ad esempio per avere processi utente attivi senza alcuna sesione utente in corso.
 +
Si esegua a tal proposito il seguente comando per abilitare tale comportamento per un singolo utente:
 +
 
 +
# loginctl enable-linger ''nomeutente''
 +
 
 +
{{Attenzione|I servizi systemd '''non''' sono sessioni, dal momento che vengono eseguiti al di fuori di ''logind''. Non si utilizzi la funzionalità di lingering per abilitare il login autometico, dal momento che questo [[General troubleshooting#Session permissions|renderà inutilizzabile la sessione]].}}
  
Infine, si scrivano i vari files .service corrispondenti ai servizi da avviare. Si inizi con quello del window manager:
+
==Xorg e systemd==
  
{{hc|$HOME/.config/systemd/user/mystuff.target|<nowiki>
+
Vi sono diversi metodi per avviare Xorg tramite systemd. Di seguito due possibilità: l'avvio di una sessione utente con un processo di Xorg o l'avvio di quest'ultimo come servizio utente.
[Unit]
+
 
Description=your window manager service
+
===Login automatico in Xorg senza display manager===
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
 
</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|systemctl --user enable}}, consentendone l'avvio al login. È consigliabile abilitare questo servizio con systemctl e non linkarlo manualmente.}}
+
{{Accuracy|Questa configurazione avvia due istanze di D-Bus: una per il desktop e l'altra per systemd. Perchè non utilizzare quella di systemd? }}
  
È 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'''.
+
Quanto sotto avvierà una sessione utente ed il server Xorg come unità di sistema e provvederà poi a leggere il contenuto di {{ic|~/.xinitrc}}, avviare il window manager, ecc.
  
Per uscire dalla sessione utente si utilizzi {{ic|systemctl --user exit}}.
+
Sarà necessario configurare [[#D-Bus]] nel modo corretto ed installare il pacchetto {{AUR|xlogin-git}}.
  
===Login automatico===
+
Si crei il proprio file [[xinitrc (Italiano)|xinitrc]] da quello di default, in modo che effettui il source dei files in {{ic|/etc/X11/xinit/xinitrc.d/}}. È necessario che l'esecuzione del priorio {{ic|~/.xinitrc}} non ritorni, quindi si inserisca {{ic|wait}} come ultimo comando, o si aggiunga {{ic|exec}} all'ultimo comando (ad esempio, il proprio window manager).
  
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.
+
Questa sessione utilizzerà il proprio demone D-Bus, ma varie utility di systemd si connetteranno automaticamente all'istanza avviata dal servizio {{ic|dbus.service}}
  
Si aggiunga questa linea ai files {{ic|/etc/pam.d/login}} e {{ic|/etc/pam.d/system-auth}}:
+
Si abiliti infine ('''come root''') il servizio ''xlogin'' per ottenere il login automatico al boot:
  
  session    required    pam_systemd.so
+
  # systemctl enable xlogin@''username''
  
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.
+
La sessione utente viene eseguita interamente in un ambiente systemd, quindi tutto dovrebbe funzionare nel modo corretto.
  
Una volta fatto quanto sopra, si esegua {{ic|systemctl --user enable}} {{ic|WM_SCELTO.service}}
+
===Avvio di Xorg come servizio utente===
  
{{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.}}
+
In alternativa, è possibile avviare [[xorg (Italiano)|xorg]] come servizio utente, avendo il vantaggio di poter definire il servizio in questione come dipendenza di altre unità che lo necessitino.
 +
Questo approccio, tuttavia, non è esente da difetti, elencati sotto:
  
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.
+
A partire dalla versione 1.16, {{Pkg|xorg-server}} si integra in modo migliore con systemd in due modi:
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.
+
* Può essere avviato senza privilegi di root, delegando la gestione dei dispositivi a logind (si vedano i commit di Hans de Goede [http://cgit.freedesktop.org/xorg/xserver/commit/?id=82863656ec449644cd34a86388ba40f36cea11e9 this qui]).
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}}.
+
* Può essere avviato come servizio attivato tramite socket (si veda [http://cgit.freedesktop.org/xorg/xserver/commit/?id=b3d3ffd19937827bcbdb833a628f9b1814a6e189 questo commit]).
  
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.
+
Sfortunatamente, per avviare Xorg senza privilegi di amministratore, è necessario essere in una sessione, perciò, in questo momento, è necessario avviare Xorg come amministratore per poterlo gestire tramite i servizi utente (come per versioni precedenti la 1.16).
  
===Altri casi d'uso===
+
{{Nota|Si noti che quanto sopra non è una restrizione imposta da logind: Xorg necessita infatti di sapere di quale sessione appropriarsi e, ad ora, ottiene questa informazione chiamando la funzione {{ic|GetSessionByPID}} di [http://www.freedesktop.org/wiki/Software/systemd/logind logind], utilizzando il proprio PID come argomento. Si vedano [http://lists.x.org/archives/xorg-devel/2014-February/040476.html questo thread] e [http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/systemd-logind.c i sorgenti di Xorg]. È probabilmente possibile modificare Xorg in modo che ottenga la sessione dalla tty sulla quale viene avviata.}}
  
====Multiplexer di terminale persistente====
+
Di seguito le istruzioni per avviare Xorg come servizio utente
  
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}}).
+
1. Assicurarsi che Xorg possa venire avviato con privilegi da amministratore da qualsiasi utente, modificando {{ic|/etc/X11/Xwrapper.config}}:
  
Per creare questo tipo di sessione utente si proceda come sopra, creando però {{ic|multiplexer.target}} invece di {{ic|wm.target}}:
+
{{hc|/etc/X11/Xwrapper.config|<nowiki>
 +
allowed_users=anybody
 +
needs_root_rights=yes
 +
</nowiki>}}
  
[Unit]
+
2. Creare le seguenti unità in {{ic|~/.config/systemd/user}}:
Description=Terminal multiplexer
 
Documentation=info:screen man:screen(1) man:tmux(1)
 
After=cruft.target
 
Wants=cruft.target
 
 
[Install]
 
Alias=default.target
 
  
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.
+
{{hc|~/.config/systemd/user/xorg@.socket|<nowiki>
 +
[Unit]
 +
Description=Socket for xorg at display %i
  
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.
+
[Socket]
 +
ListenStream=/tmp/.X11-unix/X%i
 +
</nowiki>}}
  
{{bc|<nowiki>
+
{{hc|~/.config/systemd/user/xorg@.service|<nowiki>
 
[Unit]
 
[Unit]
Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
+
Description=Xorg server at display %i
After=gpg-agent.service
+
 
Wants=gpg-agent.service
+
Requires=xorg@%i.socket
 +
After=xorg@%i.socket
  
 
[Service]
 
[Service]
Type=forking
+
Type=simple
ExecStart=/usr/bin/tmux start
+
SuccessExitStatus=0 1
ExecStop=/usr/bin/tmux kill-server
 
Environment=DISPLAY=:0
 
EnvironmentFile=/tmp/gpg-agent-info
 
  
[Install]
+
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"
WantedBy=multiplexer.target
 
 
</nowiki>}}
 
</nowiki>}}
  
Una volta fatto, si esegua {{ic|systemctl --user enable}} su {{ic|tmux.service}}, {{ic|multiplexer.target}} ed eventuali altri servizi che debbano essere avviati da {{ic|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.
+
Dove {{ic|${XDG_VTNR}}} è il terminale virtuale dove Xorg verrà eseguito, definito all'interno del servizio utente, o specificato come variabile d'ambiente in systemd tramite:
  
Congratulazioni! Si dispone ora di un multiplexer di terminale ed altri programmi utili che vengono avviati automaticamente al boot!
+
$ systemctl --user set-environment XDG_VTNR=1
  
=====Avviare X=====
+
{{Nota|Xorg dovrebbe essere lanciato dallo stesso terminale virtuale dove si è effettuato il login, altrimenti loging considererà la sessione come inattiva.}}
  
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}}:
+
3. Assicurarsi di definire la variabile d'ambiente {{ic|DISPLAY}} come spiegato [[#DISPLAY|sopra]].
  
alias startx='systemctl --user start wm.target'
+
4. Per abilitare l'attivazione socket per Xorg sul display 0 e tty2, si procederebbe come segue:
  
==Servizi Utente==
+
$ systemctl --user set-environment XDG_VTNR=2    # Per dichiarare a xorg@.service quale terminale utilizzare
 +
$ systemctl --user start xorg@0.socket            # Resta in ascolto sul socket del display 0
  
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):
+
A questo punto, qualsiasi applicazione X11 verrà eseguita automaticamente sul terminale virtuale 2.
  
* {{ic|/usr/lib/systemd/user/}}
+
La variabile d'ambiente {{ic|XDG_VTNR}} può essere definita nell'ambiente di systemd partendo da  {{ic|.bash_profile}}, cosa che renderebbe possibile avviare qualsiasi applicazione X11, compreso un window manager, come unità utente systemd, inserendo una dipendenza a {{ic|xorg@0.socket}}.
* {{ic|/etc/systemd/user}}
 
* {{ic|~/.config/systemd/user}}
 
  
Per controllare l'istanza di systemd, si utilizzi il comando {{ic|systemctl --user}}.
+
{{Attenzione|Al momento, l'esecuzione di un window manager come servizio utente ne comporta l'avvio al di fuori della sessione, con tutti i problemi che ciò comporta: [[General troubleshooting#Session permissions]]. Sembra però che gli sviluppatori di systemd stiano tentando di rendere possibile tale comportamento. Si veda a tal proposito [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] e [http://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html].}}
  
===Servizi installati da pacchetti===
+
==Scrivere servizi utente==
 
 
I pacchetti che forniscono servizi pensati per essere avviati dall'utente, possono installarli in {{ic|/usr/lib/systemd/user/}}. L'amministratore di sistema può quindi modificare l'unità copiandola in {{ic|/etc/systemd/user/}} e quest'ultima potrà a sua volta essere modificata dall'utente copiandola in {{ic|~/.config/systemd/user}}.
 
  
 
===Esempio===
 
===Esempio===
  
Quanto segue è una versione utente del servizio di mpd:
+
Di seguito un esempio per l'avvio di mpd come servizio utente:
  
{{hc|mpd.service|<nowiki>
+
{{hc|~/.config/systemd/user/mpd.service|<nowiki>
 
[Unit]
 
[Unit]
 
Description=Music Player Daemon
 
Description=Music Player Daemon
Line 209: Line 231:
  
 
[Install]
 
[Install]
WantedBy=default.targets
+
WantedBy=default.target
 
</nowiki>}}
 
</nowiki>}}
  
 
===Esempio con variabili===
 
===Esempio con variabili===
  
Quanto segue è una versione utente del servizio {{ic|sickbeard.service}}, che utilizza una variabile contenente il valore della home directory dell'utente che lo esegue, utilizzata da SickBeard per trovare alcuni files:
+
Esempio di avvio di {{ic|sickbeard}} come servizio utente, con definizione di una variabile utente per la directory home dove Sickbeard reperisce alcuni file di configurazione:
  
{{hc|sickbeard.service|<nowiki>
+
{{hc|~/.config/systemd/user/sickbeard.service|<nowiki>
 
[Unit]
 
[Unit]
 
Description=SickBeard Daemon
 
Description=SickBeard Daemon
Line 227: Line 249:
 
</nowiki>}}
 
</nowiki>}}
  
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 specificato in {{ic|man systemd.unit}}, la variabile {{ic|%h}} viene sostituita con la home directory dell'utente che esegue il servizio. Vi sono altre variabili disponibili, spiegate in dettaglio nelle pagine di manuale di [[systemd (Italiano)|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:
+
===Nota per applicazioni X11===
  
{{hc|$HOME/.config/systemd/user/parcellite.service|<nowiki>
+
La maggior parte delle applicazioni X11, necessitano della variabile {{ic|DISPLAY}} per essere eseguite (causa principale del mancato avvio delle proprie unità utente). Si veda [[#DISPLAY]] per definire la variabile per l'intera istanza utente di systemd. In alternativa, è possibile definirla solo per il servizio corrente, come segue:
  
 +
{{hc|~/.config/systemd/user/parcellite.service|2=
 
[Unit]
 
[Unit]
 
Description=Parcellite clipboard manager
 
Description=Parcellite clipboard manager
Line 240: Line 261:
 
[Service]
 
[Service]
 
ExecStart=/usr/bin/parcellite
 
ExecStart=/usr/bin/parcellite
Environment=DISPLAY=:0 # <= !
+
'''Environment=DISPLAY=:0'''
  
 
[Install]
 
[Install]
 
WantedBy=mystuff.target
 
WantedBy=mystuff.target
</nowiki>}}
+
}}
 +
 
 +
==Esempi d'uso==
 +
 
 +
===Multiplexer di terminale persistente===
 +
 
 +
{{Out of date|References {{ic|user-session@.service}} instead of {{ic|user@.service}}; the latter does not contain {{ic|1=Conflicts=getty@tty1.service}}.}}
 +
 
 +
You may wish your user session to default to running a terminal multiplexer, such as [[GNU Screen]] or [[Tmux]], in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with myStuff.target).
 +
 
 +
To create this type of user session, procede as above, but instead of creating wm.target, create multiplexer.target:
 +
 
 +
{{bc|1=
 +
[Unit]
 +
Description=Terminal multiplexer
 +
Documentation=info:screen man:screen(1) man:tmux(1)
 +
After=cruft.target
 +
Wants=cruft.target
 +
 
 +
[Install]
 +
Alias=default.target
 +
}}
  
Sarebbe però preferibile non inserire direttamente il valore della variabile {{ic|DISPLAY}} nei servizi (specialmente se si hanno più schermi):
+
{{ic|cruft.target}}, like {{ic|mystuff.target}} above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.
  
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
+
You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to {{ic|/tmp/gpg-agent-info}}. This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.
  
 +
{{bc|1=
 
[Unit]
 
[Unit]
Description=Your amazing and original description
+
Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
 +
After=gpg-agent.service
 +
Wants=gpg-agent.service
  
 
[Service]
 
[Service]
ExecStart=/full/path/to/the/app
+
Type=forking
Environment=DISPLAY=%i # <= !
+
ExecStart=/usr/bin/tmux start
 +
ExecStop=/usr/bin/tmux kill-server
 +
Environment=DISPLAY=:0
 +
EnvironmentFile=/tmp/gpg-agent-info
  
 
[Install]
 
[Install]
WantedBy=mystuff.target
+
WantedBy=multiplexer.target
</nowiki>}}
+
}}
  
È ora possibile avviarli con:
+
Once this is done, {{ic|systemctl --user enable}} {{ic|tmux.service}}, {{ic|multiplexer.target}} and any services you created to be run by {{ic|cruft.target}} and you should be set to go! Activated {{ic|user-session@.service}} as described above, but be sure to remove the {{ic|1=Conflicts=getty@tty1.service}} from {{ic|user-session@.service}}, since your user session will not be taking over a TTY. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!
  
systemctl --user {start|enable} x-app@display-in-uso.service # <= :0 nella maggior parte dei casi
+
===Window manager===
  
Alcune applicazioni grafiche potrebbero non avviarsi correttamente poichè il display socket non è ancora disponibile. È possibile ovviare il proglema aggiungendo quanto segue ai propri servizi:
+
Per eseguire un window manager come servizio di systemd, sarà necessario [[#Avvio di Xorg come servizio utente|avviare Xorg come servizio utente]]. Di seguito, un esempio utilizzando awesome:
  
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
+
{{hc|~/.config/systemd/user/awesome.service|<nowiki>
 
[Unit]
 
[Unit]
 +
Description=Awesome window manager
 
After=xorg.target
 
After=xorg.target
 
Requires=xorg.target
 
Requires=xorg.target
  
...
+
[Service]
 +
ExecStart=/usr/bin/awesome
 +
Restart=always
 +
RestartSec=10
 +
 +
[Install]
 +
WantedBy=wm.target
 
</nowiki>}}
 
</nowiki>}}
  
Il target {{ic|xorg.target}} fa parte del pacchetto {{AUR|xorg-launch-helper}}.
+
{{Nota|La sezione {{ic|[Install]}} include una direttiva {{ic|WantedBy}}. All'utilizzo di {{ic|systemctl --user enable}}, verrà creato il link {{ic|~/.config/systemd/user/wm.target.wants/''window_manager''.service}}, consentendo l'avvio al login. Si raccomanda l'abilitazione di questo servizio, e non la creazione manuale del link simbolico.}}
 
 
==Articoli correlati==
 
  
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home il wiki di KaiSforza, su BitBucket]
+
==Riferimenti==
* [https://github.com/zoqaeski/systemd-user-units I servizi di Zoqaeski su GitHub]
+
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home Wiki Bitbucket di KaiSforza]
* [https://github.com/grawity/systemd-user-units Utile raccolta di units per systemd]
+
* [https://github.com/zoqaeski/systemd-user-units Servizi di Zoqaeski su GitHub]
* [https://bitbucket.org/KaiSforza/systemd-user-units Altre units utente per systemd]
+
* [https://github.com/grawity/systemd-user-units Collezione di servizi utente systemd]
 +
* [https://bbs.archlinux.org/viewtopic.php?id=167115 Discussione sul forum di Arch a seguito dei cambiamenti introdotti a partire da systemd 206]

Revision as of 19:03, 4 June 2015

zh-CN:Systemd/User

systemd offre agli utenti la possibilità di gestire i servizi sotto il controllo dell'utente tramite una istanza di systemd per singolo utente, che consente agli stessi di avviare, fermare, abilitare e disabilitare le proprie unità. Questa caratteristica è utile per demoni e altre operazioni automatiche come lo scaricamento della posta. È inoltre possibile, con alcune modifiche, avviare Xorg e il window manager in uso direttamente tramite i servizi utente.

Come funziona

Quando un utente effettua il login, systemd avvia automaticamente una istanza di systemd --user, necessaria per la gestione dei servizi dell'utente. Tale processo rimarrà in esecuzione fin tanto che l'utente sarà coneesso, e verrà terminato quando l'utente effettua il logout. Quando l'#Avvio automatico delle istanze utente di systemd è abilitato, l'istanza viene avviata al boot e non più terminata. Il comportamento di default è quello di non eseguire alcun servizio utente. I servizi utente possono essere utilizzati per avviare demoni o compiere operazioni automatiche, disponendo comunque di tutti i benefici di systemd, come l'attivazione socket, timers, dipendenze e controllo processi tramite cgroups. Le unità utente sono situate nelle seguenti directory, similmente a quanto accade con i servizi di sistema (directory ordinate per preferenza crescente)

  • /usr/lib/systemd/user/ directory per i servizi forniti dai pacchetti.
  • /etc/systemd/user/ directory per i servizi definiti dall'amministratore di sistema.
  • ~/.config/systemd/user/ directory per i servizi utenti.

All'avvio di una istanza utente di systemd, viene caricato il target default.target; da questo punto è possibile controllare tale istanza tramite systemctl --user.

Nota:
  • Si noti che l'istanza utente systemd --user è un processo dedicato per utente, e non per sessione. Ne consegue che la maggior parte delle risorse gestite dai servizi utenti, come sockets o file di stato, riguardano un singolo utente (sono difatti situati nella home directory dello stesso) e non una sessione. Ciò significa che tutti i servizi utente vengono eseguiti al di fuori di una sessione; per questo motivo, i programmi che necessitano di essere eseguiti per ogni singola sessione probabilmente non funzioneranno con le istanze utente di systemd. La gestione delle sessioni da parte di systemd varia continuamente. Si legga [1] e [2] per avere un'idea generale sullo sviluppo di questa funzionalità.
  • systemd --user viene eseguito come processo separato rispetto a systemd --system. I servizi utente non possono pertanto riferirsi o dipendere da servizi di sistema.

Configurazione di base

Le istanze utente di systemd dovrebbero avviarsi automaticamente al primo login. Per verificare che siano effettivamente in esecuzione, utilizzare systemctl --user status.

Nota: Se l'istanza utente di systemd non si avvia automaticamente, si controlli il file /etc/pam.d/system-login. Dovrebbe contenere una riga simile a -session optional pam_systemd.so. Si controlli inoltre l'esistenza di eventuali file .pacnew.

Tutti i servizi utenti devono essere inseriti in ~/.config/systemd/user. Se si vuole avviare une servizio automaticamente al login, si esegua systemctl --user enable servizio per ogni servizio.

Nota: A partire da systemd 206, il meccanismo per le istanze utente è stato modificato. Il modulo pam_systemd.so lancia ora una istanza utente di default. Non è necessario avviarla manualmente. Il servizio user-session@.service fornito dal pacchetto user-session-unitsAUR è obsoleto. A partire da questa versione, l'istanza systemd --user viene eseguita al di fuori di una sessione utente, con le conseguenze del caso.

D-Bus

Alcune applicazioni necessitano di un messagebus D-Bus, tradizionalmente avviato quando si esegue un desktop environment tramite dbus-launch. Tuttavia, se si tenta di eseguire qualche applicazione che dipenda da D-Bus come servizio utente, sarà necessario avviare il server D-Bus come servizio di systemd per soddisfare la dipendenza.

Nota: A causa della prossima transizione di systemd a kdbus, systemd diverrà in ogni caso il gestore dei messagebus utente di sistema.

Procedere come segue:

1. Si crei un servizio e delle unità socket per il server D-Bus in /etc/systemd/user

/etc/systemd/user/dbus.socket
[Unit]
Description=D-Bus User Message Bus Socket

[Socket]
ListenStream=%t/bus

[Install]
WantedBy=sockets.target
Also=dbus.service
/etc/systemd/user/dbus.service
[Unit]
Description=D-Bus User Message Bus
Documentation=man:dbus-daemon(1)
Requires=dbus.socket

[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

[Install]
Also=dbus.socket

2. Sarà necessario definire la variabile d'ambiente DBUS_SESSION_BUS_ADDRESS. È possibile farlo tramite un file di configurazione per il servizio user@.service, creando il file seguente:

/etc/systemd/system/user@.service.d/dbus.conf
[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus
Nota: Per le versioni di systemd precedenti alla 209, la variabile DBUS_SESSION_BUS_ADDRESS veniva definita nell'unità user@.service fornita upstream. Per versioni successive, tale funzionalità è stata disabilitata, a causa del futuro passaggio a kdbus, dove sarà il modulo PAM pam_systemd.so a definire la variabile.

3. Attivare il socket per tutti gli utenti eseguendo da root:

# systemctl --global enable dbus.socket

Variabili d'ambiente

L'istanza utente di systemd non eredita le variabili d'ambiente definite in .bashrc e similari. Vi sono tre modi per definire variabili d'ambiente per istanze di systemd:

  1. Utilizzare l'opzione DefaultEnvironment in /etc/systemd/user.conf. Viene applicata a tutti i servizi utente.
  2. Creare un file di configurazione in /etc/systemd/system/user@.service.d/. Viene applicata a tutti i servizi utente.
  3. In qualsiasi momento, tramite i comandi systemctl --user set-environment o systemctl --user import-environment. Applicata a tutti i servizi avviati dopo l'esecuzione dei comandi di cui sopra, ma non a quelli già avviati.
Suggerimento: Per definire più variabili contemporaneamente, si crei un file di configurazione contentente una lista di coppie chiave=valore, separate da uno spazio, e si aggiunga xargs systemctl --user set-environment < /path/to/file.conf al file di configurazione utente della shell in uso.

Alcune delle variabili che si potrebbe voler definire sono DISPLAY o PATH

DISPLAY

Nota: A partire da systemd 219, "viene fornito uno script sessione X11 che definisce automaticamente $DISPLAY e $XAUTHORITY nell'ambiente del demone systemd --user all'avvio di una nuova sessione, allo scopo di migliorare la compatibilità di eventuali applicazioni X11 eseguite come servizi di utente." fonte) Tale funzionalità non dipende per il momento dall'abilitazione di KDBUS.

La variabile DISPLAY viene utilizzata dalle applicazioni X11 per identificare lo schermo da utilizzare. Se si ha intenzione di eseguire applicazioni X11 come servizi utente, sarà necessario definire tale variabile. Ad esempio:

/etc/systemd/user.conf
...
DefaultEnvironment=DISPLAY=:0 
...

PATH

Come tutte le variabili d'ambiente definite tramite .bashrc o .bash_profile, anche PATH non è visibile a systemd. Se si modifica il valore di tale variabile e si intende avviare applicazioni che se ne avvalgano come servizi di systemd, sarà necessario notificare systemd della sua modifica. È consigliabile farlo aggiungendo la seguente riga al proprio .bash_profile, dopo aver definito la variabile PATH:

~/.bash_profile
systemctl --user import-environment PATH

Avvio automatico delle istanze utente di systemd

L'istanza utente di systemd viene avviata dopo il primo login di un utente, e fermata alla chiusura dell'ultima sessione di quell'utente. Potrebbe essere talvolta necesario avviarla subito dopo il boot, e mantenerla attiva alla chiusura dell'ultima sessione utente relativa, ad esempio per avere processi utente attivi senza alcuna sesione utente in corso. Si esegua a tal proposito il seguente comando per abilitare tale comportamento per un singolo utente:

# loginctl enable-linger nomeutente
Attenzione: I servizi systemd non sono sessioni, dal momento che vengono eseguiti al di fuori di logind. Non si utilizzi la funzionalità di lingering per abilitare il login autometico, dal momento che questo renderà inutilizzabile la sessione.

Xorg e systemd

Vi sono diversi metodi per avviare Xorg tramite systemd. Di seguito due possibilità: l'avvio di una sessione utente con un processo di Xorg o l'avvio di quest'ultimo come servizio utente.

Login automatico in Xorg senza display manager

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Questa configurazione avvia due istanze di D-Bus: una per il desktop e l'altra per systemd. Perchè non utilizzare quella di systemd? (Discuss in Talk:Systemd/User (Italiano)#)

Quanto sotto avvierà una sessione utente ed il server Xorg come unità di sistema e provvederà poi a leggere il contenuto di ~/.xinitrc, avviare il window manager, ecc.

Sarà necessario configurare #D-Bus nel modo corretto ed installare il pacchetto xlogin-gitAUR.

Si crei il proprio file xinitrc da quello di default, in modo che effettui il source dei files in /etc/X11/xinit/xinitrc.d/. È necessario che l'esecuzione del priorio ~/.xinitrc non ritorni, quindi si inserisca wait come ultimo comando, o si aggiunga exec all'ultimo comando (ad esempio, il proprio window manager).

Questa sessione utilizzerà il proprio demone D-Bus, ma varie utility di systemd si connetteranno automaticamente all'istanza avviata dal servizio dbus.service

Si abiliti infine (come root) il servizio xlogin per ottenere il login automatico al boot:

# systemctl enable xlogin@username

La sessione utente viene eseguita interamente in un ambiente systemd, quindi tutto dovrebbe funzionare nel modo corretto.

Avvio di Xorg come servizio utente

In alternativa, è possibile avviare xorg come servizio utente, avendo il vantaggio di poter definire il servizio in questione come dipendenza di altre unità che lo necessitino. Questo approccio, tuttavia, non è esente da difetti, elencati sotto:

A partire dalla versione 1.16, xorg-server si integra in modo migliore con systemd in due modi:

  • Può essere avviato senza privilegi di root, delegando la gestione dei dispositivi a logind (si vedano i commit di Hans de Goede this qui).
  • Può essere avviato come servizio attivato tramite socket (si veda questo commit).

Sfortunatamente, per avviare Xorg senza privilegi di amministratore, è necessario essere in una sessione, perciò, in questo momento, è necessario avviare Xorg come amministratore per poterlo gestire tramite i servizi utente (come per versioni precedenti la 1.16).

Nota: Si noti che quanto sopra non è una restrizione imposta da logind: Xorg necessita infatti di sapere di quale sessione appropriarsi e, ad ora, ottiene questa informazione chiamando la funzione GetSessionByPID di logind, utilizzando il proprio PID come argomento. Si vedano questo thread e i sorgenti di Xorg. È probabilmente possibile modificare Xorg in modo che ottenga la sessione dalla tty sulla quale viene avviata.

Di seguito le istruzioni per avviare Xorg come servizio utente

1. Assicurarsi che Xorg possa venire avviato con privilegi da amministratore da qualsiasi utente, modificando /etc/X11/Xwrapper.config:

/etc/X11/Xwrapper.config
allowed_users=anybody
needs_root_rights=yes

2. Creare le seguenti unità in ~/.config/systemd/user:

~/.config/systemd/user/xorg@.socket
[Unit]
Description=Socket for xorg at display %i

[Socket]
ListenStream=/tmp/.X11-unix/X%i
~/.config/systemd/user/xorg@.service
[Unit]
Description=Xorg server at display %i

Requires=xorg@%i.socket
After=xorg@%i.socket

[Service]
Type=simple
SuccessExitStatus=0 1

ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"

Dove ${XDG_VTNR} è il terminale virtuale dove Xorg verrà eseguito, definito all'interno del servizio utente, o specificato come variabile d'ambiente in systemd tramite:

$ systemctl --user set-environment XDG_VTNR=1
Nota: Xorg dovrebbe essere lanciato dallo stesso terminale virtuale dove si è effettuato il login, altrimenti loging considererà la sessione come inattiva.

3. Assicurarsi di definire la variabile d'ambiente DISPLAY come spiegato sopra.

4. Per abilitare l'attivazione socket per Xorg sul display 0 e tty2, si procederebbe come segue:

$ systemctl --user set-environment XDG_VTNR=2     # Per dichiarare a xorg@.service quale terminale utilizzare
$ systemctl --user start xorg@0.socket            # Resta in ascolto sul socket del display 0

A questo punto, qualsiasi applicazione X11 verrà eseguita automaticamente sul terminale virtuale 2.

La variabile d'ambiente XDG_VTNR può essere definita nell'ambiente di systemd partendo da .bash_profile, cosa che renderebbe possibile avviare qualsiasi applicazione X11, compreso un window manager, come unità utente systemd, inserendo una dipendenza a xorg@0.socket.

Attenzione: Al momento, l'esecuzione di un window manager come servizio utente ne comporta l'avvio al di fuori della sessione, con tutti i problemi che ciò comporta: General troubleshooting#Session permissions. Sembra però che gli sviluppatori di systemd stiano tentando di rendere possibile tale comportamento. Si veda a tal proposito [3] e [4].

Scrivere servizi utente

Esempio

Di seguito un esempio per l'avvio di mpd come servizio utente:

~/.config/systemd/user/mpd.service
[Unit]
Description=Music Player Daemon

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

[Install]
WantedBy=default.target

Esempio con variabili

Esempio di avvio di sickbeard come servizio utente, con definizione di una variabile utente per la directory home dove Sickbeard reperisce alcuni file di configurazione:

~/.config/systemd/user/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 specificato in man systemd.unit, la variabile %h viene sostituita con la home directory dell'utente che esegue il servizio. Vi sono altre variabili disponibili, spiegate in dettaglio nelle pagine di manuale di systemd.

Nota per applicazioni X11

La maggior parte delle applicazioni X11, necessitano della variabile DISPLAY per essere eseguite (causa principale del mancato avvio delle proprie unità utente). Si veda #DISPLAY per definire la variabile per l'intera istanza utente di systemd. In alternativa, è possibile definirla solo per il servizio corrente, come segue:

~/.config/systemd/user/parcellite.service
[Unit]
Description=Parcellite clipboard manager

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

[Install]
WantedBy=mystuff.target

Esempi d'uso

Multiplexer di terminale persistente

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: References user-session@.service instead of user@.service; the latter does not contain Conflicts=getty@tty1.service. (Discuss in Talk:Systemd/User (Italiano)#)

You may wish your user session to default to running a terminal multiplexer, such as GNU Screen or Tmux, in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with myStuff.target).

To create this type of user session, procede as above, but instead of creating wm.target, create multiplexer.target:

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

[Install]
Alias=default.target

cruft.target, like mystuff.target above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.

You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to /tmp/gpg-agent-info. This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.

[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

Once this is done, systemctl --user enable tmux.service, multiplexer.target and any services you created to be run by cruft.target and you should be set to go! Activated user-session@.service as described above, but be sure to remove the Conflicts=getty@tty1.service from user-session@.service, since your user session will not be taking over a TTY. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!

Window manager

Per eseguire un window manager come servizio di systemd, sarà necessario avviare Xorg come servizio utente. Di seguito, un esempio utilizzando awesome:

~/.config/systemd/user/awesome.service
[Unit]
Description=Awesome window manager
After=xorg.target
Requires=xorg.target

[Service]
ExecStart=/usr/bin/awesome
Restart=always
RestartSec=10
 
[Install]
WantedBy=wm.target
Nota: La sezione [Install] include una direttiva WantedBy. All'utilizzo di systemctl --user enable, verrà creato il link ~/.config/systemd/user/wm.target.wants/window_manager.service, consentendo l'avvio al login. Si raccomanda l'abilitazione di questo servizio, e non la creazione manuale del link simbolico.

Riferimenti