Difference between revisions of "Systemd (Italiano)"

From ArchWiki
Jump to: navigation, search
m (FAQ)
m (Usare le unità: Fix bold)
 
(120 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 +
{{DISPLAYTITLE:systemd (Italiano)}}
 
[[Category: Daemons and system services (Italiano)]]
 
[[Category: Daemons and system services (Italiano)]]
 
[[Category: Boot process (Italiano)]]
 
[[Category: Boot process (Italiano)]]
 +
[[ar:Systemd]]
 +
[[de:Systemd]]
 +
[[el:Systemd]]
 
[[en:Systemd]]
 
[[en:Systemd]]
 
[[es:Systemd]]
 
[[es:Systemd]]
 +
[[fa:Systemd]]
 
[[fr:Systemd]]
 
[[fr:Systemd]]
 +
[[ja:Systemd]]
 +
[[pt:Systemd]]
 
[[ru:Systemd]]
 
[[ru:Systemd]]
[[zh-CN:Systemd]]
+
[[zh-hans:Systemd]]
{{Article summary start|Sommario}}
+
[[zh-hant:Systemd]]
{{Article summary text|Tratta di come installare e configurare systemd}}
+
{{Related articles start (Italiano)}}
{{Article summary heading|Articoli correlati}}
+
{{Related|systemd/User}}
{{Article summary wiki|Systemd/Services}}
+
{{Related|systemd/Timers}}
{{Article summary wiki|Init to systemd cheatsheet}}
+
{{Related|systemd FAQ_(Italiano)}}
{{Article summary wiki|udev}} - systemd e udev sono stati fusi a monte.
+
{{Related|init Rosetta}}
{{Article summary end}}
+
{{Related|udev}}
 +
{{Related|Improve Boot Performance (Italiano)}}
 +
{{Related articles end}}
 +
 
 
Dalla pagina web del  [http://freedesktop.org/wiki/Software/systemd progetto]:
 
Dalla pagina web del  [http://freedesktop.org/wiki/Software/systemd progetto]:
''"'''systemd''' è un gestore di sistema e di servizi per Linux, compatibile con gli initscript SysV e LSB. Systemd fornisce una notevole capacità di parallelizzazione, usa socket e [[D-Bus]] per l'avvio dei demoni, offre un avvio su richiesta dei demoni, tiene traccia dei processi con l'utilizzo del [[cgroups|control groups]] di Linux, supporta lo snapshotting e il restore dello stato del sistema, mantiene i punti di mount e di automount e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze. Può funzionare come rimpiazzo totale di sysvinit."''
 
{{Nota|Per una dettagliata spiegazione del motivo per cui Arch sta passando a systemd, leggi questo  [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
 
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].
 
  
== Cose da considerare prima di passare a systemd ==
+
:'''systemd''' è un gestore di sistema e di servizi per Linux. Fornisce un manager di sistema e servizi che e` avviato con PID 1 e avvia il resto del sistema. '''systemd''' fornisce una notevole capacità di parallelizzazione, usa socket e [[D-Bus]] per l'avvio dei demoni, offre un avvio su richiesta dei demoni, tiene traccia dei processi con l'utilizzo del [[cgroups|control groups]] di Linux, supporta lo snapshotting e il restore dello stato del sistema, mantiene i punti di mount e di automount e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze. '''systemd''' supporta SysV e LSB, inoltre sostituisce sysvinit. Include un demone per il logging, utility per controllare aspetti base del sistema come hostname, data, locale, lista degli utenti loggati; puo` avviare containers e macchine virtuali. Fornisce demoni per gestire la rete, sincronizzazione dell'orario, forwarding di log e name resolution.
  
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf_(Italiano)|articolo relativo a rc.conf]].  Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.
+
{{Nota|1=Per una dettagliata spiegazione del motivo per cui Arch è passato a systemd, leggi questo  [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
* [http://freedesktop.org/wiki/Software/systemd/ Documentarsi] su systemd.
 
* Notare che systemd possiede un sistema '''journal''' che rimpiazza '''syslog''', tuttavia i due possono coesistere. Vedi  [[#Journald_coesistente_al_classico_demone_syslog|la sezione relativa al journal]] più sotto.
 
* Anche se systemd può rimpiazzare le funzionalità di '''cron''', '''acpid''', o '''xinetd''', non c'è nessun bisogno di abbandonare l'uso dei demoni tradizionali a meno con non lo si voglia.
 
  
==Installazione==
+
== Uso base di systemctl ==
  
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {ic|1=init=/bin/systemd}} dai [[kernel parameters|parametri del kernel]].
+
Il principale comando usato per controllare systemd è {{ic|systemctl}}. Alcuni degli utilizzi possibili sono l'esame dello stato del sistema e la gestione del sistema e dei servizi. Vedere {{man|1|systemctl}} per maggiori dettagli
  
=== Una installazione mista systemd/sysvinit/initscripts ===
+
{{Suggerimento|Si può usare il seguente comando {{ic|systemctl}} con lo switch {{ic|-H <user>@<host>}} per controllare un'istanza di systemd su una macchina remota. Si userà [[SSH]] per connettersi all'istanza remota di systemd.}}
  
E' possibile mantenere sia systemd che sysvinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:
+
{{Nota|{{ic|systemadm}} è il frontend grafico ufficiale per {{ic|systemctl}}. E' fornito dal pacchetto {{AUR|systemd-ui-git}}{{Broken package link|{{aur-mirror|systemd-ui-git}}}} di [[AUR]].}}
  
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#I_files_di_configurazione_nativi_di_systemd|i files nativi di configurazione di systemd]], e riavviare per verificare che funzionino come ci si aspetta con gli initscripts.
+
=== Analizzare lo stato del sistema ===
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].
 
# Aggiungere {{ic|1=init=/bin/systemd}} ai [[Kernel parameters|parametri del kernel]] nel bootloader.
 
# Riavviare.
 
  
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} al boot / shutdown rispettivamente.
+
Mostra lo stato del sistema:
Se il vecchio supporto per DAEMONS in {{ic|rc.conf}} o lo scripts in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.
 
{{Attenzione|In caso si abbiano demoni nella riga DAEMONS che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se ill nome del servizio e il nome dello script rc non corrispondono, questo non funzionerà e occorre assicurarsi che solo uno dei due (preferibilmente quello nativo) sia attivato.}}
 
  
=== Una installazione mista systemd/initscripts ===
+
$ systemctl status
  
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd.
+
Lista della unità attive:
  
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts
+
$ systemctl
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable ''daemonname.'''service''' ''}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemon#List_of_Daemons|Lista dei demoni]] e dei [[Systemd/Services|servizi]]. I demoni che non hanno ancora un servizio di systemd equivalente devono essere mantenuti nella riga DAEMONS affinché systemd possa avviare il vecchio rc scripts.
 
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.
 
# Rimuovere {{ic|1=init=...}} in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.
 
# Riavviare.
 
  
La sola differenza tra questa modalità e quella di mantenere sysvinit è che tutti i files binari di sysvinit sono rimpiazzati da link simbolici a systemctl. In ogni caso, le funzionalità sono immutate.
+
oppure:
  
=== Installazione pura di systemd ===
+
$ systemctl list-units
  
Infine, è possibile rimuovere interamente initscripts e sysvinit e usare solo systemd.
+
Lista delle unità che hanno avuto problemi:
  
# Seguire le istruzioni per una installazione mista systemd/initscripts
+
$ systemctl --failed
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti.
 
# Rimuovere il pacchetto initscripts dal sistema.
 
  
=== Informazioni supplementari ===
+
I file delle unità disponibili possono essere visti in {{ic|/usr/lib/systemd/system/}} e {{ic|/etc/systemd/system/}} (questi ultimi hanno la precedenza sui primi). Si possono vedere le unità installate con:
  
{{Suggerimento|Se si utilizza {{ic|quiet}} nei parametri del kernel, è possibile rimuoverlo durante i primi avvii per identificare eventuali problemi durante il boot.}}
+
$ systemctl list-unit-files
  
== I files di configurazione nativi di systemd ==
+
=== Usare le unità ===
{{Nota|E' possibile non creare questi files.}}
 
{{Pkg|systemd}} userà {{ic|/etc/rc.conf}} se questi files sono assenti. (Si tenga nota che è una soluzione temporanea e non a lungo termine E' fortemente consigliato usare i files di configurazione di systemd su qualsiasi sistema, dato che gli initscripts possono usarli).
 
  
=== Aggiungere un hostname ===
+
Le unità possono essere, per esempio, servizi ({{ic|.service}}), punti di mount ({{ic|.mount}}), dispositivi ({{ic|.device}}) oppure sockets ({{ic|.socket}}).
{{hc|/etc/hostname|myhostname}}
 
  
=== Impostazioni di console e keymap ===
+
Quando si usa {{ic|systemctl}}, occorre generalmente specificare sempre il nome completo dell'unità compreso il suffisso, per esempio {{ic|sshd.socket}}. Esistono tuttavia delle scorciatoie quando si specifica l'unità nei seguenti comandi {{ic|systemctl}}:
:Il file /etc/vconsole.conf configura i terminali virtuali, per esempio la mappatura della tastiera ed il tipo di carattere.
 
{{hc|/etc/vconsole.conf|2=
 
KEYMAP=it
 
FONT=
 
FONT_MAP=}}
 
  
Per maggiori informazioni vedere  [[Fonts_(Italiano)#Font_per_console|i font per console]] e [[KEYMAP#Keyboard_layouts|configurazione tastiera]].
+
* Se non si specifica il suffisso, per systemctl sarà sottointeso {{ic|.service}}. Per esempio, {{ic|netctl}} e {{ic|netctl.service}} sono equivalenti.
 +
* I punti di mount saranno automaticamente tradotti nella appropriata unità {{ic|.mount}}. Per esempio, specificare {{ic|/home}} è equivalente a {{ic|home.mount}}.
 +
* Come i punti di mount, anche i dispositivi sono automaticamente tradotti nell'appropriata unità {{ic|.device}}, quindi specificare {{ic|/dev/sda2}} è equivalente a {{ic|dev-sda2.device}}.
 +
Vedi {{man|5|systemd.unit}} per dettagli.
  
{{Suggerimento|Per usare i font e la mappatura della tastiera contenuti nel kernel invece di quelli di default di systemd:
+
{{Nota| Alcune unit contengono una {{ic|@}} (e.g. {{ic|''name@string.service''}}: questo significa che sono [http://0pointer.de/blog/projects/instances.html istanze] di un {{ic|template}}, il cui filename non contiene la parte {{ic|''string''}} (e.g. {{ic|''name@.service''}}). {{ic|''string''}} e` chiamato identificatore dell'istanza ed e` simile all'argomento passato al template quando viene richiamato con il comando ''systemctl'': nelle unit verra` sostituico con {{ic|''%i''}}.
{{hc|/etc/vconsole.conf|2=
 
KEYMAP=
 
FONT=
 
</nowiki>}}
 
Questo potrebbe essere di default in futuro.
 
}}
 
  
=== Impostazioni locali ===
+
Per essere piu` accurati, prima di tentare di istanziare {{ic|''name@.estensione''}}, {{ic|systemd}} cerchera` una unit con il nome esatto.}}
Leggere le pagine man di locale.conf per maggiori opzioni:
 
{{hc|/etc/locale.conf|2=
 
LANG=it_IT.UTF-8</nowiki>}}
 
  
Per ulteriori informazioni vedere [[Locale_(Italiano)|Locale]].
+
'''Attivare''' immediatamente una unità:
  
=== Settare il fuso orario ===
+
# systemctl start ''unit''
Leggere {{ic|man 5 localtime}} per maggiori opzioni.
 
  
# ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
+
'''Fermare immediatamente''' una unità:
  
{{Nota|{{ic|/etc/timezone}} è deprecato da {{ic|systemd-190}} e può essere cancellato.}}
+
# systemctl stop ''unit''
  
=== Orario di sistema ===
+
'''Riavviare''' una unità:
  
Systemd usa UTC di default per l'orologio hardware e ciò è raccomandato. Gestire l'ora legale provoca confusione. Se l'orario legale entra in vigore quando il computer è spento, l'orologio segnerà un orario errato al successivo avvio ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html c'è molto altro sull'argomento]). I kernel recenti regolano l'orologio di sistema dall'orologio hardware direttamente al boot senza l'utilizzo di {{ic|hwclock}}, il kernel da per scontato che l'orologio hardware segni l'orario UTC. Ciò significa che se l'orologio hardware segna l'orario locale, il sistema prima imposterà un orario errato e successivamente lo correggerà ad ogni avvio. Questa è la probaile motivazione per certi strani bug (il tempo che torna indietro è raramente una buona cosa).
+
# systemctl restart ''unit''
  
La ragione per cui si imposta l'orologio hardware sull'orario locale è dovuta al dual boot con Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx il quale usa localtime]). Windows può gestire l'orologio hardware regolato su UTC con un semplice [[Time#UTC_in_Windows|aggiustamento al registro]]. Se si riscontrano problemi con il dual boot con Windows, si può impostare l'orologio di sistema su local time.
+
'''Ricaricare la configurazione''' di una unit:
  
{{hc|/etc/adjtime|
+
# systemctl reload ''unit''
0.0 0.0 0.0
 
0
 
LOCAL}}
 
  
Gli altri parametri sono ancora obbligatori ma ignorati da systemd.
+
'''Mostrare lo stato''' di una unità, compreso se sta funzionando o no:
E' generalmente consigliato avere un servizio [[NTP|Network Time Protocol daemon]] funzionante per la sincronizzazione dell'orologio del bios con quello di sistema.
 
  
=== Configurare i moduli del kernel da caricare al boot ===
+
$ systemctl status ''unit''
  
Systemd usa {{ic|/etc/modules-load.d/}} per configurare i moduli del kernel da caricare durante il boot in una lista statica. Ogni file di configurazione ha il nome nello stile di {{ic|/etc/modules-load.d/<programma>.conf/}}. I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO. Le linee vuote o quelle dove il primo carattere che non è uno spazio è # oppure ; sono ignorate. Ad esempio:
+
'''Controllare''' se una unità è già attivata o no:
{{hc|/etc/modules-load.d/virtio-net.conf|
 
# Carica virtio-net.ko al boot
 
virtio-net}}
 
  
Vedi anche [[Kernel_modules_(Italiano)#Opzioni|Opzioni di Modprobe]]
+
$ systemctl is-enabled ''unit''
  
=== Blacklist dei moduli del kernel ===
+
'''Attivare l'avvio automatico''' al boot:
  
Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli {{Pkg|initscripts}} in quanto è attualmente gestito da {{Pkg|kmod}}. Vedere [[Kernel_modules_(Italiano)#Blacklist |Blacklist dei moduli]] per maggiori dettagli.
+
# systemctl enable ''unit''
  
=== I files temporanei ===
+
Attivare l'avvio automatico al boot e avviare immediatamente una unit:
  
Systemd-tmpfiles mantiene la configurazione dei file in {{ic|/usr/lib/tmpfiles.d/}} e in {{ic|/etc/tmpfiles.d/}} per descrivere la creazione, la pulizia e la rimozione dei files e delle cartelle temporanee e volatili che normalmente risiedono in cartelle come {{ic|/run}} o {{ic|/tmp}}. Ogni file di configurazione prende il nome nello stile di {{ic|/etc/tmpfiles.d/<program>.conf}}. Ciò sovrascriverà ogni file in {{ic|/usr/lib/tmpfiles.d/}} con lo stesso nome.
+
# systemctl enable --now ''unit''
  
I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esmpio il demone [[Samba]] si aspetta che esista la cartella {{ic|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:
+
'''Disattivare l'avvio automatico''' al boot:
  
{{hc|/usr/lib/tmpfiles.d/samba.conf|
+
# systemctl disable {{ic|unit}}
D /var/run/samba 0755 root root}}
 
  
Tuttavia, tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa {{ic|/etc/rc.local}} per disabilitare il risveglio del sistema attraverso dispositivi USB con {{ic|echo USBE > /proc/acpi/wakeup}}, si può usare in alternativa il seguente tmpfile:
+
''Unmask'' di una unit:
  
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
+
# systemctl unmask ''unit''
w /proc/acpi/wakeup - - - - USBE}}
 
  
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.
+
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):
 
 
Vedi {{ic|man tmpfiles.d}} per i dettagli.
 
 
 
=== Montaggio di filesystem remoti ===
 
 
 
Systemd automaticamente si accerta che i filesystem remoti come [[NFS]] o [[Samba]] siano avviati dopo la configurazione della rete. Tuttavia i filesystem remoti specificati in {{ic|/etc/fstab}} dovrebbero funzionare ugualmente.
 
 
 
Si può utilizzare [[#Automount|Automount]] per il montaggio di filesystem remoti solo nel momento dell'accesso. Ulteriormente è possibile usare l'opzione {{ic|1=x-systemd.device-timeout=#}} in {{ic|/etc/fstab}} per specificare un tempo massimo nel caso la risorsa di rete non sia disponibile.
 
 
 
Vedi {{ic|man systemd.mount}} per dettagli.
 
 
 
=== ACPI Power Management con systemd ===
 
 
 
Systemd gestisce degli eventi ACPI relativi all'alimentazione. Ciò viene configurato attraverso le seguenti opzioni di {{ic|/etc/systemd/logind.conf}}:
 
 
 
* {{ic|HandlePowerKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
 
* {{ic|HandleSuspendKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
 
* {{ic|HandleHibernateKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
 
* {{ic|HandleLidSwitch}} : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.
 
 
 
Le azioni specificate possono essere una qualsiasi di {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.
 
  
Se queste opzioni non sono configurate, systemd userà quelle di default: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.
+
$ systemctl help ''unit''
  
Su sistemi che non hanno una configurazione grafica o semplici gestori di finestre come [[i3]] o [[awesome]], può rimpiazzare il demone [[acpid]]  che è solitamente usato per gestire questi eventi ACPI.
+
'''Ricaricare systemd''', controllo per nuove o modificate unità:
 
 
Nell'attuale versione di systemd, le opzioni  {{ic|Handle}} saranno applicate al sistema finché non saranno "inibite" (temporaneamente spente) da un programma, come un gestore di alimentazione in un DE. Se questi inibitori non sono usati, si può finire in una situazione in cui systemd sospende il sistema , poi al risveglio gli altri gestori di alimentazione lo sospendono di nuovo.
 
 
 
{{Nota|Attualmente, il gestore di alimentazione del più recente [[KDE]] è l'unico che possiede i necessari comandi inibitori. Quando li avranno anche gli altri, occorrerà settare l'opzione {{ic|Handle}} a {{ic|ignore}} se si voglio gestire gli eventi ACPI con [[GNOME]], [[Xfce]], [[acpid]] o qualsiasi altro programma. Le nuove versioni stanno implementando tale funzionalità.}}
+
# systemctl daemon-reload
  
=== Sleep hooks ===
+
=== Power management ===
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:
 
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando
 
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è stato invocato.
 
  
Al contrario di [[Pm-utils_(Italiano)|Pm-utils]], systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.
+
{{ic|polkit}} è indispensabile per la gestione energetica.
 +
Se ci si trova in una sessione locale di {{ic|systemd-logind}}  e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), systemd automaticamente richiederà la password di root.
  
L'output del vostro script sarà registrato da {{ic|systemd-suspend.service}} o {{ic|systemd-hibernate.service}} cosicché è possibile vedere i propri outputs nel [[Systemd_(Italiano)#Il Journal_di_Systemd|journal]].
+
Spegnimento e riavvio del sistema:
  
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.
+
$ systemctl reboot
  
Vedi {{ic|man systemd.special}} e {{ic|man systemd-sleep}} per maggiori informazioni.
+
Spegnimento del sistema:
  
==== Esempi ====
+
$ systemctl poweroff
  
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki>
+
Sospensione del sistema:
#!/bin/sh
 
  
case "$1" in
+
$ systemctl suspend
  pre )
 
    echo going to $2
 
    ;;
 
  post )
 
    echo waking up from $2
 
    ;;
 
esac</nowiki>}}
 
  
=== Unità ===
+
Ibernazione del sistema:
  
Un file di configurazione di unità racchiude informazioni riguardanti un servizio, un socket, un dispositivo, un punto di montaggio, un punto di automontaggio, un file o una partizione di swap, un obbiettivo di avvio, un percorso del filesystem oppure un controllo schedulato da systemd. La sintassi è ispirata da "XDG Desktop Entry Specification" files di tipo .desktop, che a loro volta richiamano i files .ini di windows. Vedi {{ic|man systemd.unit}} per maggiori informazioni.
+
$ systemctl hibernate
  
== Comandi di Systemd ==
+
Stato ibrido di riposo (o suspend-to-both):
*{{ic|systemctl}}: utilizzato per controllare lo stato del gestore di servizi e del sistema systemd
+
*{{ic|systemd-cgls}}: mostra ricorsivamente i contenuti della gerarchia del gruppo di controllo Linux selezionato con uno schema ad albero
+
$ systemctl hybrid-sleep
*{{ic|systemadm}}: Un frontend grafico per systemd che permette un profondo controllo del sistema (disponibile attraverso il pacchetto {{AUR|systemd-ui-git}} di [[AUR]]).
 
  
Vedi le pagine man per ulteriori dettagli.
+
== Avviare DM con systemd ==
  
{{Suggerimento|Si può usare il seguente comando {{ic|systemctl}} con lo switch {{ic|-H <user>@<host>}} per controllare un'istanza di systemd su una macchina remota. Si userà [[SSH]] per connettersi all'istanza remota di systemd.}}
+
Per avviare il login grafico, abilitare il demone del suo [[Display manager (Italiano)|Display Manager]] corrispondente (per esempio [[KDM_(Italiano)|KDM]]). Attualmente esistono i .service per [[GDM]], [[KDM_(Italiano)|KDM]], [[SLiM_(Italiano)|SLiM]], [[XDM]] and [[LXDM]] e [[LightDM]].
  
=== Analizzare lo stato del sistema ===
+
# systemctl enable kdm
  
Lista della unità attive:
+
Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:
  
$ systemctl
+
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
  
oppure:
+
è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio {{ic|graphical.target}}).
  
  $ systemctl list-units
+
  # rm /etc/systemd/system/default.target
  
Lista delle unità che hanno avuto problemi:
+
=== Usare systemd-logind ===
  
$ systemctl --failed
+
Per controllare lo stato della propria sessione utente, si può utilizzare {{ic|loginctl}}. Tutte le azioni di [[PolicyKit]] come la sospensione del sistema o il montaggio di dispositivi esterni funzioneranno automaticamente.
  
I file delle unità disponibili possono essere visti in {{ic|/usr/lib/systemd/system/}} e {{ic|/etc/systemd/system/}} (questi ultimi hanno la precedenza sui primi). Si possono vedere le unità installate con:
+
$ loginctl show-session $XDG_SESSION_ID
  
$ systemctl list-unit-files
+
== Configurazione nativa ==
  
=== Usare le unità ===
+
{{Nota|E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a  {{ic|644}} e il proprietario {{ic|root:root}}}}
  
Le unità possono essere, per esempio, servizi ({{ic|.service}}), punti di monatggio ({{ic|.mount}}), dispositivi ({{ic|.device}}) oppure i sockets ({{ic|.socket}}).  
+
=== Hostname ===
 +
L'hostname è configurato in {{ic|/etc/hostname}}. Il file può contenere il nome del dominio di sistema, se esiste, tuttavia nel momento di scrivere {{ic|hostnamectl}} non si può configurare il FQDN. Per configurare l'hostname corto:
  
Quando si usa {{ic|systemctl}}, occorre generalmente specificare sempre il nome completo dell'unità compreso il suffisso, per esempio {{ic|sshd.socket}}. Esistono tuttavia delle scorciatoie quando si specifica l'unità nei seguenti comandi {{ic|systemctl}}:
+
# hostnamectl set-hostname '''myhostname'''
  
* Se non si specifica il suffisso, per systemctl sarà sottointeso {{ic|.service}}. Per esempio, {{ic|netcfg}} e {{ic|netcfg.service}} sono equivalenti.
+
See {{man|5|hostname}} e {{man|1|hostnamectl}} per dettagli.
{{Nota|Attualmente non funzionante con i comandi {{ic|enable}} e {{ic|disable}}.}}
 
* I punti di montaggio saranno automaticamente tradotti nella appropriata unità {{ic|.mount}}. Per esempio, specificare {{ic|/home}} è equivalente a {{ic|home.mount}}.
 
* Come i punti di montaggio, anche i dispositivi sono automaticamente tradotti nell'appropriata unità {{ic|.device}}, quindi specificare {{ic|/dev/sda2}} è equivalente a {{ic|dev-sda2.device}}.
 
Vedi {{ic|man systemd.unit}} per dettagli.
 
  
Attivare immediatamente una unità:
+
Esempio di file:
 +
{{hc|/etc/hostname|
 +
myhostname
 +
}}
  
# systemctl start <unit>
+
=== Impostazioni locali ===
  
Fermare immediatamente una unità:
+
{{Note|Before you set the default locale, you first need to enable locales available to the system by uncommenting them in {{ic|/etc/locale.gen}} and then executing {{ic|locale-gen}} as root. The locale set via {{ic|localectl}} must be one of the '''uncommented''' locales in {{ic|/etc/locale.gen}}.}}
 +
Le impostazioni locali di default sono configurate in {{ic|/etc/locale.conf}} Per configurare il locale di default:  
  
  # systemctl stop <unit>
+
  # localectl set-locale LANG="it_IT.utf8"
 +
 +
Vedere {{man|1|localectl}} e {{man|5|locale.conf}} per dettagli.
 +
 +
Per ulteriori informazioni vedere [[Locale_(Italiano)|Locale]].
  
Far ripartire una unità:
+
Esempio di file:
 +
{{hc|/etc/locale.conf|<nowiki>
 +
LANG=it_IT.utf8
 +
</nowiki>}}
  
# systemctl restart <unit>
+
=== Console virtuale ===
 +
La console virtuale (la mappatura della tastiera, i caratteri della console e la mappatura della console) è configurata in {{ic|/etc/vconsole.conf}}:
  
Chiedere ad una unità di ricaricare la sua configurazione:
+
{{hc|/etc/vconsole.conf|2=
 +
KEYMAP=it
 +
FONT=
 +
FONT_MAP=}}
  
# systemctl reload <unit>
+
{{Nota|Da {{pkg|systemd}}-194, si utilizzano i caratteri integrati nel kernel e la mappatura della tastiera "us" se {{ic|1=KEYMAP=}} e {{ic|1=FONT=}} sono vuoti o non configurati.}}
  
Mostrare lo stato di una unità, compreso se sta funzionando o no:
+
Un altro modo di configurare la mappatura della tastiera è:
  
  $ systemctl status <unit>
+
  # localectl set-keymap it
  
Controllare se una unità è già attivata o no:
+
<code>localectl</code> può essere usato anche per configurare la tastiera in ambiente X:
 +
 +
# localectl set-x11-keymap it
  
$ systemctl is-enabled <unit>
+
Vedere {{man|1|localectl}} e {{man|5|vconsole.conf}} per maggiori dettagli.
  
Attivare l'avvio automatico al boot:
+
Per maggiori informazioni vedere  [[Fonts_(Italiano)#Font_per_console|i font per console]] e [[KEYMAP|configurazione tastiera]].
  
# systemctl enable <unit>
+
=== Orario di sistema ===
  
{{Nota| Se i servizi non hanno una sezione Install, significa, di solito, che sono evocati automaticamente da altri servizi.  Me se occorre installarli manualmente usare il seguente comando rimpiazzando {{ic|foo}} con il nome del servizio.
+
Systemd usa '''UTC''' di default per l'orologio hardware.
  
# ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/
+
{{Suggerimento|E' generalmente consigliato avere [[NTP|il demone Network Time Protocol]] attivo per mantenere l'orologio di sistema sincronizzato con Internet e con l'orologio del bios.}}
}}
+
 +
==== Orologio hardware in localtime ====
 +
 +
Se si vuole cambiare l'orologio hardware ad usare l'orario locale ('''ALTAMENTE SCONSIGLIATO'''):
  
Disattivare l'avvio automatico al boot:
+
# timedatectl set-local-rtc true
  
# systemctl disable <unit>
+
Se si vuole riconvertirlo a UTC:
  
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):
+
# timedatectl set-local-rtc false
  
$ systemctl help <unit>
+
Attenzione che, se l'orologio hardware è configurato a localtime, la gestione dell'orario legale è persa. Se l'orario legale cambia finché il computer è spento il proprio orario sarà sbagliato al prossimo riavvio ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ulteriori approfondimenti]). I kernel recenti configurano l'orario di sistema dall'orologio hardware direttamente al boot, presupponendo che l'orologio hardware sia impostato a UTC. Questo significa che se l'orologio hardware è su locale l'orologio di sistema sarà prima configurato sbagliato e poi corretto ad ogni boot. Questa è la causa di alcuni noiosi bugs (il tempo che torna indietro è raramente una buona cosa).
  
=== Power Management ===
+
Una ragione per permettere che l'orologio hardware sia settato sul'orario locale è quella del dual boot con Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx il quale usa localtime]). Tuttavia, Windows è in grado di gestire l'orario con l'orologio hardware settato su UTC con un semplice  [[Time#UTC in Windows|aggiustamento del registro di sistema]]. Quindi, è consigliato configurare Windows affinché usi UTC, piuttosto che Linux usi localtime. Se si usa UTC su Windows, ricordarsi inoltre di disabilitare l'opzione di Windows "Internet Time Update", al fine di evitare confusione tra windows e l'orologio hardware, nel tentativo di sincronizzazione con l'orario internet. Al contrario, occorre lasciare che Linux sincronizzi l'orario di sistema con l'orario internet attivando il demone [[NTP]], come suggerito precedentemente.
  
Se ci si trova in una sessione locale di  {{ic|systemd-logind}} oppure [[ConsoleKit]] e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), systemd automaticamente richiederà la password di root (vedi anche [[#Rimpiazzare_ConsoleKit_con_systemd-logind|Rimpiazzare ConsoleKit con systemd-logind]])..
+
* Per maggiori informazioni vedere [[Time]].
  
Spegnimento e riavvio del sistema:
+
=== Moduli del Kernel ===
 +
 +
Ad oggi, tutti i moduli necessari da caricare sono gestiti automaticamente da [[udev]], cosicché, se non si vuole usare qualcuno dei moduli fuori dal kernel, non c'è bisogno di mettere i moduli che dovrebbero essere caricati al boot in nessun file di configurazione. Tuttavia, ci sono casi in cui si vuole caricare un modulo extra durante il processo di avvio oppure evitare il caricamento di un altro perché il computer funzioni correttamente.
 +
 +
==== Moduli extra da caricare all'avvio ====
  
$ systemctl reboot
+
I moduli extra al kernel da caricare durante il boot sono configurati in una lista statica in {{ic|/etc/modules-load.d/}}. Ogni file di configurazione ha il nome nello stile di {{ic|/etc/modules-load.d/<programma>.conf/}}. I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO. Le linee vuote o quelle dove il primo carattere che non è uno spazio è # oppure ; sono ignorate. Ad esempio:
 +
{{hc|/etc/modules-load.d/virtio-net.conf|
 +
# Carica virtio-net.ko al boot
 +
virtio-net}}
  
Spegnimento del sistema:
+
vedere {{man|5|modules-load.d}} per maggiori dettagli.
  
$ systemctl poweroff
+
==== Configurare le opzioni dei moduli ====
 +
 +
Ulteriori opzioni per i moduli devono essere impostati in {{ic|/etc/modprobe.d/modprobe.conf}}.
 +
 +
Esempio:
 +
 +
* Abbiamo il file {{ic|/etc/modules-load.d/loop.conf}} con all'interno il modulo {{ic|loop}} da far caricare durante la fase di boot.
 +
 +
* in {{ic|/etc/modprobe.d/modprobe.conf}} specifichiamo le opzioni addizionali, es. {{ic|options loop max_loop&#61;64}}
 +
 +
In seguito, l'opzione appena impostato potrebbe essere verificata tramite {{ic|cat /sys/module/loop/parameters/max_loop}}
  
Spegnimento completo del sistema:
+
==== Blacklisting ====
  
$ systemctl halt
+
Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli {{Pkg|initscripts}}{{Broken package link|package not found}} in quanto è attualmente gestito da {{Pkg|kmod}}. Vedere [[Kernel_modules_(Italiano)#Blacklist|Blacklist dei moduli]] per maggiori dettagli.
  
Sospensione del sistema:
+
=== Montaggio del filesystem ===
  
  $ systemctl suspend
+
La configurazione di default controlla e monta i filesystems prima di avviare i servizi ai quali occorre che siano montati. Per esempio, systemd automaticamente si assicura che il montaggio di filesystems come [[NFS]] o [[Samba]] avvenga solo dopo che la rete è attiva. Pertanto, il montaggio dei filesystems, sia locali che remoti, specificati in {{ic|/etc/fstab}} dovrebbe funzionare senza problemi.
  
Ibernazione del sistema:
+
Vedere {{man|5|systemd.mount}} per dettagli.
  
$ systemctl hibernate
+
==== Automount ====
  
== Runlevel/target ==
+
* Se si possiede una grande partizione {{ic|/home}}, sarebbe meglio permettere ai servizi che non dipendono da essa di avviarsi durante il controllo di {{ic|/home}} da parte di fsck. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in {{ic|/etc/fstab}}:
  
Quello dei "runlevels" è un concetto superato in systemd. Systemd ha il concetto di ''target'' (lett. "bersagli") che adempiono uno scopo simile a quello dei runlevel, ma che hanno un comportamento leggermente differente. Ogni ''target'' ha un nome anziché un numero ed è usato per raggiungere uno specifico scopo con la possibilità di averne più di uno attivo nello stesso momento. Alcuni ''targets'' sono attivati ereditando tutto dei servizi di un altro ''target'' e implementandolo di servizi addizionali. Ci sono ''target'' che simulano i runlevel di SystemVinit, è così possibile passare da un ''target'' all'altro utilizzando il comando {{ic|telinit RUNLEVEL}}.
+
noauto,x-systemd.automount
  
=== Conoscere il runlevel/targets corrente ===
+
Questo controllerà e monterà {{ic|/home}} al primo accesso, e il kernel memorizzerà in un buffer tutti gli accessi ai file in {{ic|/home}} finché non sarà pronta.
  
Il seguente comando dovrebbe essere usato sotto systemd al posto di {{ic|runlevel}}:
+
Nota: questo renderà il filesystem {{ic|/home}} di tipo {{ic|autofs}}, che è ignorato da [[mlocate]] di default. La velocità di montaggio automatico di {{ic|/home}} non può essere maggiore di un secondo o due, a seconda del proprio sistema, quindi è possibile che non valga la pena di utilizzare questo trucco.
# systemctl list-units --type=target
 
  
=== Creare un target personalizzato ===
+
* Lo stesso si può applicare al montaggio dei filesystems remoti. Se si desidera montarli successivamente all'accesso occorrerà usare i parametri {{ic|noauto,x-systemd.automount}}. In aggiunta, si può usare l'opzione {{ic|1=x-systemd.device-timeout=#}} per specificare un tempo di timeout in caso la risorsa di rete non sia disponibile.
  
I runlevels sono assegnati ad uno specifico scopo su l'installazione vanilla di Fedora; 0, 1, 3, 5, e 6; hanno una mappatura 1:1 con uno specifico ''target'' di systemd. Sfortunatamente non c'è un altrettanto buon metodo per i runlevels definiti dall'utente come 2 e 4. Se si fa uso di questi, si suggerisce di dare un nuovo nome al ''target'' di systemd come {{ic|/etc/systemd/system/<your target>}} che prenda come base une dei runlevels esistenti (vedi {{ic|/usr/lib/systemd/system/graphical.target}} come esempio), creare una cartella  {{ic|/etc/systemd/system/<your target>.wants}}, e fare un collegamento ai servizi addizionali da {{ic|/usr/lib/systemd/system/}} che si intendono attivare.
+
* Se si hanno filesystems criptati con keyfiles, si può comunque aggiungere il parametro {{ic|noauto}} alla corrispondente riga in {{ic|/etc/crypttab}}. Systemd non aprirà il supporto corispondente all'avvio, ma aspetterà finché non avverrà un accesso e quindi automaticamente aprirà il keyfile specifico prima di montarlo. Questo potrebbe far risparmiare un po' di secondi al boot se si sta per esempio utilizzando un supporto RAID criptato, in quanto systemd non deve aspettare finché il dispositivo non sarà disponibile. Per esempio:
  
=== Targets table ===
+
{{hc|/etc/crypttab|
 +
data /dev/md0 /root/key noauto}}
  
{| border="1"
+
==== LVM ====
!SysV Runlevel!!Systemd Target!!Notes
 
|-
 
| 0 || runlevel0.target, poweroff.target || Ferma il sistema.
 
|-
 
| 1, s, single || runlevel1.target, rescue.target || Modalità utente singolo (single user).
 
|-
 
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definita dall'utente. Preconfigurata a 3.
 
|-
 
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical.  Users can usually login via multiple consoles or via the network.
 
|-
 
| 5 || runlevel5.target, graphical.target || Multi-user, grafica.  Solitamente ha tutti i servizi del runlevel 3  con l'aggiunta di un login grafico.
 
|-
 
| 6 || runlevel6.target, reboot.target || Riavvio
 
|-
 
| emergency || emergency.target || Console di emergenza
 
|-
 
|}
 
  
=== Cambiare il runlevel corrente ===
+
Se si possiede un volume [[LVM]] non attivato durante [[Mkinitcpio|l'initramfs]], attivare il servizio {{ic|lvm-monitoring}} fornito dal pacchetto {{pkg|lvm2}}:
  
In systemd i runlevels sono esplicitati per mezzo di "target units". Si possono cambiare così:
+
# systemctl enable lvm-monitoring.service
  
# systemctl isolate graphical.target
+
=== ACPI power management ===
  
Questo comando cambierà solamente il runlevel corrente e non avrà nessun effetto sul prossimo avvio. Questo è equivalente ai comandi {{ic|telinit 3}} oppure {{ic|telinit 5}} in Sysvinit.
+
Systemd gestisce degli eventi [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di {{ic|/etc/systemd/logind.conf}}:
  
=== Cambiare il runlevel/target predefinito all'avvio ===
+
* {{ic|HandlePowerKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
 +
* {{ic|HandleSuspendKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
 +
* {{ic|HandleHibernateKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
 +
* {{ic|HandleLidSwitch}} : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.
  
Il target standard è {{ic|default.target}}, che è abbinato in modo predefinito a {{ic|graphical.target}} (che corrisponde al vecchio runevel 5). Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:
+
Le azioni specificate possono essere una qualsiasi di {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}},  {{ic|hybrid-sleep}} o {{ic|kexec}}.
* {{ic|1=systemd.unit=multi-user.target}} (che corrisponde al vecchio runevel 3),
 
* {{ic|1=systemd.unit=rescue.target}} (che corrisponde al vecchio runevel 1).
 
  
In alternativa si può lasciare il bootloader inalterato e cambiare  {{ic|default.target}}. Ciò può essere fatto usando {{ic|systemctl}}:
+
Se queste opzioni non sono configurate, systemd userà quelle di default: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.
  
  # systemctl enable multi-user.target
+
Su sistemi che non hanno una configurazione grafica o semplici gestori di finestre come [[i3]] o [[awesome]], può rimpiazzare il demone [[acpid]] che è solitamente usato per gestire questi eventi ACPI.
  
L'effetto di questo comando si nota nell'output di {{ic|systemctl}}; viene creato un link simbolico al nuovo target predefinito {{ic|/etc/systemd/system/default.target}}. Questo funziona solo se:
+
{{Nota|Digitare {{ic|systemctl restart systemd-logind.service}} perchè le modifiche abbiano effetto.}}
  
[Install]
+
{{Nota|Systemd non riesce a gestire gli eventi di alimentazione di rete e di batteria, sicché è ancora richiesto l'uso di [[Laptop Mode Tools]] o altri strumenti [[acpid]] similari.}}
Alias=default.target
 
  
si trova nel file di configurazione del target. Attualmente, sia {{ic|multi-user.target}} che {{ic|graphical.target}} lo possiedono.
+
Nell'attuale versione di systemd, le opzioni  {{ic|Handle*}} saranno applicate al sistema finché non saranno "inibite" (temporaneamente spente) da un programma, come un gestore di alimentazione in un DE. Se questi inibitori non sono usati, si può finire in una situazione in cui systemd sospende il sistema , poi al risveglio gli altri gestori di alimentazione lo sospendono di nuovo.
 +
 +
{{Attenzione|Attualmente, i gestori di alimentazione delle versioni più recenti di [[KDE]] e [[GNOME]] sono gli unici che possiedono i necessari comandi inibitori. Quando li avranno anche gli altri, occorrerà settare l'opzione {{ic|Handle}} a {{ic|ignore}} se si voglio gestire gli eventi ACPI con [[Xfce]], [[acpid]] o qualsiasi altro programma.}}
  
== Avviare un DE con systemd ==
+
{{Nota|Systemd può anche usare altri backends per la sospensione  (come [[Uswsusp]] o [[TuxOnIce]]), in aggiunta al backend di default del ''kernel'', al fine di mettere il computer in uno stato di sleep o ibernazione.}}
  
Per avviare il login grafico, abilitare il demone del suo [[Display Manager_(Italiano)|Display Manager]] corrispondente (per esempio [[KDM_(Italiano)|KDM]]). Attualmente esistono i .service per [[GDM]], [[KDM_(Italiano)|KDM]], [[SLiM_(Italiano)|SLiM]], [[XDM]] and [[LXDM]] e [[LightDM]].
+
For {{ic|systemctl hibernate}} to work on your system you need to follow instructions at [[Pm-utils#Hibernation_.28suspend2disk.29|Hibernation]] and possibly at [[Pm-utils#Mkinitcpio_Resume_Hook|Mkinitcpio Resume Hook]]{{Broken section link}} ({{ic|pm-utils}} does not need to be installed).  
  
# systemctl enable kdm.service
+
==== Sleep hooks ====
  
Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:
+
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}}, {{ic|systemctl hibernate}} oppure {{ic|systemctl hybrid-sleep}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce due meccanismi simili per avviare script personali in base a questi eventi.  
  
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
+
===== Suspend/resume service files =====
  
è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio {{ic|graphical.target}}).
+
Dei service files possono essere agganciati a suspend.target, hibernate.target e sleep.target per eseguire azioni prima o dopo  la sospensione lo l'ibernazione. Files separati dovrebbero essere creati per azioni degli utenti e azioni di sistema (root). Per attivare i servizi degli utenti, {{ic|# systemctl enable suspend@<user> && systemctl enable resume@<user>}}. Esempi:
  
# rm /etc/systemd/system/default.target
+
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki>
 +
[Unit]
 +
Description=User suspend actions
 +
Before=sleep.target
  
=== Usare i service file ===
+
[Service]
 +
User=%I
 +
Type=forking
 +
Environment=DISPLAY=:0
 +
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
 +
ExecStart=/usr/bin/sflock
  
{{Nota|Usando questo modo non si creerà nessuna sessione di PAM per il proprio utente. Tuttavia ConsoleKit (il quale fornisce accesso all'avvio/spegnimento, alle periferiche audio etc.) non funzionerà in modo corretto. Per il metodo raccomandato vedere:
+
[Install]
[[#Rimpiazzare_ConsoleKit_con_systemd-logind|Rimpiazzare ConsoleKit con systemd-logind]] e [[Automatic_login_to_virtual_console_(Italiano)#Usare_systemd]].}}
+
WantedBy=sleep.target</nowiki>}}
  
Se si sta cercando un modo semplice per avviare X direttamente senza un DM si può creare un file .service come questo:
+
{{hc|/etc/systemd/system/resume@.service|2=<nowiki>
 
 
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|2=
 
 
[Unit]
 
[Unit]
Description=Direct login to X
+
Description=User resume actions
After=systemd-user-sessions.service
+
After=suspend.target
  
 
[Service]
 
[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"
+
User=%I
 +
Type=simple
 +
ExecStartPre=/usr/local/bin/ssh-connect.sh
 +
ExecStart=/usr/bin/mysql -e 'slave start'
  
 
[Install]
 
[Install]
WantedBy=graphical.target}}
+
WantedBy=suspend.target</nowiki>}}
  
 +
Per azioni di sistema o root (attivare con {{ic|# systemctl enable root-suspend}}):
  
== Il Journal di Systemd ==
+
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki>
 +
[Unit]
 +
Description=Local system resume actions
 +
After=suspend.target
  
Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal.
+
[Service]
 +
Type=simple
 +
ExecStart=/usr/bin/systemctl restart mnt-media.automount
  
Come prassi, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:
+
[Install]
 +
WantedBy=suspend.target</nowiki>}}
  
# journalctl
+
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki>
 +
[Unit]
 +
Description=Local system suspend actions
 +
Before=sleep.target
  
Il sistema journal scrive in {{ic|/run/systemd/journal}}, il ché significa che i logs svaniscono ad ogni riavvio. Per avere dei logs non volatili bisogna creare {{ic|/var/log/journal/}}:
+
[Service]
 +
Type=simple
 +
ExecStart=-/usr/bin/pkill sshfs
  
# mkdir /var/log/journal/
+
[Install]
 +
WantedBy=sleep.target</nowiki>}}
  
=== Filtrare l' output ===
+
Un paio di consigli a proposito di questi servizi (maggiori informazioni in {{man|5|systemd.service}}):
 +
* Se si usa {{ic|1=<nowiki>Type=OneShot</nowiki>}} si possono usare linee {{ic|1=<nowiki>ExecStart=</nowiki>}} multiple. Altrimenti solo una linea ExecStart è permessa. Si possono aggiungere più comandi con {{ic|ExecStartPre}} oppure separandoli con un punto e virgola (vedere il primo esempio più su -- notare gli spazi prima e dopo il punto e virgola... sono indispensabili!).
 +
* Un comando preceduto da  '-' causerà una uscita con stato non-zero  per essere ignorato e trattato come un comando successivo.
 +
* Il miglior modo per trovare gli errori in questi servizi è naturalmente con {{ic|journalctl}}.
  
{{ic|journalctl}} permette di filtrare l'output secondo specifici campi.
+
===== Servizi combinati di Suspend/resume =====
 +
 +
Con il servizio combinato suspend/resume, un singolo collegamento fa tutto il lavoro per le varie fasi (sleep/resume) e per i differenti targets (suspend/hibernate/hybrid-sleep).
 +
 +
Esempi e spiegazioni:
 +
 +
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki>
 +
[Unit]
 +
Description=Wicd sleep hook
 +
Before=sleep.target
 +
StopWhenUnneeded=yes
  
Esempi:
+
[Service]
 +
Type=oneshot
 +
RemainAfterExit=yes
 +
ExecStart=-/usr/share/wicd/daemon/suspend.py
 +
ExecStop=-/usr/share/wicd/daemon/autoconnect.py
  
Mostra tutti i messaggi di un eseguibile specifico:
+
[Install]
 +
WantedBy=sleep.target</nowiki>}}
  
# journalctl /usr/lib/systemd/systemd
+
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: Dopo averlo avviato, il servizio è considerato attivo fino a quando non è esplicitamente fermato.
 +
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: Quando è attivo, il servizio sarà fermato se nessun altro servizio necessita di esso. Nell'esempio specifico, sarà fermato dopo che sleep.target sarà fermato.
 +
* Perché sleep.target venga richiamato da suspend.target, hibernate.target e hybrid-sleep.target e sleep.target esso stesso è un StopWhenUnneeded service, il collegamento garantisce l'avvio e la fermata corretta per diversi compiti.
  
Mostra tutti i messaggi di uno specifico processo:
+
===== Hooks in /usr/lib/systemd/system-sleep =====
  
# journalctl _PID=1
+
Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:
 +
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando
 +
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} oppure {{ic|hybrid-sleep}}, dipende da quello che è stato invocato.
  
Mostra tutti i messaggi di una specifica unità:
+
Al contrario di [[Pm-utils_(Italiano)|Pm-utils]], systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.
  
  # journalctl _SYSTEMD_UNIT=netcfg.service
+
L'output di ogni script personalizzato sarà registrato da {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}} oppure {{ic|systemd-hybrid-sleep.service}} cosicché sarà possibile vedere i propri outputs nel [[#Il Journal|journal]]:
 +
  # journalctl -b -u systemd-suspend
  
 +
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}}, {{ic|hibernate.target}} oppure {{ic|hybrid-sleep.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts personalizzati.
  
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} per dettagli.
+
Un esempio di script personalizzato:
  
==== Limiti alla dimensione del journal ====
+
{{hc|/usr/lib/systemd/system-sleep/example.sh|
 +
#!/bin/sh
 +
case $1/$2 in
 +
  pre/*)
 +
    echo "Going to $2..."
  
Se il journal è creato come non volatile la sua dimensione è fissata al 10% della dimensione del rispettivo file system. Per esempio con {{ic|/var/log/journal}} allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal. La dimensione massima del journal persistente può essere controllata attraverso {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:
+
    ;;
 +
  post/* )
 +
    echo "Waking up from $2..."
 +
    ;;
 +
esac}}
  
SystemMaxUse=50M
+
Non dimenticare di rendere lo script eseguibile:
 +
+
 +
# chmod a+x /usr/lib/systemd/system-sleep/example.sh
  
Fare riferimento a {{ic|man journald.conf}} per maggiori dettagli.
+
Vedere {{man|7|systemd.special}} e {{man|8|systemd-sleep}} per maggiori dettagli.
  
====Journald coesistente al classico demone syslog====
+
=== File temporanei ===
  
La compatibilità con il classico syslog è fornita dal socket {{ic|/run/systemd/journal/syslog}}, attraverso il quale passano tutti i messaggi.
+
Systemd-tmpfiles mantiene la configurazione dei file in {{ic|/usr/lib/tmpfiles.d/}} e in {{ic|/etc/tmpfiles.d/}} per descrivere la creazione, la pulizia e la rimozione dei files e delle cartelle temporanee e volatili che normalmente risiedono in cartelle come {{ic|/run}} o {{ic|/tmp}}. Ogni file di configurazione prende il nome nello stile di {{ic|/etc/tmpfiles.d/<program>.conf}}. Ciò sovrascriverà ogni file in {{ic|/usr/lib/tmpfiles.d/}} con lo stesso nome.
Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). Nel caso di syslog-ng cambiare la sezione {{ic|source src}} di {{ic|/etc/syslog-ng/syslog-ng.conf}} così:
 
  
source src {
+
I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esmpio il demone [[Samba]] si aspetta che esista la cartella {{ic|/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:
    unix-dgram("/run/systemd/journal/syslog");
 
    internal();
 
    file("/proc/kmsg");
 
}
 
  
e attivare syslog-ng:
+
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 +
D /run/samba 0755 root root}}
  
# systemctl enable syslog-ng.service
+
I tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa {{ic|/etc/rc.local}} per disabilitare il risveglio del sistema attraverso dispositivi USB con {{ic|echo USBE > /proc/acpi/wakeup}}, si può usare in alternativa il seguente tmpfile:
  
== Network ==
+
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 +
w /proc/acpi/wakeup - - - - USBE}}
  
=== Dinamico (DHCP)con dhcpcd ===
+
Vedi {{man|5|tmpfiles.d}} per i dettagli.
 +
{{nota|Questo metodo potrebbe non funzionare per impostare le opzioni in {{ic|/sys}} poiché il servizio {{ic|systemd-tmpfiles-setup}} può eseguirsi prima che i moduli delle periferiche appropriate siano caricati. In questo caso si potrebbe verificare che il modulo abbia un parametro per l'opzione che si desidera impostare con {{ic|modinfo <module>}} e impostare questa opzione con un [[Modprobe.d#Configuration|file di configurazione in {{ic|/etc/modprobe.d}}]]{{Broken section link}}. In caso contrario si dovrà scrivere una [[Udev#About_udev_rules|regola udev]] per impostare l' attributo appropriato non appena viene visualizzato il dispositivo.}}
  
Se si vuole semplicemente utilizzare DHCP per la connessione Ethernet, si può usare {{ic|dhcpcd@.service}} (fornito dal pacchetto {{Pkg|dhcpcd}}.
+
=== Unità ===
Per utilizzare DHCP per {{ic|eth0}}, semplicemente usare:
 
# systemctl start dhcpcd@eth0.service
 
 
 
Si può attivare l'avvio automatico al boot con:
 
# systemctl enable dhcpcd@eth0.service
 
 
 
Alcune volte il servizio dhcpd si avvia prima del modulo della scheda di rete ({{bug|30235}}), aggiungere manualmente il modulo della propria scheda di rete a {{ic|/etc/modules-load.d/****.conf}}.  Esempio: creare {{ic|/etc/modules-load.d/r8169.conf}},, per una scheda realtek
 
# r8169
 
 
 
=== Altre configurazioni ===
 
 
 
Per reti statiche, wireless o configurazioni avanzate come il bridging si può usare [[Netcfg#systemd_support|netcfg]] o [[NetworkManager_(Italiano)#Abilitare_NetworkManager_nativamente_in_systemd|NetworkManager]] i quali forniscono entrambi dei file service di systemd.
 
 
 
{{Nota|Se si ha intenzione di usare netcfg, networkmanager oppure un altro software per gestire la rete non si deve avviare o attivare dhcpcd come visto nel precedente paragrafo.}}
 
 
 
Se occorre configurare la rete Ethernet in modo statico, ma non si vuole usare [[netcfg]], c'é un servizio personalizzato disponibile alla [[Systemd/Services#Static_Ethernet_network|pagina dei servizi di systemd]].
 
 
 
== Integrazione con Arch ==
 
 
 
=== Emulazione degli initscripts ===
 
 
 
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Questo è semplicemente inteso come una misura transitoria per facilitare il passaggio degli utenti a systemd.
 
 
 
{{Nota|{{ic|/etc/inittab}} non è più usato.}}
 
 
 
Se ci si ritrova disabilitato {{keypress|Ctrl+Alt+Del}} per riavviare, occorre riconfigurare questa opzione per systemd eseguendo {{ic|systemctl mask ctrl-alt-del.target}} da root.
 
 
 
==== rc.conf ====
 
 
 
Alcune variabili in{{ic|/etc/rc.conf}} sono supportate. Per una configurazione pura di systemd è raccomandato usare  [[Systemd#Native_systemd_configuration_files|native systemd configuration files]] che hanno la precedenza su {{ic|/etc/rc.conf}}.
 
 
 
Variabili supportate:
 
 
 
* LOCALE
 
* KEYMAP
 
* CONSOLEFONT
 
* CONSOLEMAP
 
* HOSTNAME
 
* DAEMONS
 
 
 
Variabili non supportate e configurazioni di systemd:
 
* TIMEZONE: fare un link simbolico {{Ic|/etc/localtime}} al proprio file con le informazioni di zona manualmente.
 
* HARDWARECLOCK: Vedere [[Systemd_(Italiano)#Orario_di_sistema|Orario di sistema]].
 
* USELVM: al suo posto usare {{ic|lvm.service}} fornito da {{Pkg|lvm2}}.
 
* USECOLOR
 
* MODULES
 
 
 
 
 
=== Conversione totale a systemd puro ===
 
 
 
{{Nota|Questo è il metodo preferenziale, in cui il sistema non si relazione con la configurazione centralizzata di {{ic|rc.conf}} in nessun modo, ma usa i file di configurazione nativi di systemd.}}
 
  
Segui la configurazione di sistema spiegata in [[#I_files_di_configurazione_nativi_di_systemd]]. Ogni file rimpiazza una sezione di {{ic|/etc/rc.conf}} come mostrato in questa tabella:
+
Un file di configurazione di unità racchiude informazioni riguardanti un servizio, un socket, un dispositivo, un punto di montaggio, un punto di automontaggio, un file o una partizione di swap, un obbiettivo di avvio, un percorso del filesystem oppure un controllo schedulato da systemd. La sintassi è ispirata da "XDG Desktop Entry Specification" files di tipo .desktop, che a loro volta richiamano i files .ini di windows.  
 
 
{| class="wikitable"
 
|-
 
! scope="col"| Configurazione
 
! scope="col"| Files di configurazione
 
! scope="col"| Vecchia sezione {{ic|/etc/rc.conf}}
 
|-
 
| align="center"|Hostname
 
| align="left"|{{ic|/etc/hostname}}
 
{{ic|/etc/hosts}}
 
| align="center"|{{ic|NETWORKING}}
 
|-
 
| align="center"|Console fonts and Keymap
 
| align="left"|{{ic|/etc/vconsole.conf}}
 
| align="center"|{{ic|LOCALIZATION}}
 
|-
 
| align="center"|Locale
 
| align="left"|{{ic|/etc/locale.conf}}
 
{{ic|/etc/locale.gen}}
 
| align="center"|{{ic|LOCALIZATION}}
 
|-
 
| align="center"|Time zone
 
| align="left"|{{ic|/etc/localtime}}
 
| align="center"|{{ic|LOCALIZATION}}
 
|-
 
| align="center"|Hardware clock
 
| align="left"|{{ic|/etc/adjtime}}
 
| align="center"|{{ic|LOCALIZATION}}
 
|-
 
| align="center"|Kernel modules
 
| align="left"|{{ic|/etc/modules-load.d/}}
 
| align="center"|{{ic|HARDWARE}}
 
|}
 
  
For questioni di compatibilità, la sezione '''DAEMONS'''  in {{ic|/etc/rc.conf}} è ancora compatibile con systemd e può essere usata per avviare servizi al boot, anche con una gestione "pura" dei servizi di systemd. In alternativa è possibile rimuovere interamente il file {{ic|/etc/rc.conf}} e attivare i servizi in systemd. Per ogni {{ic|<service_name>}} nella sezione '''DAEMONS''' di {{ic|/etc/rc.conf}}, digita:
+
Vedi {{man|5|systemd.unit}} per maggiori informazioni.
 
 
# systemctl enable <nome_del_servizio>.service
 
 
 
{{Suggerimento|Per una lista dei demoni più comuni con il loro initscripts e il loro equivalente in systemd, vedi [[Daemon#List_of_Daemons|questa tabella]].}}
 
 
 
Se {{ic|<nome_del_servizio>.service}} non esiste:
 
 
 
* il file .service può non essere disponibile per systemd. In questo caso, è necessario mantenere {{ic|rc.conf}} per avviare il servizio durante il boot.
 
* systemd può aver assegnato al servizio un nome diverso, ad esempio {{ic|cronie.service}} rimpiazza il lanciatore del demone {{ic|crond}} e {{ic|alsa-restore.service}} rimpiazza il lanciatore del demone {{ic|alsa}}. Un altro importante esempio è il demone  {{ic|network}}, che è qimpiazzato da un altra serie di servizi (vedi [[#Network]] per maggiori dettagli.)
 
 
 
{{Suggerimento|Si può guardare dentro i pacchetti che contengono gli script di avvio per il nome del servizio. Per esempio:
 
$ pacman -Ql cronie
 
[...]
 
cronie /etc/rc.d/crond                            #Daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)
 
[...]
 
cronie /usr/lib/systemd/system/cronie.service    #Corresponding systemd daemon service
 
[...]
 
}}
 
* systemd automaticamente gestirà l'ordine di avvio di questi demoni.
 
* alcuni servizi non necessitano di essere avviati esplicitamente all'avvio dall'utente. Per esempio, {{ic|dbus.service}} sarà attivato automaticamente dopo essere stato installato. Controllare la lista dei servizi e il loro stato d'uso con il comando {{ic|systemctl}}.
 
 
 
==Scrivere i files .service personalizzati==
 
  
 
===Gestire le dipendenze===
 
===Gestire le dipendenze===
  
 
Con systemd le dipendenze possono essere risolte progettando le unità correttamente.
 
Con systemd le dipendenze possono essere risolte progettando le unità correttamente.
Il caso più tipico è che l'unità {{ic|A}} richieda l'unità {{ic|B}} per poter funzionare prima che {{ic|A}} parta. In questo caso aggiungere {{ic|1=Requires=B}} e {{ic|1=After=B}} alla sezione {{ic|[Unit]}} di {{ic|A}}. Se la dipendenza è opzionale aggiungere, invece, Wants=B e After=B. Notare che {{ic|1=Wants=}} e {{ic|1=Requires=}} non includono {{ic|1=After=}}, il che significa che se {{ic|1=After=}} non è specificato, le due unità saranno avviate in parallelo. Le dipendenze sono di solito posizionate sui .service e non sui .target. Per esempio, {{ic|network.target}} è richiamato qualsiasi sia il servizio che configuri l'interfaccia di rete, quindi avviare successivamente la propria unità personalizzata è sufficiente in quanto {{ic|network.target}} è avviato comunque.
+
Il caso più tipico è che l'unità {{ic|A}} richieda l'unità {{ic|B}} per poter funzionare prima che {{ic|A}} parta. In questo caso aggiungere {{ic|1=Requires=B}} e {{ic|1=After=B}} alla sezione {{ic|[Unit]}} di {{ic|A}}. Se la dipendenza è opzionale aggiungere, invece, Wants=B e After=B. Notare che {{ic|1=Wants=}} e {{ic|1=Requires=}} non includono {{ic|1=After=}}, il che significa che se {{ic|1=After=}} non è specificato, le due unità saranno avviate in parallelo.  
 +
 
 +
Le dipendenze sono di solito posizionate sui .service e non sui .target. Per esempio, {{ic|network.target}} è richiamato qualsiasi sia il servizio che configuri l'interfaccia di rete, quindi avviare successivamente la propria unità personalizzata è sufficiente in quanto {{ic|network.target}} è avviato comunque.
  
 
===Type===
 
===Type===
  
Ci sono parecchi tipi differenti di avvio da considerare quando si scrive un servizio personalizzato. Ciò è configurato tramite il parametro {{ic|1=Type=}} nella sezione {{ic|[Service]}}. Vedere {{ic|man systemd.service}} per una spiegazione più dettagliata.
+
Ci sono parecchi tipi differenti di avvio da considerare quando si scrive un servizio personalizzato. Ciò è configurato tramite il parametro {{ic|1=Type=}} nella sezione {{ic|[Service]}}. Vedere {{man|5|systemd.service}} per una spiegazione più dettagliata.
  
* {{ic|1=Type=simple}}: systemd presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.
+
* {{ic|1=Type=simple}}(default): systemd presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.
 
* {{ic|1=Type=forking}}: systemd presuppone che il servizio deve essere avviato prima il processo sia suddiviso e il genitore sia concluso. Per i classici demoni usare questo tipo a meno che non si sappia che non è necessario, come la maggior parte dei demoni usa il double-forking per segnalare che sono pronti. Occorre pure specificare {{ic|1=PIDFile=}} perché systemd tenga traccia del processo principale.
 
* {{ic|1=Type=forking}}: systemd presuppone che il servizio deve essere avviato prima il processo sia suddiviso e il genitore sia concluso. Per i classici demoni usare questo tipo a meno che non si sappia che non è necessario, come la maggior parte dei demoni usa il double-forking per segnalare che sono pronti. Occorre pure specificare {{ic|1=PIDFile=}} perché systemd tenga traccia del processo principale.
* {{ic|1=Type=oneshot}}: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con  {{ic|1=RemainAfterExit=}} in modo che systemd consideri il servizio ancora attivo anche dopo che il processo si è concluso.
+
* {{ic|1=Type=oneshot}}: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con  {{ic|1=RemainAfterExit=yes}} in modo che systemd consideri il servizio ancora attivo anche dopo che il processo si è concluso.
 
* {{ic|1=Type=notify}}: Identico a {{ic|1=Type=simple}}, ma con l'accorgimento che il demone invierà un segnale a systemd quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da {{ic|libsystemd-daemon.so}}.
 
* {{ic|1=Type=notify}}: Identico a {{ic|1=Type=simple}}, ma con l'accorgimento che il demone invierà un segnale a systemd quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da {{ic|libsystemd-daemon.so}}.
 
* {{ic|1=Type=dbus}}: Il servizio è considerato pronto quando lo specificato {{ic|BusName}} appare nel sistema di bus si DBus.
 
* {{ic|1=Type=dbus}}: Il servizio è considerato pronto quando lo specificato {{ic|BusName}} appare nel sistema di bus si DBus.
Line 592: Line 496:
 
===Rimpiazzare le unità fornite===
 
===Rimpiazzare le unità fornite===
  
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.
+
Per editare il file unit fornito da un pacchetto, si può creare una cartella chiamata  {{ic|/etc/systemd/system/<unit>.d/}} per esempio {{ic|/etc/systemd/system/httpd.service.d/}} e mettere i files {{ic|*.conf}} in essa per sovrascrivere e aggiungere nuove opzioni. Systemd controllerà questi files {{ic|*.conf}} e li applicherà al di sopra degli originali. Per esempio, se si vuole semplicemente aggiungere un dipendenza all'unità si può creare il seguente file:
Per mantenere la propria versione di una unità (che non sarà distrutta dopo un aggiornamento), copiare la vecchia unità da {{ic|/usr/lib/}} a {{ic|/etc/}} e fare le proprie modifiche qui. In alternativa si può usare {{ic|.include}} per analizzare un servizio esistente e sovrascrivere o aggiungere nuove opzioni. Per esempio, se si vuole semplicemente aggiungere una dipendenza al servizio, si può usare:
+
 
{{hc|/etc/systemd/system/<service-name>.service|2=
+
{{hc|/etc/systemd/system/<unit>.d/customdependency.conf|2=
.include /usr/lib/systemd/system/<service-name>.service
 
  
 
[Unit]
 
[Unit]
Line 603: Line 506:
 
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:
 
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:
  
  # systemctl reenable <unit>
+
  # systemctl daemon-reload
 
  # systemctl restart <unit>
 
  # systemctl restart <unit>
  
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono stae modificate.}}
+
In alternativa si può copiare la vecchia unità da  {{ic|/usr/lib/systemd/system/}} in {{ic|/etc/systemd/system/}} e fare qui le modifiche. Una unità in {{ic|/etc/systemd/system/}} sovrascriverà sempre la stessa unità in {{ic|/usr/lib/systemd/system/}}. Da notare che quando l'unità originale in {{ic|/usr/lib/}} cambia a causa di un aggiornamento, le modifiche non si rifletteranno automaticamente sulla propria unità personalizzata in {{ic|/etc/}}. In aggiunta occorre riattivarla manualmente con {{ic|systemctl reenable <unit>}}. E' raccomandato usare il metodo con il {{ic|*.conf}} descritto sopra.
 +
 
 +
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}} Siccome le unità saranno aggiornate di volta in volta , usare systemd-delta per la manutenzione del sistema.
  
 
===Evidenziazione della sintassi per le unità di systemd con Vim===
 
===Evidenziazione della sintassi per le unità di systemd con Vim===
  
L'evidenziazione della sintassi per le unità di systemd con [[Vim]] può essere attivata installando {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].
+
L'evidenziazione della sintassi per le unità di systemd con [[Vim]] può essere attivata installando {{Pkg|vim-systemd}} dal [[Official repositories|repo ufficiale]].
  
== FAQ ==
+
== Targets ==
  
Per una lista aggiornata dei problemi conosciuti, vedere il [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].
+
Quello dei "runlevels" è un concetto superato in systemd. Systemd ha il concetto di ''target'' (lett. "bersagli") che adempiono uno scopo simile a quello dei runlevel, ma che hanno un comportamento leggermente differente. Ogni ''target'' ha un nome anziché un numero ed è usato per raggiungere uno specifico scopo con la possibilità di averne più di uno attivo nello stesso momento. Alcuni ''targets'' sono attivati ereditando tutto dei servizi di un altro ''target'' e implementandolo di servizi addizionali. Ci sono ''target'' che simulano i runlevel di SystemVinit, è così possibile passare da un ''target'' all'altro utilizzando il comando {{ic|telinit RUNLEVEL}}.
  
{{FAQ
+
=== Conoscere il target attuale ===
|question=Perché non ricevo messaggi di log sulla console?
 
|answer=Si deve configurare il proprio livello di log. Un tempo, {{ic|/etc/rc.sysinit}} lo faceva e configurava il livello di log di dmesg a {{ic|3}}, che era un ragionevole livello. Ora aggiungere {{ic|1=loglevel=3}} o {{ic|quiet}} ai [[kernel parameters|parametri del kernel]].}}
 
  
{{FAQ
+
Il seguente comando dovrebbe essere usato sotto systemd al posto di {{ic|runlevel}}:
|question=Come posso cambiare il numero di console funzionanti di default?
+
$ systemctl list-units --type=target
|answer=Per aggiungere un'altra console, semplicemente creare un altro collegamento per ottenere  un'altra console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :
 
  
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
+
=== Creare un target personalizzato ===
# systemctl daemon-reload
 
# systemctl start getty@tty9.service
 
  
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :
+
I runlevels sono assegnati ad uno specifico scopo su l'installazione vanilla di Fedora; 0, 1, 3, 5, e 6; hanno una mappatura 1:1 con uno specifico ''target'' di systemd. Sfortunatamente non c'è un altrettanto buon metodo per i runlevels definiti dall'utente come 2 e 4. Se si fa uso di questi, si suggerisce di dare un nuovo nome al ''target'' di systemd come {{ic|/etc/systemd/system/<your target>}} che prenda come base une dei runlevels esistenti (vedi {{ic|/usr/lib/systemd/system/graphical.target}} come esempio), creare una cartella {{ic|/etc/systemd/system/<your target>.wants}}, e fare un collegamento ai servizi addizionali da {{ic|/usr/lib/systemd/system/}} che si intendono attivare.
  
# rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
+
=== Targets table ===
# systemctl daemon-reload
 
# systemctl stop getty@tty5.service getty@tty6.service
 
  
systemd non usa il file /etc/inittab.
+
{| border="1"
 +
!SysV Runlevel!!systemd Target!!Notes
 +
|-
 +
| 0 || runlevel0.target, poweroff.target || Ferma il sistema.
 +
|-
 +
| 1, s, single || runlevel1.target, rescue.target || Modalità utente singolo (single user).
 +
|-
 +
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definita dall'utente. Preconfigurata a 3.
 +
|-
 +
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical.  Users can usually login via multiple consoles or via the network.
 +
|-
 +
| 5 || runlevel5.target, graphical.target || Multi-user, grafica.  Solitamente ha tutti i servizi del runlevel 3  con l'aggiunta di un login grafico.
 +
|-
 +
| 6 || runlevel6.target, reboot.target || Riavvio
 +
|-
 +
| emergency || emergency.target || Console di emergenza
 +
|-
 +
|}
  
{{Nota|Dalla versione 30 di systemd, solo una console sarà lanciata di default. Se si accede ad un'altra console una nuova istanza sarà lanciata (è lo stile socket-activation). Si può forzare l'avvio di console addizionali usando il metodo sopra.}}}}
+
=== Cambiare il target corrente ===
  
 +
In systemd i targets sono esplicitati per mezzo di "target units". Si possono cambiare così:
  
{{FAQ
+
# systemctl isolate graphical.target
|question=Come posso ottenere un output più dettagliato durante l'avvio?
 
|answer=Se non si ottiene nessun output dalla console dopo i messaggi di caricamento dell'initram, significa che il parametro {{ic|quiet}} è presente nella linea di comando del kernel. E' meglio rimuoverlo, almeno per i primi avvii con systemd, per vedere se tutto è ok. Poi, si potrà vedere una lista di {{ic|[ OK ]}} in verde o {{ic|[ FAILED ]}} in rosso.
 
  
Tutti i messaggi sono registrati nel log di sistema e se si vuole scoprire lo stato del proprio sistema usare {{ic|$ systemctl}} (non sono necessari privilegi di root) oppure guardare il log di avvio con  {{ic|journalctl}}.}}
+
Questo comando cambierà solamente il target corrente e non avrà nessun effetto sul prossimo avvio. Questo è equivalente ai comandi {{ic|telinit 3}} oppure {{ic|telinit 5}} in Sysvinit.
  
{{FAQ
+
=== Cambiare il target predefinito all'avvio ===
|question=Come evitare che la console sia pulita dopo l'avvio?
 
|answer=Creare un file g{{ic|getty@tty1.service}} personalizzato copiando {{ic|/usr/lib/systemd/system/getty@.service}} in {{ic|/etc/systemd/system/getty.target.wants/getty@tty1.service}} e cambiando {{ic|TTYVTDisallocate}} in {{ic|no}}.
 
}} e si permette l'esportazione di {{ic|LANG}} in {{ic|/etc/locale.conf}}
 
  
{{FAQ
+
Il target standard è {{ic|default.target}}, che è abbinato in modo predefinito a {{ic|graphical.target}} (che corrisponde al vecchio runlevel 5). Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:
|question=Quali opzioni del kernel occorrono attive nel mio kernel nel caso non usassi il kernel Arch ufficiale?
 
|answer=I Kernels precedenti al 2.6.39 non sono supportati.
 
  
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:
+
{{Suggerimento|L'estensione {{ic|.target}} può essere tralasciata.}}
  
CONFIG_AUDIT=y (raccomandata)
+
* {{ic|1=systemd.unit=multi-user.target}} (che corrisponde al vecchio runevel 3),
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non richiesta, può dare problemi a sysvinit compat)
+
* {{ic|1=systemd.unit=rescue.target}} (che corrisponde al vecchio runevel 1).
CONFIG_CGROUPS=y
 
CONFIG_IPV6=[y|m] (altamente raccomandata)
 
CONFIG_UEVENT_HELPER_PATH=""
 
CONFIG_DEVTMPFS=y
 
CONFIG_DEVTMPFS_MOUNT=y (richiesta, se non si usa l'initramfs)
 
CONFIG_RTC_DRV_CMOS=y (altamente raccomandata)
 
CONFIG_FANOTIFY=y (richiesta da readahead)
 
CONFIG_AUTOFS4_FS=[y|m]
 
CONFIG_TMPFS_POSIX_ACL=y (raccomandata, if you want to use pam_systemd.so)
 
CONFIG_NAMESPACES=y (per Private*=yes)
 
CONFIG_NET_NS=y (per PrivateNetwork=yes)
 
CONFIG_FHANDLE=y
 
}}
 
  
{{FAQ
+
In alternativa si può lasciare il bootloader inalterato e cambiare  {{ic|default.target}}. Ciò può essere fatto usando {{ic|systemctl}}:
|question=Quali altre unità dipendono da una unità?
 
|answer=Per esempio, se si vuole evidenziare quali servizi e target attiva {{ic|multi-user.target}}, si usi qualcosa del genere:
 
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}
 
  
Invece di {{ic|Wants}} si può provare {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} per i rispettivi tipi di dipendenza e il loro contrario.}}
+
# systemctl enable multi-user.target
  
{{FAQ
+
L'effetto di questo comando si nota nell'output di {{ic|systemctl}}; viene creato un link simbolico al nuovo target predefinito {{ic|/etc/systemd/system/default.target}}. Questo funziona solo se:
|question=Il mio computer si spegne, ma l'alimentatore resta acceso.
 
|answer=Usare
 
  
  $ systemctl poweroff
+
  [Install]
 +
Alias=default.target
  
invece di {{ic|systemctl halt}}.}}
+
si trova nel file di configurazione del target. Attualmente, sia {{ic|multi-user.target}} che {{ic|graphical.target}} lo possiedono.
  
{{FAQ
+
== Timers ==
|question=Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?
 
|answer=Assicurarsi di usare
 
  
# systemctl enable dmraid.service
+
Systemd can replace cron functionality to a great extent. See [[systemd/Timers]].
}}
 
  
{{FAQ
+
== Il Journal ==
|question=Come posso fare in modo che uno script sia eseguito al boot?
 
|answer=Creare un nuovo file in {{ic|/etc/systemd/system}} (e.g. "myscript".service) e aggiungere il seguente contenuto:
 
  
[Unit]
+
Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal. Tuttavia, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:
Description=My script
 
  
[Service]
+
# journalctl
ExecStart=/usr/bin/my-script
 
  
[Install]
+
Di default (quando {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. La directory {{ic|/var/log/journal/}} è parte di core/systemd. Se si è cancellata intenzionalmente o se qualche programma lo ha fatto systemd '''non''' lo riicreerà automaticamente, tuttavia sarà ricreata durante il prossimo aggiornamento di systemd. Fino a quel momento i log saranno scritti in {{ic|/run/systemd/journal}}. Ciò significa che i log saranno persi al riavvio.
WantedBy=multi-user.target
 
  
Poi
+
=== Filtrare l' output ===
  
# systemctl enable "myscript".service
+
{{ic|journalctl}} permette di filtrare l'output secondo specifici campi.
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato.
 
}}
 
  
{{FAQ
+
Esempi:
|question=Lo stato del .service dice "active (exited)" in verde. (per iptables)
 
|answer=Ciò è perfettamente normale.
 
Nel caso specifico di iptables è perché non c'è nessun demone da avviare, è controllato dal kernel. Tuttavia esiste dopo che le regole sono state caricate.
 
Per verificare se le regole di iptables sono state caricate correttamente:
 
{{bc|# iptables --list}}
 
}}
 
  
{{FAQ
+
Mostrare tutti i messaggi di questo boot:
|question={{ic|Failed to issue method call: File exists}} error
+
|answer=Questo accade quando si usa {{ic|systemctl enable}} e si tenta di creare il link simbolico in {{ic|/etc/systemd/system/}} ed esiste già. Di solito accade quando si passa da un display manager ad un altro (per esempio da GDM a KDM, che possono essere abilitati con {{ic|gdm.service}} e {{ic|kdm.service}}, rispettivamente) e il link simbolico corrispondente {{ic|/etc/systemd/system/display-manager.service}} esiste già.
+
  # journalctl -b
Per risolvere il problema usare {{ic|systemctl -f enable}} per sovrascrivere link simbolici già esistenti.
 
}}
 
  
== Ottimizzazioni ==
+
Tuttavia, spesso un utente può essere interessato ai messaggi non del corrente boot, ma del precedente (per esempio a causa di un non recuperabile blocco occorso). Attualmente, questa opzione non è implementata, ma esiste una discussione a  [http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] (Settembre/Ottobre 2012).
 +
 +
Come workaround al momento si può usare:
  
=== systemd-analyze ===
+
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
 +
 +
,che provoca che il precedente boot sia come scaturito oggi. Tenere presente che, se ci sono molti messaggi per il giorno corrente, l'output di questo comando può essere ritardato per un bel po 'di tempo.
 +
 +
Seguire i nuovi messaggi:
 +
 +
# journalctl -f
  
Systemd fornisce una utilità chiamata {{ic|systemd-analyze}} che permette di analizzare il proprio processo d'avvio al fine di evidenziare quali unità stanno causando rallentamenti nel processo di avvio stesso. E' possibile quindi ottimizzare il sistema tenendo conto di ciò. Occorre installare {{Pkg|python2-dbus}} e {{Pkg|python2-cairo}} per usarlo.
+
Mostrare tutti i messaggi di un eseguibile specifico:
  
Per vedere quanto tempo ha impiegato il boot del kernel e dello userspace, semplicemente si usi:
+
# journalctl /usr/lib/systemd/systemd
  
$ systemd-analyze
+
Mostrare tutti i messaggi di uno specifico processo:
  
{{Suggerimento|Se si aggiunge l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/mkinitcpio.conf}} e si ricostruisce l'initramfs, {{ic|systemd-analyze}} mostrerà anche quanto tempo ha impiegato l'initramfs.}}
+
  # journalctl _PID=1
  
Per elencare le unità partite, ordinate a seconda del tempo che impiegano ad avviarsi:
+
Mostrare tutti i messaggi di una specifica unità:
  
  $ systemd-analyze blame
+
  # journalctl -u netcfg
  
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:
 
  
$ systemd-analyze plot > plot.svg
+
Vedere {{man|1|journalctl}} e {{ic|systemd.journal-fields}} oppure il [http://0pointer.de/blog/projects/journalctl.html blog] di Lennert per dettagli.
  
====Attivare bootchart assieme a systemd====
+
=== Limiti alla dimensione del journal ===
  
E' possibile usare una versione di bootchart per visualizzare la sequenza di boot.
+
Se il journal è persistente (non volatile) la sua dimensione è fissata al 10% della dimensione del rispettivo file system. Per esempio con {{ic|/var/log/journal}} allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal. La dimensione massima del journal persistente può essere controllata attraverso {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:
Da quando non è più possibile inserire un secondo "init" nel comando del kernel non c'è più la possibilità di usare alcuna configurazione standard di bootchart. Tuttavia il pacchetto {{AUR|bootchart2}} di [[AUR]] nasce con un non documentato service di systemd. Dopo aver installato bootchart2 fare:
 
  
# systemctl enable bootchart.service
+
SystemMaxUse=50M
  
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.
+
Fare riferimento a {{man|5|journald.conf}} per maggiori dettagli.
  
=== Tasti di scelta rapida della Shell ===
+
=== Journald coesistente con syslog ===
  
La gestione dei demoni tramite systemd richiede un po' più digitazione per realizzare i comandi come l'avvio, lo stop, l'attiavzione, il controllo dello stato, ecc. Le seguenti funzioni possono essere aggiunte a quelle nel file {{ic|~/.bashrc}} per semplificare le interazioni con systemd e per migliorare l'esperienza complessiva.
+
La compatibilità con il classico syslog è fornita dal socket {{ic|/run/systemd/journal/syslog}}, attraverso il quale passano tutti i messaggi.
 
+
Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). Il pacchetto {{pkg|syslog-ng}} dei repo ufficiali automaticamente fornisce la necessaria configurazione.
{{bc|<nowiki>if ! systemd-notify --booted; then # not using systemd
 
alias start='sudo rc.d start'
 
  alias restart='sudo rc.d restart'
 
  alias stop='sudo rc.d stop'
 
else
 
  alias start='sudo systemctl start'
 
  alias restart='sudo systemctl restart'
 
  alias stop='sudo systemctl stop'
 
  alias enable='sudo systemctl enable'
 
  alias status='sudo systemctl status'
 
  alias disable='sudo systemctl disable'
 
fi
 
</nowiki>}}
 
 
 
=== Diminuire l'output ===
 
 
 
Cambiare {{ic|verbose}} in {{ic|quiet}} nella riga del kernel del bootloader. Per certi sistemi, particolarmente quelli che utilizzano un SSD, il rallentamento delle prestazioni di TTY e attualmente un collo di bottiglia, quindi la diminuzione dell'output significa velocizzare l'avvio.
 
 
 
=== Avvio anticipato ===
 
 
 
Una caratteristica centrale di systemd è l'attivazione di  [[D-Bus]] e dei socket, il ché provoca l'avvio dei servizi al primo accesso, e generalmente è una cosa positiva. Tuttavia, se si è a conoscenza che un servizio (come [[ConsoleKit]]) sarà sempre avviato durante il boot, il tempo di avvio potrà essere ridotto avviandolo il prima possibile. Ciò può essere ottenuto (se il servizioè impostato per ciò, e nella maggior parte dei casi lo è) mediante l'immissione di:
 
 
 
# systemctl enable console-kit-daemon.service
 
 
 
Questo provocherà l'avvio di ConsoleKit al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.
 
 
 
=== Automount ===
 
 
 
Le impostazioni standard controllano con fsck e montano tutti i filesystems prima di avviare la maggior parte dei demoni e dei servizi. Se si possiede una grande partizione di {{ic|/home}}, sarebbe meglio permettere ai servizi che non dipendono dalla{{ic|/home}} di avviarsi mentre la {{ic|/home}} sarà controllata. Ciò può essere ottenuto aggiungendo le seguenti opzioni  alla voce della propria partizione {{ic|/home}} in fstab:
 
  
  noauto,x-systemd.automount
+
  # systemctl enable syslog-ng
 
+
Una buona guida a {{ic|journalctl}} è [http://0pointer.de/blog/projects/journalctl.html| qui].
Questo controllerà e monterà la {{ic|/home}} quando ci sarà l'accesso per la prima volta,  e il kernel memorizzerà tutti gli accessi ai file della {{ic|/home}} finché non sarà pronta.
 
 
 
Se si utilizzano filesystems criptati con keyfiles, è possibile aggiungere il paramtero {{ic|noauto}} alla corrispondente voce in {{ic|/etc/crypttab}}. Systemd non aprirà il dispositivo criptato al boot, maal contrario aspetterà finché non ci sarà un accesso e sarà automaticamente aperto con lo specifico keyfile prima di montarlo. Ciò può far risparmiare un po' di secondi al boot se si sta usando un dispositivo RAID criptato per esempio, perché systemd non dovrà aspettare che il dispositivo diventi disponibile. Per esempio:
 
{{hc|/etc/crypttab|data /dev/md0 /root/key noauto}}
 
 
 
=== Readahead ===
 
 
 
systemd nasce con la propria implementazione di readahead , questo dovrebbe principalmente migliorare il tempo d'avvio. Tuttavia, in relazione alla versione del kernel e al tipo di disco rigido, i tempi possono variare (per esempio potrebbe essere più lento). Per attivarlo, fare:
 
 
 
# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service
 
 
 
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.
 
 
 
=== Rimpiazzare ConsoleKit con systemd-logind ===
 
 
 
A partire da {{Pkg|polkit}} 0.107 (attualmente in [testing]), [[ConsoleKit]] può essere completamente rimpiazzato da {{ic|systemd-logind}}. Tuttavia, non c'è attualmente nessun Display Manager nei repositories di Arch Linux che  supporti nativamente {{ic|systemd-logind}} senza dipendere ancora da [[ConsoleKit]]. Il più semplice metodo per rimuovere [[ConsoleKit]] è quello di [[Automatic_login_to_virtual_console_(Italiano)#Systemd|loggarsi automaticamente a una console virtuale]] e [[Start_X_at_Boot_(Italiano)|avviare X da qui]]. E' importante, come menzionato nel precedente articolo, che il server X sia avviato nella stessa console virtuale in cui si è fatto il login, altrimenti systemd non può tenere traccia della sessione utente. Dopodiché si può semplicemente rimuovere {{ic|ck-launch-session}} dal proprio {{ic|~/.xinitrc}}.
 
 
 
Per controllare lo stato della propria sessione utente, si può utilizzare {{ic|loginctl}}. Per vedere se la propria sessione utente è configurata appropriatamente, controllare se il seguente comando contiene {{ic|1=Active=yes}}. Tutte le azioni di {{Pkg|polkit}} come la sospensione del sistema o il montaggio di dispositivi esterni tramite [[Udisks]] dovrebbero poi funzionare automaticamente.
 
 
 
$ loginctl show-session <session-id>
 
 
 
{{Nota|Se si usa [[NetworkManager]], occorre ricompilarlo con il supporto a systemd da [[ABS]] configurando {{ic|1=--with-session-tracking=systemd}} nel [[PKGBUILD]].}}
 
  
 
== Correzione di errori ==
 
== Correzione di errori ==
Line 822: Line 651:
 
Per vedere se si soffre di questo problema vedere [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually questo articolo].
 
Per vedere se si soffre di questo problema vedere [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually questo articolo].
  
==== SLiM in una sessione di xfce ====
+
=== I processi di breve durata non registrano nessun output ===
  
Una configurazione che può comportare blocchi allo spegnimento è l'utilizzo contemporaneo di Xfce con SLiM: Spegnere e riavviare in una sessione di xfce può causare il blocco per mezzo minuto di slim.service fino a quando systemd ne forzerà la chiusura.
+
Se {{ic|journalctl -u foounit.service}} non mostra nessun output per un processo di breve durata, controllare il PID. Per esempio, se systemd-modules-load.service fallisce, e {{ic|systemctl status systemd-modules-load}} evidenzia che è eseguito con PID 123, è possibile vedere l'output del journal per quel PID, per esempio {{ic|journalctl -b _PID&#61;123}}. I campi con metadata del journal come _SYSTEMD_UNIT e _COMM sono raccolti in modo asincrono e fanno affidamento sulla cartella {{ic|/proc}} per il processo esistente. La sistemazione di questo richiede una sistemazione del kernel per fornire questi dati per mezzo di una connessione socket, come per SCM_CREDENTIALS.
Un modo per aggirare il problema è la modifica di {{ic|slim.service}}:
 
  
{{hc|/etc/systemd/system/slim.service|2=
+
=== Diagnosi dei problemi al Boot ===
[Unit]
+
Description=SLiM Simple Login Manager
+
Avviare il sistema con questi parametri sulla linea di comando del kernel:
After=systemd-user-sessions.service
+
 
+
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}
[Service]
+
Type=forking
+
[http://freedesktop.org/wiki/Software/systemd/Debugging Maggiori informazioni sul  Debugging]
PIDFile=/var/lock/slim.lock
 
ExecStart=/usr/bin/slim -d
 
ExecStop=/bin/kill -9 $MAINPID
 
ExecStopPost=/bin/rm /var/lock/slim.lock
 
 
 
[Install]
 
WantedBy=graphical.target}}
 
Questo causerà la chiusura di SLiM usando SIGKILL. Non causa nessun problema poichè anche il file di blocco viene rimosso.
 
 
 
=== Se dei servizi falliscono l'avvio ===
 
 
 
Se {{ic|/var/tmp}} è un link simbolico a {{ic|/tmp}}, porta alcuni servizi a fallire la partenza quando sono avviati tramite systemd. In questo caso, lo stato del processo (tramite {{ic|systemctl status <service>}}) sarà "226/NAMESPACE". Per superare questo blocco, semplicemente rimuovere il proprio link simbolico a {{ic|/var/tmp}} e reinstallare il pacchetto {{pkg|filesystem}}.
 
  
 
== Vedi anche==
 
== Vedi anche==
Line 851: Line 667:
  
 
*[http://www.freedesktop.org/wiki/Software/systemd Sito ufficiale]
 
*[http://www.freedesktop.org/wiki/Software/systemd Sito ufficiale]
*[http://0pointer.de/public/systemd-man/ Pafine di manuale]
+
*[http://0pointer.de/public/systemd-man/ Pagine di manuale]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Trucchi e suggerimenti]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Trucchi e suggerimenti]
 
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd per amministratori (PDF)]
 
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd per amministratori (PDF)]
 
*[http://fedoraproject.org/wiki/Systemd Systemd su Fedora Project]
 
*[http://fedoraproject.org/wiki/Systemd Systemd su Fedora Project]
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Come correggere i problemi di Systemd]
+
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Come correggere i problemi di systemd]
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]
+
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] articolo introduttivo nella rivista ''The H Open''.
 
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
 
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
 
*[http://0pointer.de/blog/projects/systemd-update.html status update]
 
*[http://0pointer.de/blog/projects/systemd-update.html status update]
Line 863: Line 679:
 
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
 
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
 
*[http://0pointer.de/blog/projects/why.html most recent summary]
 
*[http://0pointer.de/blog/projects/why.html most recent summary]
 +
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]

Latest revision as of 17:05, 24 November 2017

Dalla pagina web del progetto:

systemd è un gestore di sistema e di servizi per Linux. Fornisce un manager di sistema e servizi che e` avviato con PID 1 e avvia il resto del sistema. systemd fornisce una notevole capacità di parallelizzazione, usa socket e D-Bus per l'avvio dei demoni, offre un avvio su richiesta dei demoni, tiene traccia dei processi con l'utilizzo del control groups di Linux, supporta lo snapshotting e il restore dello stato del sistema, mantiene i punti di mount e di automount e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze. systemd supporta SysV e LSB, inoltre sostituisce sysvinit. Include un demone per il logging, utility per controllare aspetti base del sistema come hostname, data, locale, lista degli utenti loggati; puo` avviare containers e macchine virtuali. Fornisce demoni per gestire la rete, sincronizzazione dell'orario, forwarding di log e name resolution.
Nota: Per una dettagliata spiegazione del motivo per cui Arch è passato a systemd, leggi questo post.

Uso base di systemctl

Il principale comando usato per controllare systemd è systemctl. Alcuni degli utilizzi possibili sono l'esame dello stato del sistema e la gestione del sistema e dei servizi. Vedere systemctl(1) per maggiori dettagli

Suggerimento: Si può usare il seguente comando systemctl con lo switch -H <user>@<host> per controllare un'istanza di systemd su una macchina remota. Si userà SSH per connettersi all'istanza remota di systemd.
Nota: systemadm è il frontend grafico ufficiale per systemctl. E' fornito dal pacchetto systemd-ui-gitAUR[broken link: archived in aur-mirror] di AUR.

Analizzare lo stato del sistema

Mostra lo stato del sistema:

$ systemctl status 

Lista della unità attive:

$ systemctl

oppure:

$ systemctl list-units

Lista delle unità che hanno avuto problemi:

$ systemctl --failed

I file delle unità disponibili possono essere visti in /usr/lib/systemd/system/ e /etc/systemd/system/ (questi ultimi hanno la precedenza sui primi). Si possono vedere le unità installate con:

$ systemctl list-unit-files

Usare le unità

Le unità possono essere, per esempio, servizi (.service), punti di mount (.mount), dispositivi (.device) oppure sockets (.socket).

Quando si usa systemctl, occorre generalmente specificare sempre il nome completo dell'unità compreso il suffisso, per esempio sshd.socket. Esistono tuttavia delle scorciatoie quando si specifica l'unità nei seguenti comandi systemctl:

  • Se non si specifica il suffisso, per systemctl sarà sottointeso .service. Per esempio, netctl e netctl.service sono equivalenti.
  • I punti di mount saranno automaticamente tradotti nella appropriata unità .mount. Per esempio, specificare /home è equivalente a home.mount.
  • Come i punti di mount, anche i dispositivi sono automaticamente tradotti nell'appropriata unità .device, quindi specificare /dev/sda2 è equivalente a dev-sda2.device.

Vedi systemd.unit(5) per dettagli.

Nota: Alcune unit contengono una @ (e.g. name@string.service: questo significa che sono istanze di un template, il cui filename non contiene la parte string (e.g. name@.service). string e` chiamato identificatore dell'istanza ed e` simile all'argomento passato al template quando viene richiamato con il comando systemctl: nelle unit verra` sostituico con %i. Per essere piu` accurati, prima di tentare di istanziare name@.estensione, systemd cerchera` una unit con il nome esatto.

Attivare immediatamente una unità:

# systemctl start unit

Fermare immediatamente una unità:

# systemctl stop unit

Riavviare una unità:

# systemctl restart unit

Ricaricare la configurazione di una unit:

# systemctl reload unit

Mostrare lo stato di una unità, compreso se sta funzionando o no:

$ systemctl status unit

Controllare se una unità è già attivata o no:

$ systemctl is-enabled unit

Attivare l'avvio automatico al boot:

# systemctl enable unit

Attivare l'avvio automatico al boot e avviare immediatamente una unit:

# systemctl enable --now unit

Disattivare l'avvio automatico al boot:

# systemctl disable unit

Unmask di una unit:

# systemctl unmask unit

Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):

$ systemctl help unit

Ricaricare systemd, controllo per nuove o modificate unità:

# systemctl daemon-reload

Power management

polkit è indispensabile per la gestione energetica. Se ci si trova in una sessione locale di systemd-logind e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), systemd automaticamente richiederà la password di root.

Spegnimento e riavvio del sistema:

$ systemctl reboot

Spegnimento del sistema:

$ systemctl poweroff

Sospensione del sistema:

$ systemctl suspend

Ibernazione del sistema:

$ systemctl hibernate

Stato ibrido di riposo (o suspend-to-both):

$ systemctl hybrid-sleep

Avviare DM con systemd

Per avviare il login grafico, abilitare il demone del suo Display Manager corrispondente (per esempio KDM). Attualmente esistono i .service per GDM, KDM, SLiM, XDM and LXDM e LightDM.

# systemctl enable kdm

Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio graphical.target).

# rm /etc/systemd/system/default.target

Usare systemd-logind

Per controllare lo stato della propria sessione utente, si può utilizzare loginctl. Tutte le azioni di PolicyKit come la sospensione del sistema o il montaggio di dispositivi esterni funzioneranno automaticamente.

$ loginctl show-session $XDG_SESSION_ID

Configurazione nativa

Nota: E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root

Hostname

L'hostname è configurato in /etc/hostname. Il file può contenere il nome del dominio di sistema, se esiste, tuttavia nel momento di scrivere hostnamectl non si può configurare il FQDN. Per configurare l'hostname corto:

# hostnamectl set-hostname myhostname

See hostname(5) e hostnamectl(1) per dettagli.

Esempio di file:

/etc/hostname
myhostname

Impostazioni locali

Note: Before you set the default locale, you first need to enable locales available to the system by uncommenting them in /etc/locale.gen and then executing locale-gen as root. The locale set via localectl must be one of the uncommented locales in /etc/locale.gen.

Le impostazioni locali di default sono configurate in /etc/locale.conf Per configurare il locale di default:

# localectl set-locale LANG="it_IT.utf8"
	

Vedere localectl(1) e locale.conf(5) per dettagli.

Per ulteriori informazioni vedere Locale.

Esempio di file:

/etc/locale.conf
LANG=it_IT.utf8

Console virtuale

La console virtuale (la mappatura della tastiera, i caratteri della console e la mappatura della console) è configurata in /etc/vconsole.conf:

/etc/vconsole.conf
KEYMAP=it
FONT=
FONT_MAP=
Nota: Da systemd-194, si utilizzano i caratteri integrati nel kernel e la mappatura della tastiera "us" se KEYMAP= e FONT= sono vuoti o non configurati.

Un altro modo di configurare la mappatura della tastiera è:

# localectl set-keymap it

localectl può essere usato anche per configurare la tastiera in ambiente X:

# localectl set-x11-keymap it

Vedere localectl(1) e vconsole.conf(5) per maggiori dettagli.

Per maggiori informazioni vedere i font per console e configurazione tastiera.

Orario di sistema

Systemd usa UTC di default per l'orologio hardware.

Suggerimento: E' generalmente consigliato avere il demone Network Time Protocol attivo per mantenere l'orologio di sistema sincronizzato con Internet e con l'orologio del bios.

Orologio hardware in localtime

Se si vuole cambiare l'orologio hardware ad usare l'orario locale (ALTAMENTE SCONSIGLIATO):

# timedatectl set-local-rtc true

Se si vuole riconvertirlo a UTC:

# timedatectl set-local-rtc false

Attenzione che, se l'orologio hardware è configurato a localtime, la gestione dell'orario legale è persa. Se l'orario legale cambia finché il computer è spento il proprio orario sarà sbagliato al prossimo riavvio (ulteriori approfondimenti). I kernel recenti configurano l'orario di sistema dall'orologio hardware direttamente al boot, presupponendo che l'orologio hardware sia impostato a UTC. Questo significa che se l'orologio hardware è su locale l'orologio di sistema sarà prima configurato sbagliato e poi corretto ad ogni boot. Questa è la causa di alcuni noiosi bugs (il tempo che torna indietro è raramente una buona cosa).

Una ragione per permettere che l'orologio hardware sia settato sul'orario locale è quella del dual boot con Windows (il quale usa localtime). Tuttavia, Windows è in grado di gestire l'orario con l'orologio hardware settato su UTC con un semplice aggiustamento del registro di sistema. Quindi, è consigliato configurare Windows affinché usi UTC, piuttosto che Linux usi localtime. Se si usa UTC su Windows, ricordarsi inoltre di disabilitare l'opzione di Windows "Internet Time Update", al fine di evitare confusione tra windows e l'orologio hardware, nel tentativo di sincronizzazione con l'orario internet. Al contrario, occorre lasciare che Linux sincronizzi l'orario di sistema con l'orario internet attivando il demone NTP, come suggerito precedentemente.

  • Per maggiori informazioni vedere Time.

Moduli del Kernel

Ad oggi, tutti i moduli necessari da caricare sono gestiti automaticamente da udev, cosicché, se non si vuole usare qualcuno dei moduli fuori dal kernel, non c'è bisogno di mettere i moduli che dovrebbero essere caricati al boot in nessun file di configurazione. Tuttavia, ci sono casi in cui si vuole caricare un modulo extra durante il processo di avvio oppure evitare il caricamento di un altro perché il computer funzioni correttamente.

Moduli extra da caricare all'avvio

I moduli extra al kernel da caricare durante il boot sono configurati in una lista statica in /etc/modules-load.d/. Ogni file di configurazione ha il nome nello stile di /etc/modules-load.d/<programma>.conf/. I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO. Le linee vuote o quelle dove il primo carattere che non è uno spazio è # oppure ; sono ignorate. Ad esempio:

/etc/modules-load.d/virtio-net.conf
# Carica virtio-net.ko al boot
virtio-net

vedere modules-load.d(5) per maggiori dettagli.

Configurare le opzioni dei moduli

Ulteriori opzioni per i moduli devono essere impostati in /etc/modprobe.d/modprobe.conf.

Esempio:

  • Abbiamo il file /etc/modules-load.d/loop.conf con all'interno il modulo loop da far caricare durante la fase di boot.
  • in /etc/modprobe.d/modprobe.conf specifichiamo le opzioni addizionali, es. options loop max_loop=64

In seguito, l'opzione appena impostato potrebbe essere verificata tramite cat /sys/module/loop/parameters/max_loop

Blacklisting

Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli initscripts[broken link: package not found] in quanto è attualmente gestito da kmod. Vedere Blacklist dei moduli per maggiori dettagli.

Montaggio del filesystem

La configurazione di default controlla e monta i filesystems prima di avviare i servizi ai quali occorre che siano montati. Per esempio, systemd automaticamente si assicura che il montaggio di filesystems come NFS o Samba avvenga solo dopo che la rete è attiva. Pertanto, il montaggio dei filesystems, sia locali che remoti, specificati in /etc/fstab dovrebbe funzionare senza problemi.

Vedere systemd.mount(5) per dettagli.

Automount

  • Se si possiede una grande partizione /home, sarebbe meglio permettere ai servizi che non dipendono da essa di avviarsi durante il controllo di /home da parte di fsck. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di /home in /etc/fstab:
noauto,x-systemd.automount

Questo controllerà e monterà /home al primo accesso, e il kernel memorizzerà in un buffer tutti gli accessi ai file in /home finché non sarà pronta.

Nota: questo renderà il filesystem /home di tipo autofs, che è ignorato da mlocate di default. La velocità di montaggio automatico di /home non può essere maggiore di un secondo o due, a seconda del proprio sistema, quindi è possibile che non valga la pena di utilizzare questo trucco.

  • Lo stesso si può applicare al montaggio dei filesystems remoti. Se si desidera montarli successivamente all'accesso occorrerà usare i parametri noauto,x-systemd.automount. In aggiunta, si può usare l'opzione x-systemd.device-timeout=# per specificare un tempo di timeout in caso la risorsa di rete non sia disponibile.
  • Se si hanno filesystems criptati con keyfiles, si può comunque aggiungere il parametro noauto alla corrispondente riga in /etc/crypttab. Systemd non aprirà il supporto corispondente all'avvio, ma aspetterà finché non avverrà un accesso e quindi automaticamente aprirà il keyfile specifico prima di montarlo. Questo potrebbe far risparmiare un po' di secondi al boot se si sta per esempio utilizzando un supporto RAID criptato, in quanto systemd non deve aspettare finché il dispositivo non sarà disponibile. Per esempio:
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

Se si possiede un volume LVM non attivato durante l'initramfs, attivare il servizio lvm-monitoring fornito dal pacchetto lvm2:

# systemctl enable lvm-monitoring.service

ACPI power management

Systemd gestisce degli eventi ACPI relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di /etc/systemd/logind.conf:

  • HandlePowerKey : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
  • HandleSuspendKey : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
  • HandleHibernateKey : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
  • HandleLidSwitch : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.

Le azioni specificate possono essere una qualsiasi di ignore, poweroff, reboot, halt, suspend, hibernate, hybrid-sleep o kexec.

Se queste opzioni non sono configurate, systemd userà quelle di default: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, and HandleLidSwitch=suspend.

Su sistemi che non hanno una configurazione grafica o semplici gestori di finestre come i3 o awesome, può rimpiazzare il demone acpid che è solitamente usato per gestire questi eventi ACPI.

Nota: Digitare systemctl restart systemd-logind.service perchè le modifiche abbiano effetto.
Nota: Systemd non riesce a gestire gli eventi di alimentazione di rete e di batteria, sicché è ancora richiesto l'uso di Laptop Mode Tools o altri strumenti acpid similari.

Nell'attuale versione di systemd, le opzioni Handle* saranno applicate al sistema finché non saranno "inibite" (temporaneamente spente) da un programma, come un gestore di alimentazione in un DE. Se questi inibitori non sono usati, si può finire in una situazione in cui systemd sospende il sistema , poi al risveglio gli altri gestori di alimentazione lo sospendono di nuovo.

Attenzione: Attualmente, i gestori di alimentazione delle versioni più recenti di KDE e GNOME sono gli unici che possiedono i necessari comandi inibitori. Quando li avranno anche gli altri, occorrerà settare l'opzione Handle a ignore se si voglio gestire gli eventi ACPI con Xfce, acpid o qualsiasi altro programma.
Nota: Systemd può anche usare altri backends per la sospensione (come Uswsusp o TuxOnIce), in aggiunta al backend di default del kernel, al fine di mettere il computer in uno stato di sleep o ibernazione.

For systemctl hibernate to work on your system you need to follow instructions at Hibernation and possibly at Mkinitcpio Resume Hook[broken link: invalid section] (pm-utils does not need to be installed).

Sleep hooks

Systemd non usa pm-utils per mettere la macchina a riposo quando usa systemctl suspend, systemctl hibernate oppure systemctl hybrid-sleep, quindi gli hooks di Pm-utils incluso qualsiasi hook personalizzato si sia creato non funzioneranno. Tuttavia, systemd fornisce due meccanismi simili per avviare script personali in base a questi eventi.

Suspend/resume service files

Dei service files possono essere agganciati a suspend.target, hibernate.target e sleep.target per eseguire azioni prima o dopo la sospensione lo l'ibernazione. Files separati dovrebbero essere creati per azioni degli utenti e azioni di sistema (root). Per attivare i servizi degli utenti, # systemctl enable suspend@<user> && systemctl enable resume@<user>. Esempi:

/etc/systemd/system/suspend@.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target
/etc/systemd/system/resume@.service
[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStartPre=/usr/local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

Per azioni di sistema o root (attivare con # systemctl enable root-suspend):

/etc/systemd/system/root-resume.service
[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target
/etc/systemd/system/root-suspend.service
[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target

Un paio di consigli a proposito di questi servizi (maggiori informazioni in systemd.service(5)):

  • Se si usa Type=OneShot si possono usare linee ExecStart= multiple. Altrimenti solo una linea ExecStart è permessa. Si possono aggiungere più comandi con ExecStartPre oppure separandoli con un punto e virgola (vedere il primo esempio più su -- notare gli spazi prima e dopo il punto e virgola... sono indispensabili!).
  • Un comando preceduto da '-' causerà una uscita con stato non-zero per essere ignorato e trattato come un comando successivo.
  • Il miglior modo per trovare gli errori in questi servizi è naturalmente con journalctl.
Servizi combinati di Suspend/resume

Con il servizio combinato suspend/resume, un singolo collegamento fa tutto il lavoro per le varie fasi (sleep/resume) e per i differenti targets (suspend/hibernate/hybrid-sleep).

Esempi e spiegazioni:

/etc/systemd/system/wicd-sleep.service
[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target
  • RemainAfterExit=yes: Dopo averlo avviato, il servizio è considerato attivo fino a quando non è esplicitamente fermato.
  • StopWhenUnneeded=yes: Quando è attivo, il servizio sarà fermato se nessun altro servizio necessita di esso. Nell'esempio specifico, sarà fermato dopo che sleep.target sarà fermato.
  • Perché sleep.target venga richiamato da suspend.target, hibernate.target e hybrid-sleep.target e sleep.target esso stesso è un StopWhenUnneeded service, il collegamento garantisce l'avvio e la fermata corretta per diversi compiti.
Hooks in /usr/lib/systemd/system-sleep

Systemd avvia tutti gli eseguibili in /usr/lib/systemd/system-sleep/ e passa due argomenti a ognuno di essi:

  • Argument 1: pre o post, a seconda che la macchina si stia addormentando o svegliando
  • Argument 2: suspend, hibernate oppure hybrid-sleep, dipende da quello che è stato invocato.

Al contrario di Pm-utils, systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.

L'output di ogni script personalizzato sarà registrato da systemd-suspend.service, systemd-hibernate.service oppure systemd-hybrid-sleep.service cosicché sarà possibile vedere i propri outputs nel journal:

# journalctl -b -u systemd-suspend

Nota che è possibile usare anche sleep.target, suspend.target, hibernate.target oppure hybrid-sleep.target per agganciare le unità allo stato di sospensione invece di usare degli scripts personalizzati.

Un esempio di script personalizzato:

/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."

    ;;
  post/* )
    echo "Waking up from $2..."
    ;;
esac

Non dimenticare di rendere lo script eseguibile:

	+	
# chmod a+x /usr/lib/systemd/system-sleep/example.sh

Vedere systemd.special(7) e systemd-sleep(8) per maggiori dettagli.

File temporanei

Systemd-tmpfiles mantiene la configurazione dei file in /usr/lib/tmpfiles.d/ e in /etc/tmpfiles.d/ per descrivere la creazione, la pulizia e la rimozione dei files e delle cartelle temporanee e volatili che normalmente risiedono in cartelle come /run o /tmp. Ogni file di configurazione prende il nome nello stile di /etc/tmpfiles.d/<program>.conf. Ciò sovrascriverà ogni file in /usr/lib/tmpfiles.d/ con lo stesso nome.

I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esmpio il demone Samba si aspetta che esista la cartella /run/samba per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:

/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root

I tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa /etc/rc.local per disabilitare il risveglio del sistema attraverso dispositivi USB con echo USBE > /proc/acpi/wakeup, si può usare in alternativa il seguente tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

Vedi tmpfiles.d(5) per i dettagli.

Nota: Questo metodo potrebbe non funzionare per impostare le opzioni in /sys poiché il servizio systemd-tmpfiles-setup può eseguirsi prima che i moduli delle periferiche appropriate siano caricati. In questo caso si potrebbe verificare che il modulo abbia un parametro per l'opzione che si desidera impostare con modinfo <module> e impostare questa opzione con un file di configurazione in /etc/modprobe.d[broken link: invalid section]. In caso contrario si dovrà scrivere una regola udev per impostare l' attributo appropriato non appena viene visualizzato il dispositivo.

Unità

Un file di configurazione di unità racchiude informazioni riguardanti un servizio, un socket, un dispositivo, un punto di montaggio, un punto di automontaggio, un file o una partizione di swap, un obbiettivo di avvio, un percorso del filesystem oppure un controllo schedulato da systemd. La sintassi è ispirata da "XDG Desktop Entry Specification" files di tipo .desktop, che a loro volta richiamano i files .ini di windows.

Vedi systemd.unit(5) per maggiori informazioni.

Gestire le dipendenze

Con systemd le dipendenze possono essere risolte progettando le unità correttamente. Il caso più tipico è che l'unità A richieda l'unità B per poter funzionare prima che A parta. In questo caso aggiungere Requires=B e After=B alla sezione [Unit] di A. Se la dipendenza è opzionale aggiungere, invece, Wants=B e After=B. Notare che Wants= e Requires= non includono After=, il che significa che se After= non è specificato, le due unità saranno avviate in parallelo.

Le dipendenze sono di solito posizionate sui .service e non sui .target. Per esempio, network.target è richiamato qualsiasi sia il servizio che configuri l'interfaccia di rete, quindi avviare successivamente la propria unità personalizzata è sufficiente in quanto network.target è avviato comunque.

Type

Ci sono parecchi tipi differenti di avvio da considerare quando si scrive un servizio personalizzato. Ciò è configurato tramite il parametro Type= nella sezione [Service]. Vedere systemd.service(5) per una spiegazione più dettagliata.

  • Type=simple(default): systemd presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.
  • Type=forking: systemd presuppone che il servizio deve essere avviato prima il processo sia suddiviso e il genitore sia concluso. Per i classici demoni usare questo tipo a meno che non si sappia che non è necessario, come la maggior parte dei demoni usa il double-forking per segnalare che sono pronti. Occorre pure specificare PIDFile= perché systemd tenga traccia del processo principale.
  • Type=oneshot: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con RemainAfterExit=yes in modo che systemd consideri il servizio ancora attivo anche dopo che il processo si è concluso.
  • Type=notify: Identico a Type=simple, ma con l'accorgimento che il demone invierà un segnale a systemd quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da libsystemd-daemon.so.
  • Type=dbus: Il servizio è considerato pronto quando lo specificato BusName appare nel sistema di bus si DBus.

Rimpiazzare le unità fornite

Per editare il file unit fornito da un pacchetto, si può creare una cartella chiamata /etc/systemd/system/<unit>.d/ per esempio /etc/systemd/system/httpd.service.d/ e mettere i files *.conf in essa per sovrascrivere e aggiungere nuove opzioni. Systemd controllerà questi files *.conf e li applicherà al di sopra degli originali. Per esempio, se si vuole semplicemente aggiungere un dipendenza all'unità si può creare il seguente file:

/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<new dependency>
After=<new dependency>

Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:

# systemctl daemon-reload
# systemctl restart <unit>

In alternativa si può copiare la vecchia unità da /usr/lib/systemd/system/ in /etc/systemd/system/ e fare qui le modifiche. Una unità in /etc/systemd/system/ sovrascriverà sempre la stessa unità in /usr/lib/systemd/system/. Da notare che quando l'unità originale in /usr/lib/ cambia a causa di un aggiornamento, le modifiche non si rifletteranno automaticamente sulla propria unità personalizzata in /etc/. In aggiunta occorre riattivarla manualmente con systemctl reenable <unit>. E' raccomandato usare il metodo con il *.conf descritto sopra.

Suggerimento: Si può usare systemd-delta per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.
Siccome le unità saranno aggiornate di volta in volta , usare systemd-delta per la manutenzione del sistema.

Evidenziazione della sintassi per le unità di systemd con Vim

L'evidenziazione della sintassi per le unità di systemd con Vim può essere attivata installando vim-systemd dal repo ufficiale.

Targets

Quello dei "runlevels" è un concetto superato in systemd. Systemd ha il concetto di target (lett. "bersagli") che adempiono uno scopo simile a quello dei runlevel, ma che hanno un comportamento leggermente differente. Ogni target ha un nome anziché un numero ed è usato per raggiungere uno specifico scopo con la possibilità di averne più di uno attivo nello stesso momento. Alcuni targets sono attivati ereditando tutto dei servizi di un altro target e implementandolo di servizi addizionali. Ci sono target che simulano i runlevel di SystemVinit, è così possibile passare da un target all'altro utilizzando il comando telinit RUNLEVEL.

Conoscere il target attuale

Il seguente comando dovrebbe essere usato sotto systemd al posto di runlevel:

$ systemctl list-units --type=target

Creare un target personalizzato

I runlevels sono assegnati ad uno specifico scopo su l'installazione vanilla di Fedora; 0, 1, 3, 5, e 6; hanno una mappatura 1:1 con uno specifico target di systemd. Sfortunatamente non c'è un altrettanto buon metodo per i runlevels definiti dall'utente come 2 e 4. Se si fa uso di questi, si suggerisce di dare un nuovo nome al target di systemd come /etc/systemd/system/<your target> che prenda come base une dei runlevels esistenti (vedi /usr/lib/systemd/system/graphical.target come esempio), creare una cartella /etc/systemd/system/<your target>.wants, e fare un collegamento ai servizi addizionali da /usr/lib/systemd/system/ che si intendono attivare.

Targets table

SysV Runlevel systemd Target Notes
0 runlevel0.target, poweroff.target Ferma il sistema.
1, s, single runlevel1.target, rescue.target Modalità utente singolo (single user).
2, 4 runlevel2.target, runlevel4.target, multi-user.target Definita dall'utente. Preconfigurata a 3.
3 runlevel3.target, multi-user.target Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 runlevel5.target, graphical.target Multi-user, grafica. Solitamente ha tutti i servizi del runlevel 3 con l'aggiunta di un login grafico.
6 runlevel6.target, reboot.target Riavvio
emergency emergency.target Console di emergenza

Cambiare il target corrente

In systemd i targets sono esplicitati per mezzo di "target units". Si possono cambiare così:

# systemctl isolate graphical.target

Questo comando cambierà solamente il target corrente e non avrà nessun effetto sul prossimo avvio. Questo è equivalente ai comandi telinit 3 oppure telinit 5 in Sysvinit.

Cambiare il target predefinito all'avvio

Il target standard è default.target, che è abbinato in modo predefinito a graphical.target (che corrisponde al vecchio runlevel 5). Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:

Suggerimento: L'estensione .target può essere tralasciata.
  • systemd.unit=multi-user.target (che corrisponde al vecchio runevel 3),
  • systemd.unit=rescue.target (che corrisponde al vecchio runevel 1).

In alternativa si può lasciare il bootloader inalterato e cambiare default.target. Ciò può essere fatto usando systemctl:

# systemctl enable multi-user.target

L'effetto di questo comando si nota nell'output di systemctl; viene creato un link simbolico al nuovo target predefinito /etc/systemd/system/default.target. Questo funziona solo se:

[Install]
Alias=default.target

si trova nel file di configurazione del target. Attualmente, sia multi-user.target che graphical.target lo possiedono.

Timers

Systemd can replace cron functionality to a great extent. See systemd/Timers.

Il Journal

Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal. Tuttavia, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:

# journalctl

Di default (quando Storage= è configurato a auto in /etc/systemd/journald.conf), il journal scrive in /var/log/journal/. La directory /var/log/journal/ è parte di core/systemd. Se si è cancellata intenzionalmente o se qualche programma lo ha fatto systemd non lo riicreerà automaticamente, tuttavia sarà ricreata durante il prossimo aggiornamento di systemd. Fino a quel momento i log saranno scritti in /run/systemd/journal. Ciò significa che i log saranno persi al riavvio.

Filtrare l' output

journalctl permette di filtrare l'output secondo specifici campi.

Esempi:

Mostrare tutti i messaggi di questo boot:

# journalctl -b

Tuttavia, spesso un utente può essere interessato ai messaggi non del corrente boot, ma del precedente (per esempio a causa di un non recuperabile blocco occorso). Attualmente, questa opzione non è implementata, ma esiste una discussione a systemd-devel@lists.freedesktop.org (Settembre/Ottobre 2012).

Come workaround al momento si può usare:

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

,che provoca che il precedente boot sia come scaturito oggi. Tenere presente che, se ci sono molti messaggi per il giorno corrente, l'output di questo comando può essere ritardato per un bel po 'di tempo.

Seguire i nuovi messaggi:

# journalctl -f

Mostrare tutti i messaggi di un eseguibile specifico:

# journalctl /usr/lib/systemd/systemd

Mostrare tutti i messaggi di uno specifico processo:

# journalctl _PID=1

Mostrare tutti i messaggi di una specifica unità:

# journalctl -u netcfg


Vedere journalctl(1) e systemd.journal-fields oppure il blog di Lennert per dettagli.

Limiti alla dimensione del journal

Se il journal è persistente (non volatile) la sua dimensione è fissata al 10% della dimensione del rispettivo file system. Per esempio con /var/log/journal allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal. La dimensione massima del journal persistente può essere controllata attraverso SystemMaxUse in /etc/systemd/journald.conf, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:

SystemMaxUse=50M

Fare riferimento a journald.conf(5) per maggiori dettagli.

Journald coesistente con syslog

La compatibilità con il classico syslog è fornita dal socket /run/systemd/journal/syslog, attraverso il quale passano tutti i messaggi. Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a /dev/log (official announcement). Il pacchetto syslog-ng dei repo ufficiali automaticamente fornisce la necessaria configurazione.

# systemctl enable syslog-ng

Una buona guida a journalctl è qui.

Correzione di errori

Lo spegnimento e il riavvio sono terribilmente lunghi

Se il processo di spegnimento impiega molto tempo (oppure sembra bloccarsi) probabilmente la colpa è da attribuirsi alla mancata chiusura di un servizio. Systemd attende del tempo per la chiusura di ogni servizio prima di chiuderlo forzatamente. Per vedere se si soffre di questo problema vedere questo articolo.

I processi di breve durata non registrano nessun output

Se journalctl -u foounit.service non mostra nessun output per un processo di breve durata, controllare il PID. Per esempio, se systemd-modules-load.service fallisce, e systemctl status systemd-modules-load evidenzia che è eseguito con PID 123, è possibile vedere l'output del journal per quel PID, per esempio journalctl -b _PID=123. I campi con metadata del journal come _SYSTEMD_UNIT e _COMM sono raccolti in modo asincrono e fanno affidamento sulla cartella /proc per il processo esistente. La sistemazione di questo richiede una sistemazione del kernel per fornire questi dati per mezzo di una connessione socket, come per SCM_CREDENTIALS.

Diagnosi dei problemi al Boot

Avviare il sistema con questi parametri sulla linea di comando del kernel:

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

Maggiori informazioni sul Debugging

Vedi anche