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:
systemd-xorg-launch-helper-git e
systemd-user-session-units-git, 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.
Per uscire dalla sessione utente si utilizzi
systemctl --user exit.
Login automatico.
Se si vuole utilizzare il login automatico al boot, è possibile utilizzare la relativa unit fornita dal pacchetto
user-session-units. 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 enable 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:
[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
...
Se ti è piaciuto l'articolo , iscriviti al feed
cliccando sull'immagine sottostante per tenerti sempre aggiornato sui
nuovi contenuti del blog:
Elementary ha abilitati di default tutti i repository ufficiali di Ubuntu. Ciò vuol dire che per installare qualsiasi cosa presente in archivio, sarà comunque possibile digitare il buon vecchio "sudo apt-get install ...". 
Elementary OS
Una delle novità principali della Clock App è il nuovo layout della pagina per la ricerca delle città. Il pulsante di ricerca è stato totalmente ridisegnato e ora presenta alcuni puntini bianchi disposti a formare un triangolo su sfondo rosa. Il campo di testo adiacente, inoltre, è stato allungato fino a occupare in orizzontale tutto lo schermo. 
Canonical oggi ha annunciato che Ubuntu 13. 10 “Saucy Salamander” è disponibile per computer da tavolo e smartphone. La prima versione mobile di Ubuntu offre un SO ottimizzato e un'interfaccia per dispositivi mobili, spianando la strada per una totale convergenza dei dispositivi e creando una piattaforma unica per l'informatica moderna. La versione 13.10 per computer da tavolo beneficia di migliorie alla funzione di ricerca Smart Scopes e alle prestazioni dei dispositivi grazie alla convergenza cellulare/PC, preparando il terreno per la convergenza totale su tutti i dispositivi. 
Il comando da Shell noto come ps (process state), ci mostra lo stato dei processi in corso all'interno del sistema; in pratica, lanciando il comando ps viene visualizzata una lista dei processi correnti; vediamo un possibile output di ps: 
KmPlot
![Elementary OS_02[3]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3wtCc3b3eP5q0h_i0QoHkGNIsAXMPzs8v2NI1-HcgqltxCd_qAKhP445osBB-HCoNL1UriF4NQZKTqO_xz3H5ILvNANUwR75a_4g7uXsNxcOH3ERcvlHW7fOTsYiRhaYiSJZbgZQxtYoi/s1600-h/Elementary%252520OS_02%25255B3%25255D%25255B2%25255D.png "Elementary OS_02[3]")
