Difference between revisions of "Systemd (Italiano)"

From ArchWiki
Jump to: navigation, search
(Allineamento al 04.10.2012 17:07)
(Allineamento al 06.10.2012 17:17)
Line 38: Line 38:
 
# Riavviare.
 
# Riavviare.
  
systemd avvierà i demoni in /etc/rc.conf e avvierà /etc/rc.local e /etc/rc.local.shutdown al boot / shutdown rispettivamente.
+
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.
 +
Se il vecchio supporto per DAEMONS in {{ic|rc.conf}} o lo  scripts in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.
 +
{{Avvertimento|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 ===
 
=== Una installazione mista systemd/initscripts ===
Line 47: Line 49:
 
# [[#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.
 
# [[#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.
 
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.
# Rimuovere {{ic|1=init=...}} in quanto /sbin/init ora è un link simbolico a systemd.
+
# Rimuovere {{ic|1=init=...}} in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.
 
# Riavviare.
 
# Riavviare.
  
Se il vecchio supporto per i DEMONI in rc.conf oppure non si necessite dello script rc.local, i corrispondenti file service possono essere disabilitati.
+
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.
  
 
=== Installazione pura di systemd ===
 
=== Installazione pura di systemd ===
Line 57: Line 59:
  
 
# Seguire le istruzioni per una installazione mista systemd/initscripts
 
# Seguire le istruzioni per una installazione mista systemd/initscripts
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di rc.conf e che /etc/rc.local e /etc/rc.local.shutdown siano entrambi vuoti.
+
# 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.
 
# Rimuovere il pacchetto initscripts dal sistema.
  
 
=== Informazioni supplementari ===
 
=== Informazioni supplementari ===
  
{{Nota|1=In una installazione di systemd pura, installando {{pkg|systemd-sysvcompat}} si rimpiazza {{pkg|sysvinit}} e si creano i collegamenti a halt, reboot ecc.}}
+
{{Suggerimento|Se si utilizza {{ic|quiet}} nei parametri del kernel, è possibile rimuoverlo durante i primi avvii per identificare eventuali problemi durante il boot.}}
 
+
{{Suggerimento|Se si utilizza {{ic|quiet}} nei parametri del kernel, è necessario rimuoverlo durante i primi avvii per identificare eventuali problemi durante il boot.}}
+
{{Attenzione|{{ic|/usr}} deve essere montata e disponibile al boot (questo non è un particolare di systemd). Se {{ic|/usr}} risiede in una partizione separata, avrete bisogno di fare degli aggiustamenti per montarla con l'initramfs e smontarla da root allo spegnimento.
+
Vedi [[Mkinitcpio#/usr_as_a_separate_partition|il wiki di mkinitcpio]] e [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken separate-usr-is-broken]}}
+
  
 
== I files di configurazione nativi di systemd ==
 
== I files di configurazione nativi di systemd ==
Line 77: Line 75:
 
=== Impostazioni di console e keymap ===
 
=== Impostazioni di console e keymap ===
 
:Il file /etc/vconsole.conf configura i terminali virtuali, per esempio la mappatura della tastiera ed il tipo di carattere.
 
:Il file /etc/vconsole.conf configura i terminali virtuali, per esempio la mappatura della tastiera ed il tipo di carattere.
{{hc|/etc/vconsole.conf|<nowiki>
+
{{hc|/etc/vconsole.conf|2=
 
KEYMAP=it
 
KEYMAP=it
 
FONT=
 
FONT=
FONT_MAP=</nowiki>}}
+
FONT_MAP=}}
  
 
Per maggiori informazioni vedere  [[Fonts_(Italiano)#Font_per_console|i font per console]] e [[KEYMAP#Keyboard_layouts|configurazione tastiera]].
 
Per maggiori informazioni vedere  [[Fonts_(Italiano)#Font_per_console|i font per console]] e [[KEYMAP#Keyboard_layouts|configurazione tastiera]].
  
 
{{Suggerimento|Per usare i font e la mappatura della tastiera contenuti nel kernel invece di quelli di default di systemd:
 
{{Suggerimento|Per usare i font e la mappatura della tastiera contenuti nel kernel invece di quelli di default di systemd:
{{hc|/etc/vconsole.conf|<nowiki>
+
{{hc|/etc/vconsole.conf|2=
 
KEYMAP=
 
KEYMAP=
 
FONT=
 
FONT=
Line 94: Line 92:
 
=== Impostazioni locali ===
 
=== Impostazioni locali ===
 
Leggere le pagine man di locale.conf per maggiori opzioni:  
 
Leggere le pagine man di locale.conf per maggiori opzioni:  
{{hc|/etc/locale.conf|<nowiki>
+
{{hc|/etc/locale.conf|2=
 
LANG=it_IT.UTF-8</nowiki>}}
 
LANG=it_IT.UTF-8</nowiki>}}
  
Line 101: Line 99:
 
=== Settare il fuso orario ===
 
=== Settare il fuso orario ===
 
Leggere {{ic|man 5 localtime}} per maggiori opzioni.
 
Leggere {{ic|man 5 localtime}} per maggiori opzioni.
 +
 
  # ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
 
  # ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
  
Line 106: Line 105:
  
 
=== Orario di sistema ===
 
=== Orario di sistema ===
 +
 
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).
 
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).
  
Line 119: Line 119:
  
 
=== Configurare i moduli del kernel da caricare al boot ===
 
=== Configurare i moduli del kernel da caricare al boot ===
 +
 
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:
 
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:
{{hc|/etc/modules-load.d/virtio-net.conf|<nowiki>
+
{{hc|/etc/modules-load.d/virtio-net.conf|
 
# Carica virtio-net.ko al boot
 
# Carica virtio-net.ko al boot
virtio-net</nowiki>
+
virtio-net}}
}}
+
 
 
Vedi anche [[Kernel_modules_(Italiano)#Opzioni|Opzioni di Modprobe]]
 
Vedi anche [[Kernel_modules_(Italiano)#Opzioni|Opzioni di Modprobe]]
  
 
=== Blacklist dei moduli del kernel ===
 
=== Blacklist dei moduli del kernel ===
 +
 
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.
 
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.
  
 
=== I files temporanei ===
 
=== I files temporanei ===
 +
 
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.
 
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.
  
 
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:
 
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:
 +
 
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 
{{hc|/usr/lib/tmpfiles.d/samba.conf|
D /var/run/samba 0755 root root
+
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:
 
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:
 +
 
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
w /proc/acpi/wakeup - - - - USBE
+
w /proc/acpi/wakeup - - - - USBE}}
}}
+
 
 
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.
 
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.
  
Line 146: Line 150:
  
 
=== Montaggio di filesystem remoti ===
 
=== 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.
+
 
 +
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.
 
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.
Line 153: Line 158:
  
 
=== ACPI Power Management con systemd ===
 
=== 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}}:
 
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|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|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|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
+
* {{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}}.
 
Le azioni specificate possono essere una qualsiasi di {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.
  
Line 166: Line 174:
 
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.
 
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, nessun gestore di alimentazione ha i necessari comandi inibitori. Quando li avranno, occorrerà settare l'opzione {{ic|Handle}} a {{ic|ignore}} se si voglio gestire gli eventi ACPI con [[KDE]], [[GNOME]], [[Xfce]], [[acpid]] o qualsiasi altro programma. Le nuove versioni stanno implementando tale funzionalità.}}
+
{{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à.}}
  
 
=== Sleep hooks ===
 
=== Sleep hooks ===
Line 172: Line 180:
 
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando
 
* 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.
 
* 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 in parallelo e non uno dopo l'altro.
+
 
 +
Al contrario di [[Pm-utils_(Italiano)|Pm-utils]], systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.
  
 
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]].
 
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]].
Line 181: Line 190:
  
 
==== Esempi ====
 
==== Esempi ====
 +
 
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki>
 
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki>
 
#!/bin/sh
 
#!/bin/sh
Line 194: Line 204:
  
 
=== Unità ===
 
=== 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 {{ic|man systemd.unit}} per maggiori informazioni.
 
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.
  
Line 209: Line 220:
 
Lista della unità attive:
 
Lista della unità attive:
  
{{bc|$ systemctl}}
+
$ systemctl
  
 
oppure:
 
oppure:
  
{{bc|$ systemctl list-units}}
+
$ systemctl list-units
  
 
Lista delle unità che hanno avuto problemi:
 
Lista delle unità che hanno avuto problemi:
  
{{bc|$ systemctl --failed}}
+
$ systemctl --failed
  
 
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:
 
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:
{{bc|$ systemctl list-unit-files}}
+
 
 +
$ systemctl list-unit-files
  
 
=== Usare le unità ===
 
=== Usare le unità ===
  
 
Le unità possono essere, per esempio, servizi ({{ic|.service}}), punti di monatggio ({{ic|.mount}}), dispositivi ({{ic|.device}}) oppure i sockets ({{ic|.socket}}).  
 
Le unità possono essere, per esempio, servizi ({{ic|.service}}), punti di monatggio ({{ic|.mount}}), dispositivi ({{ic|.device}}) oppure i sockets ({{ic|.socket}}).  
 +
 
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}}:
 
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}}:
 +
 
* Se non si specifica il suffisso, per systemctl sarà sottointeso {{ic|.service}}. Per esempio, {{ic|netcfg}} e {{ic|netcfg.service}} sono equivalenti.
 
* Se non si specifica il suffisso, per systemctl sarà sottointeso {{ic|.service}}. Per esempio, {{ic|netcfg}} e {{ic|netcfg.service}} sono equivalenti.
 
{{Nota|Attualmente non funzionante con i comandi {{ic|enable}} e {{ic|disable}}.}}
 
{{Nota|Attualmente non funzionante con i comandi {{ic|enable}} e {{ic|disable}}.}}
Line 234: Line 248:
 
Attivare immediatamente una unità:
 
Attivare immediatamente una unità:
  
{{bc|# systemctl start <unit>}}
+
# systemctl start <unit>
  
 
Fermare immediatamente una unità:
 
Fermare immediatamente una unità:
  
{{bc|# systemctl stop <unit>}}
+
# systemctl stop <unit>
  
 
Far ripartire una unità:
 
Far ripartire una unità:
  
{{bc|# systemctl restart <unit>}}
+
# systemctl restart <unit>
  
 
Chiedere ad una unità di ricaricare la sua configurazione:
 
Chiedere ad una unità di ricaricare la sua configurazione:
  
{{bc|# systemctl reload <unit>}}
+
# systemctl reload <unit>
  
 
Mostrare lo stato di una unità, compreso se sta funzionando o no:
 
Mostrare lo stato di una unità, compreso se sta funzionando o no:
  
{{bc|$ systemctl status <unit>}}
+
$ systemctl status <unit>
  
 
Controllare se una unità è già attivata o no:
 
Controllare se una unità è già attivata o no:
  
{{bc|$ systemctl is-enabled <unit>}}
+
$ systemctl is-enabled <unit>
  
 
Attivare l'avvio automatico al boot:
 
Attivare l'avvio automatico al boot:
  
{{bc|# systemctl enable <unit>}}
+
# systemctl enable <unit>
  
{{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 "foo" con il nome del servizio.
+
{{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.
 
+
{{bc|# ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/}}
+
  
 +
# ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/
 
}}
 
}}
  
 
Disattivare l'avvio automatico al boot:
 
Disattivare l'avvio automatico al boot:
  
{{bc|# systemctl disable <unit>}}
+
# systemctl disable <unit>
  
 
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):
 
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):
  
{{bc|$ systemctl help <unit>}}
+
$ systemctl help <unit>
  
 
=== Power Management ===
 
=== Power Management ===
Line 280: Line 293:
 
Spegnimento e riavvio del sistema:
 
Spegnimento e riavvio del sistema:
  
{{bc|$ systemctl reboot}}
+
$ systemctl reboot
  
 
Spegnimento del sistema:
 
Spegnimento del sistema:
  
{{bc|$ systemctl poweroff}}
+
$ systemctl poweroff
  
 
Spegnimento completo del sistema:
 
Spegnimento completo del sistema:
  
{{bc|$ systemctl halt}}
+
$ systemctl halt
  
 
Sospensione del sistema:
 
Sospensione del sistema:
  
{{bc|$ systemctl suspend}}
+
$ systemctl suspend
  
 
Ibernazione del sistema:
 
Ibernazione del sistema:
  
{{bc|$ systemctl hibernate}}
+
$ systemctl hibernate
  
 
== Runlevel/target ==
 
== Runlevel/target ==
 +
 
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}}.
 
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}}.
  
 
=== Conoscere il runlevel/targets corrente ===
 
=== Conoscere il runlevel/targets corrente ===
 +
 
Il seguente comando dovrebbe essere usato sotto systemd al posto di {{ic|runlevel}}:
 
Il seguente comando dovrebbe essere usato sotto systemd al posto di {{ic|runlevel}}:
{{bc|1=# systemctl list-units --type=target}}
+
# systemctl list-units --type=target
  
 
=== Creare un target personalizzato ===
 
=== 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 {{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.
 
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.
  
 
=== Targets table ===
 
=== Targets table ===
 +
 
{| border="1"
 
{| border="1"
 
!SysV Runlevel!!Systemd Target!!Notes
 
!SysV Runlevel!!Systemd Target!!Notes
Line 329: Line 346:
  
 
=== Cambiare il runlevel corrente ===
 
=== Cambiare il runlevel corrente ===
 +
 
In systemd i runlevels sono esplicitati per mezzo di "target units". Si possono cambiare così:
 
In systemd i runlevels sono esplicitati per mezzo di "target units". Si possono cambiare così:
{{bc|# systemctl isolate graphical.target}}
+
# systemctl isolate graphical.target
 
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.
 
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.
  
 
=== Cambiare il runlevel/target predefinito all'avvio ===
 
=== Cambiare il runlevel/target predefinito all'avvio ===
 +
 
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:
 
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:
 
* {{ic|1=systemd.unit=multi-user.target}} (che corrisponde al vecchio runevel 3),
 
* {{ic|1=systemd.unit=multi-user.target}} (che corrisponde al vecchio runevel 3),
Line 339: Line 358:
  
 
In alternativa si può lasciare il bootloader inalterato e cambiare  {{ic|default.target}}. Ciò può essere fatto usando {{ic|systemctl}}:
 
In alternativa si può lasciare il bootloader inalterato e cambiare  {{ic|default.target}}. Ciò può essere fatto usando {{ic|systemctl}}:
{{bc|# systemctl enable multi-user.target}}
+
# systemctl enable multi-user.target
  
 
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:
 
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:
 +
 
  [Install]
 
  [Install]
 
  Alias=default.target
 
  Alias=default.target
 +
 
si trova nel file di configurazione del target. Attualmente, sia {{ic|multi-user.target}} che {{ic|graphical.target}} lo possiedono.
 
si trova nel file di configurazione del target. Attualmente, sia {{ic|multi-user.target}} che {{ic|graphical.target}} lo possiedono.
  
Line 350: Line 371:
 
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]].
 
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]].
  
{{bc|# systemctl enable kdm.service}}
+
# systemctl enable kdm.service
  
 
Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:
 
Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:
Line 358: Line 379:
 
è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio {{ic|graphical.target}}).
 
è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio {{ic|graphical.target}}).
  
{{bc|# rm /etc/systemd/system/default.target}}
+
# rm /etc/systemd/system/default.target
  
 
=== Usare i service file ===
 
=== Usare i service file ===
 +
 
{{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:  
 
{{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:  
 
[[#Rimpiazzare_ConsoleKit_con_systemd-logind|Rimpiazzare ConsoleKit con systemd-logind]] e [[Automatic_login_to_virtual_console_(Italiano)#Usare_systemd]].}}
 
[[#Rimpiazzare_ConsoleKit_con_systemd-logind|Rimpiazzare ConsoleKit con systemd-logind]] e [[Automatic_login_to_virtual_console_(Italiano)#Usare_systemd]].}}
 +
 
Se si sta cercando un modo semplice per avviare X direttamente senza un DM si può creare un file .service come questo:
 
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/graphical.target.wants/xinit.service|<nowiki>
+
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|2=
 
[Unit]
 
[Unit]
 
Description=Direct login to X
 
Description=Direct login to X
Line 374: Line 397:
  
 
[Install]
 
[Install]
WantedBy=graphical.target
+
WantedBy=graphical.target}}
</nowiki>}}
+
 
  
 
== Il Journal di Systemd ==
 
== Il Journal di Systemd ==
 +
 
Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal.
 
Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal.
  
 
Come prassi, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:
 
Come prassi, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:
{{bc|# journalctl}}
+
 
 +
# journalctl
 +
 
 
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/}}:
 
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/}}:
{{bc|# mkdir /var/log/journal/}}
+
 
 +
# mkdir /var/log/journal/
  
 
=== Filtrare l' output ===
 
=== Filtrare l' output ===
Line 392: Line 419:
  
 
Mostra tutti i messaggi di un eseguibile specifico:
 
Mostra tutti i messaggi di un eseguibile specifico:
{{bc|# journalctl /usr/lib/systemd/systemd}}
+
 
 +
# journalctl /usr/lib/systemd/systemd
  
 
Mostra tutti i messaggi di uno specifico processo:
 
Mostra tutti i messaggi di uno specifico processo:
{{bc|1=# journalctl _PID=1}}
+
 
 +
# journalctl _PID=1
  
 
Mostra tutti i messaggi di una specifica unità:
 
Mostra tutti i messaggi di una specifica unità:
{{bc|1=# journalctl _SYSTEMD_UNIT=netcfg.service}}
+
 
 +
# journalctl _SYSTEMD_UNIT=netcfg.service
 +
 
  
 
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} per dettagli.
 
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} per dettagli.
Line 405: Line 436:
  
 
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:
 
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:
{{bc|1=SystemMaxUse=50M}}
+
 
 +
SystemMaxUse=50M
 +
 
 
Fare riferimento a {{ic|man journald.conf}} per maggiori dettagli.
 
Fare riferimento a {{ic|man journald.conf}} per maggiori dettagli.
  
 
====Journald coesistente al classico demone syslog====
 
====Journald coesistente al classico demone syslog====
 +
 
La compatibilità con il classico syslog è fornita dal socket {{ic|/run/systemd/journal/syslog}}, attraverso il quale passano tutti i messaggi.
 
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]). Nel caso di syslog-ng cambiare la sezione {{ic|source src}} di {{ic|/etc/syslog-ng/syslog-ng.conf}} così:
 
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ì:
{{bc|<nowiki>
+
 
 
source src {
 
source src {
 
     unix-dgram("/run/systemd/journal/syslog");
 
     unix-dgram("/run/systemd/journal/syslog");
 
     internal();
 
     internal();
 
     file("/proc/kmsg");
 
     file("/proc/kmsg");
};</nowiki>}}
+
}
  
 
e attivare syslog-ng:
 
e attivare syslog-ng:
{{bc|# systemctl enable syslog-ng.service}}
+
 
 +
# systemctl enable syslog-ng.service
  
 
== Network ==
 
== Network ==
 +
 
=== Dinamico (DHCP)con dhcpcd ===
 
=== Dinamico (DHCP)con dhcpcd ===
 +
 
Se si vuole semplicemente utilizzare DHCP per la connessione Ethernet, si può usare {{ic|dhcpcd@.service}} (fornito dal pacchetto {{Pkg|dhcpcd}}.
 
Se si vuole semplicemente utilizzare DHCP per la connessione Ethernet, si può usare {{ic|dhcpcd@.service}} (fornito dal pacchetto {{Pkg|dhcpcd}}.
 
Per utilizzare DHCP per {{ic|eth0}}, semplicemente usare:
 
Per utilizzare DHCP per {{ic|eth0}}, semplicemente usare:
Line 428: Line 465:
  
 
Si può attivare l'avvio automatico al boot con:
 
Si può attivare l'avvio automatico al boot con:
# systemctl enable dhcpcd@eth0.service
+
# systemctl enable dhcpcd@eth0.service
  
Alcune volte il servizio dhcpd si avvia prima del modulo della scheda di rete (bug[https://bugs.archlinux.org/task/30235]), aggiungere manualmente il modulo della propria scheda di rete a /etc/modules-load.d/****.conf.  esempio: creare /etc/modules-load.d/r8169.conf, per una scheda realtek
+
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
 
  # r8169
  
 
=== Altre configurazioni ===
 
=== 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.
 
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.}}
 
{{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.}}
  
Line 440: Line 479:
  
 
== Integrazione con Arch ==
 
== Integrazione con Arch ==
 +
 
=== Emulazione degli initscripts ===
 
=== 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.
 
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.
  
Line 448: Line 489:
  
 
==== rc.conf ====
 
==== 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}}.
 
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:
 
Variabili supportate:
 +
 
* LOCALE
 
* LOCALE
 
* KEYMAP
 
* KEYMAP
Line 467: Line 510:
  
 
=== Conversione totale a systemd puro ===
 
=== 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.}}
 
{{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:
 
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:
 +
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 506: Line 551:
  
 
  # systemctl enable <nome_del_servizio>.service
 
  # 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]].}}
 
{{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:
 
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.
 
* 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.)
 
* 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:
 
{{Suggerimento|Si può guardare dentro i pacchetti che contengono gli script di avvio per il nome del servizio. Per esempio:
 
  $ pacman -Ql cronie
 
  $ pacman -Ql cronie
 
  [...]
 
  [...]
  cronie /etc/rc.d/crond                            #<-- daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)
+
  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
+
  cronie /usr/lib/systemd/system/cronie.service    #Corresponding systemd daemon service
 
  [...]
 
  [...]
 
}}
 
}}
Line 523: Line 571:
  
 
==Scrivere i files .service personalizzati==
 
==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 {{ic|man 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}}: 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.
Line 536: Line 588:
  
 
===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/}}.
 
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.
 
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:
 
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|
+
{{hc|/etc/systemd/system/<service-name>.service|2=
<nowiki>
+
 
.include /usr/lib/systemd/system/<service-name>.service
 
.include /usr/lib/systemd/system/<service-name>.service
  
 
[Unit]
 
[Unit]
 
Requires=<new dependency>
 
Requires=<new dependency>
After=<new dependency>
+
After=<new dependency>}}
</nowiki>}}
+
 
 
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:
 
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:
 +
 
  # systemctl reenable <unit>
 
  # systemctl reenable <unit>
 
  # 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.}}
 
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono stae modificate.}}
  
 
===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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].
  
Line 566: Line 621:
 
|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/}} :
 
|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/}} :
  
{{bc|<nowiki># ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
+
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
 
# systemctl daemon-reload
 
# systemctl daemon-reload
# systemctl start getty@tty9.service</nowiki>}}
+
# systemctl start getty@tty9.service
  
 
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :
 
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :
  
{{bc|<nowiki># rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
+
# rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
 
# systemctl daemon-reload
 
# systemctl daemon-reload
# systemctl stop getty@tty5.service getty@tty6.service</nowiki>}}
+
# systemctl stop getty@tty5.service getty@tty6.service
  
 
systemd non usa il file /etc/inittab.
 
systemd non usa il file /etc/inittab.
  
{{Nota|Dalla versione 30 di systemd, solo 1 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.}}}}
+
{{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.}}}}
  
  
Line 585: Line 640:
 
|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.
 
|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}}.
+
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}}.}}
}}
+
  
 
{{FAQ
 
{{FAQ
Line 599: Line 653:
 
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:
 
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:
  
{{bc|<nowiki>
 
 
CONFIG_AUDIT=y (raccomandata)
 
CONFIG_AUDIT=y (raccomandata)
 
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non richiesta, può dare problemi a sysvinit compat)
 
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non richiesta, può dare problemi a sysvinit compat)
Line 614: Line 667:
 
CONFIG_NET_NS=y (per PrivateNetwork=yes)
 
CONFIG_NET_NS=y (per PrivateNetwork=yes)
 
CONFIG_FHANDLE=y
 
CONFIG_FHANDLE=y
</nowiki>}}}}
+
}}
  
 
{{FAQ
 
{{FAQ
Line 626: Line 679:
 
|question=Il mio computer si spegne, ma l'alimentatore resta acceso.
 
|question=Il mio computer si spegne, ma l'alimentatore resta acceso.
 
|answer=Usare
 
|answer=Usare
 +
 
  $ systemctl poweroff
 
  $ systemctl poweroff
Invece di {{ic|systemctl halt}}.}}
+
 
 +
invece di {{ic|systemctl halt}}.}}
  
 
{{FAQ
 
{{FAQ
 
|question=Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?
 
|question=Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?
|answer=Assicurarsi di usare {{bc|# systemctl enable dmraid.service}}
+
|answer=Assicurarsi di usare  
 +
 
 +
# systemctl enable dmraid.service
 
}}
 
}}
  
Line 637: Line 694:
 
|question=Come posso fare in modo che uno script sia eseguito al boot?
 
|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:
 
|answer=Creare un nuovo file in {{ic|/etc/systemd/system}} (e.g. "myscript".service) e aggiungere il seguente contenuto:
{{bc|<nowiki>
+
 
 
[Unit]
 
[Unit]
 
Description=My script
 
Description=My script
Line 646: Line 703:
 
[Install]
 
[Install]
 
WantedBy=multi-user.target  
 
WantedBy=multi-user.target  
</nowiki>}}
+
 
 
Poi
 
Poi
{{bc|# systemctl enable "myscript".service}}
+
 
 +
# systemctl enable "myscript".service
 
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato.
 
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato.
 
}}
 
}}
Line 657: Line 715:
 
Nel caso specifico di iptables è perché non c'è nessun demone da avviare, è controllato dal kernel. Tuttavia esiste dopo che le regole sono state caricate.
 
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:
 
Per verificare se le regole di iptables sono state caricate correttamente:
{{bc|iptables --list}}
+
{{bc|# iptables --list}}
 
}}
 
}}
  
Line 670: Line 728:
  
 
=== systemd-analyze ===
 
=== systemd-analyze ===
 +
 
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.
 
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.
  
 
Per vedere quanto tempo ha impiegato il boot del kernel e dello userspace, semplicemente si usi:
 
Per vedere quanto tempo ha impiegato il boot del kernel e dello userspace, semplicemente si usi:
{{bc|$ systemd-analyze}}
+
 
 +
$ systemd-analyze
 +
 
 
{{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.}}
 
{{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.}}
  
 
Per elencare le unità partite, ordinate a seconda del tempo che impiegano ad avviarsi:
 
Per elencare le unità partite, ordinate a seconda del tempo che impiegano ad avviarsi:
{{bc|$ systemd-analyze blame}}
+
 
 +
$ systemd-analyze blame
  
 
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:
 
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:
{{bc|$ systemd-analyze plot > plot.svg}}
+
 
 +
$ systemd-analyze plot > plot.svg
  
 
====Attivare bootchart assieme a systemd====
 
====Attivare bootchart assieme a systemd====
 +
 
E' possibile usare una versione di bootchart per visualizzare la sequenza di boot.
 
E' possibile usare una versione di bootchart per visualizzare la sequenza di boot.
 
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:
 
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:
{{bc|# systemctl enable bootchart.service}}
+
 
 +
# systemctl enable bootchart.service
 +
 
 
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.
 
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.
  
 
=== Tasti di scelta rapida della Shell ===
 
=== Tasti di scelta rapida della Shell ===
 +
 
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 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.
  
Line 706: Line 773:
  
 
=== Diminuire l'output ===
 
=== 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.
 
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 ===
 
=== 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:
 
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:
  
{{bc|# systemctl enable console-kit-daemon.service}}
+
# 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.
 
Questo provocherà l'avvio di ConsoleKit al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.
  
 
=== Automount ===
 
=== 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:
 
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:
  
Line 726: Line 796:
  
 
=== Readahead ===
 
=== 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:
 
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:
  
{{bc|<nowiki># systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service</nowiki>}}
+
# 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.
 
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.
  
 
=== Rimpiazzare ConsoleKit con systemd-logind ===
 
=== 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}}.
 
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.
 
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>
 
  $ loginctl show-session <session-id>
  
Line 741: Line 814:
  
 
== Correzione di errori ==
 
== Correzione di errori ==
 +
 
=== Lo spegnimento e il riavvio sono terribilmente lunghi ===
 
=== 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.
 
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 [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 ====
 
==== SLiM in una sessione di xfce ====
 +
 
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.
 
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.
 
Un modo per aggirare il problema è la modifica di {{ic|slim.service}}:
 
Un modo per aggirare il problema è la modifica di {{ic|slim.service}}:
{{hc|/etc/systemd/system/slim.service|<nowiki>
+
 
 +
{{hc|/etc/systemd/system/slim.service|2=
 
[Unit]
 
[Unit]
 
Description=SLiM Simple Login Manager
 
Description=SLiM Simple Login Manager
Line 760: Line 838:
  
 
[Install]
 
[Install]
WantedBy=graphical.target</nowiki>}}
+
WantedBy=graphical.target}}
 
Questo causerà la chiusura di SLiM usando SIGKILL. Non causa nessun problema poichè anche il file di blocco viene rimosso.
 
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 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}}.
 
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==
 +
  
 
*[http://www.freedesktop.org/wiki/Software/systemd Sito ufficiale]
 
*[http://www.freedesktop.org/wiki/Software/systemd Sito ufficiale]

Revision as of 22:54, 6 October 2012

Sommario help replacing me
Tratta di come installare e configurare systemd
Articoli correlati
Systemd/Services
Init to systemd cheatsheet
udev - systemd e udev sono stati fusi a monte.

Dalla pagina web del 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 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 post.

Leggi anche l' articolo su Wikipedia.

Contents

Cose da considerare prima di passare a systemd

  • E' fortemente consigliato passare al nuovo sistema di configurazione degli initscripts descritto nell' articolo relativo a rc.conf. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.
  • Documentarsi su systemd.
  • Notare che systemd possiede un sistema journal che rimpiazza syslog, tuttavia i due possono coesistere. Vedi 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

Systemd può essere installato a fianco del normale pacchetto initscripts di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {ic|1=init=/bin/systemd}} dai parametri del kernel.

Una installazione mista systemd/sysvinit/initscripts

E' possibile mantenere sia systemd che sysvinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:

  1. Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante i files nativi di configurazione di systemd, e riavviare per verificare che funzionino come ci si aspetta con gli initscripts.
  2. Installare systemd dai repo ufficiali.
  3. Aggiungere init=/bin/systemd ai parametri del kernel nel bootloader.
  4. Riavviare.

Systemd avvierà i demoni in /etc/rc.conf e avvierà /etc/rc.local e /etc/rc.local.shutdown al boot / shutdown rispettivamente. Se il vecchio supporto per DAEMONS in rc.conf o lo scripts in rc.local non è necessario, il corrispondente servizio li disabiliterà. Template:Avvertimento

Una installazione mista systemd/initscripts

E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd.

  1. Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts
  2. Attivare i demoni formalmente elencati in /etc/rc.conf con systemctl enable daemonname.service . Per una traduzione dei demoni da /etc/rc.conf ai servizi di systemd, vedere: Lista dei demoni e dei 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.
  3. Installare systemd-sysvcompat. Questo va in conflitto con sysvinit, e ne chiederà la rimozione.
  4. Rimuovere init=... in quanto /sbin/init ora è un link simbolico a systemd.
  5. 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.

Installazione pura di systemd

Infine, è possibile rimuovere interamente initscripts e sysvinit e usare solo systemd.

  1. Seguire le istruzioni per una installazione mista systemd/initscripts
  2. Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di rc.conf e che /etc/rc.local e /etc/rc.local.shutdown siano entrambi vuoti.
  3. Rimuovere il pacchetto initscripts dal sistema.

Informazioni supplementari

Suggerimento: Se si utilizza quiet nei parametri del kernel, è possibile rimuoverlo durante i primi avvii per identificare eventuali problemi durante il boot.

I files di configurazione nativi di systemd

Nota: E' possibile non creare questi files.

systemd userà /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

/etc/hostname
myhostname

Impostazioni di console e keymap

Il file /etc/vconsole.conf configura i terminali virtuali, per esempio la mappatura della tastiera ed il tipo di carattere.
/etc/vconsole.conf
KEYMAP=it
FONT=
FONT_MAP=

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

Suggerimento: Per usare i font e la mappatura della tastiera contenuti nel kernel invece di quelli di default di systemd:
/etc/vconsole.conf
KEYMAP=
FONT=
</nowiki>

Questo potrebbe essere di default in futuro.

Impostazioni locali

Leggere le pagine man di locale.conf per maggiori opzioni:

/etc/locale.conf
LANG=it_IT.UTF-8</nowiki>

Per ulteriori informazioni vedere Locale.

Settare il fuso orario

Leggere man 5 localtime per maggiori opzioni.

# ln -sf /usr/share/zoneinfo/Europe/Rome /etc/localtime
Nota: /etc/timezone è deprecato da systemd-190 e può essere cancellato.

Orario di sistema

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 (c'è molto altro sull'argomento). I kernel recenti regolano l'orologio di sistema dall'orologio hardware direttamente al boot senza l'utilizzo di 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).

La ragione per cui si imposta l'orologio hardware sull'orario locale è dovuta al dual boot con Windows (il quale usa localtime). Windows può gestire l'orologio hardware regolato su UTC con un semplice aggiustamento al registro. Se si riscontrano problemi con il dual boot con Windows, si può impostare l'orologio di sistema su local time.

/etc/adjtime
0.0 0.0 0.0
0
LOCAL

Gli altri parametri sono ancora obbligatori ma ignorati da systemd. E' generalmente consigliato avere un servizio 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

Systemd usa /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 /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

Vedi anche Opzioni di Modprobe

Blacklist dei moduli del kernel

Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli initscripts in quanto è attualmente gestito da kmod. Vedere Blacklist dei moduli per maggiori dettagli.

I files 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 /var/run/samba per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:

/usr/lib/tmpfiles.d/samba.conf
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 /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

Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più /etc/rc.local.

Vedi 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 /etc/fstab dovrebbero funzionare ugualmente.

Si può utilizzare Automount per il montaggio di filesystem remoti solo nel momento dell'accesso. Ulteriormente è possibile usare l'opzione x-systemd.device-timeout=# in /etc/fstab per specificare un tempo massimo nel caso la risorsa di rete non sia disponibile.

Vedi 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 /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 or 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.

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.

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 Handle a ignore se si voglio gestire gli eventi ACPI con GNOME, Xfce, acpid o qualsiasi altro programma. Le nuove versioni stanno implementando tale funzionalità.

Sleep hooks

Systemd non usa pm-utils per mettere la macchina a riposo quando usa systemctl suspend o systemctl hibernate, Quindi gli hooks di Pm-utils incluso qualsiasi 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 /usr/lib/systemd/system-sleep/ e passa due argomenti a ognuno di essi:

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

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

L'output del vostro script sarà registrato da systemd-suspend.service o systemd-hibernate.service cosicché è possibile vedere i propri outputs nel journal.

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

Vedi man systemd.special e man systemd-sleep per maggiori informazioni.

Esempi

/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh

case "$1" in
  pre )
    echo going to $2
    ;;
  post )
    echo waking up from $2
    ;;
esac

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 man systemd.unit per maggiori informazioni.

Comandi di Systemd

  • systemctl: utilizzato per controllare lo stato del gestore di servizi e del sistema systemd
  • systemd-cgls: mostra ricorsivamente i contenuti della gerarchia del gruppo di controllo Linux selezionato con uno schema ad albero
  • systemadm: Un frontend grafico per systemd che permette un profondo controllo del sistema (disponibile attraverso il pacchetto systemd-ui-gitAUR di AUR).

Vedi le pagine man per ulteriori 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.

Analizzare lo stato del sistema

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 monatggio (.mount), dispositivi (.device) oppure i 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, netcfg e netcfg.service sono equivalenti.
Nota: Attualmente non funzionante con i comandi enable e disable.
  • I punti di montaggio saranno automaticamente tradotti nella appropriata unità .mount. Per esempio, specificare /home è equivalente a home.mount.
  • Come i punti di montaggio, anche i dispositivi sono automaticamente tradotti nell'appropriata unità .device, quindi specificare /dev/sda2 è equivalente a dev-sda2.device.

Vedi man systemd.unit per dettagli.

Attivare immediatamente una unità:

  1. systemctl start <unit>

Fermare immediatamente una unità:

  1. systemctl stop <unit>

Far ripartire una unità:

  1. systemctl restart <unit>

Chiedere ad una unità di ricaricare la sua configurazione:

  1. 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:

  1. systemctl enable <unit>
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 foo con il nome del servizio.
  1. ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/

Disattivare l'avvio automatico al boot:

  1. systemctl disable <unit>

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

$ systemctl help <unit>

Power Management

Se ci si trova in una sessione locale di 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)..

Spegnimento e riavvio del sistema:

$ systemctl reboot

Spegnimento del sistema:

$ systemctl poweroff

Spegnimento completo del sistema:

$ systemctl halt

Sospensione del sistema:

$ systemctl suspend

Ibernazione del sistema:

$ systemctl hibernate

Runlevel/target

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 runlevel/targets corrente

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

  1. 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 runlevel corrente

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

  1. systemctl isolate graphical.target

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

Cambiare il runlevel/target predefinito all'avvio

Il target standard è default.target, che è abbinato in modo predefinito a 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:

  • 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:

  1. 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.

Avviare un DE 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.

  1. systemctl enable kdm.service

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).

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

Usare i service file

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: Rimpiazzare ConsoleKit con systemd-logind e Automatic_login_to_virtual_console_(Italiano)#Usare_systemd.

Se si sta cercando un modo semplice per avviare X direttamente senza un DM si può creare un file .service come questo:

/etc/systemd/system/graphical.target.wants/xinit.service
[Unit]
Description=Direct login to X
After=systemd-user-sessions.service

[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"

[Install]
WantedBy=graphical.target


Il Journal di Systemd

Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal.

Come prassi, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:

  1. journalctl

Il sistema journal scrive in /run/systemd/journal, il ché significa che i logs svaniscono ad ogni riavvio. Per avere dei logs non volatili bisogna creare /var/log/journal/:

  1. mkdir /var/log/journal/

Filtrare l' output

journalctl permette di filtrare l'output secondo specifici campi.

Esempi:

Mostra tutti i messaggi di un eseguibile specifico:

  1. journalctl /usr/lib/systemd/systemd

Mostra tutti i messaggi di uno specifico processo:

  1. journalctl _PID=1

Mostra tutti i messaggi di una specifica unità:

  1. journalctl _SYSTEMD_UNIT=netcfg.service


Vedi man journalctl e systemd.journal-fields per dettagli.

Limiti alla dimensione del journal

Se il journal è creato come 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 man journald.conf per maggiori dettagli.

Journald coesistente al classico demone 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). Nel caso di syslog-ng cambiare la sezione source src di /etc/syslog-ng/syslog-ng.conf così:

source src {

   unix-dgram("/run/systemd/journal/syslog");
   internal();
   file("/proc/kmsg");

}

e attivare syslog-ng:

  1. systemctl enable syslog-ng.service

Network

Dinamico (DHCP)con dhcpcd

Se si vuole semplicemente utilizzare DHCP per la connessione Ethernet, si può usare dhcpcd@.service (fornito dal pacchetto dhcpcd. Per utilizzare DHCP per eth0, semplicemente usare:

# systemctl start dhcpcd@eth0.service

Si può attivare l'avvio automatico al boot con:

  1. systemctl enable dhcpcd@eth0.service

Alcune volte il servizio dhcpd si avvia prima del modulo della scheda di rete (FS#30235), aggiungere manualmente il modulo della propria scheda di rete a /etc/modules-load.d/****.conf. Esempio: creare /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 o 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 pagina dei servizi di systemd.

Integrazione con Arch

Emulazione degli initscripts

L'integrazione con la classica configurazione di Arch è garantita dal pacchetto initscripts. Questo è semplicemente inteso come una misura transitoria per facilitare il passaggio degli utenti a systemd.

Nota: /etc/inittab non è più usato.

Se ci si ritrova disabilitato Template:Keypress per riavviare, occorre riconfigurare questa opzione per systemd eseguendo systemctl mask ctrl-alt-del.target da root.

rc.conf

Alcune variabili in/etc/rc.conf sono supportate. Per una configurazione pura di systemd è raccomandato usare native systemd configuration files che hanno la precedenza su /etc/rc.conf.

Variabili supportate:

  • LOCALE
  • KEYMAP
  • CONSOLEFONT
  • CONSOLEMAP
  • HOSTNAME
  • DAEMONS

Variabili non supportate e configurazioni di systemd:

  • TIMEZONE: fare un link simbolico /etc/localtime al proprio file con le informazioni di zona manualmente.
  • HARDWARECLOCK: Vedere Orario di sistema.
  • USELVM: al suo posto usare lvm.service fornito da 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 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 /etc/rc.conf come mostrato in questa tabella:

Configurazione Files di configurazione Vecchia sezione /etc/rc.conf
Hostname /etc/hostname

/etc/hosts

NETWORKING
Console fonts and Keymap /etc/vconsole.conf LOCALIZATION
Locale /etc/locale.conf

/etc/locale.gen

LOCALIZATION
Time zone /etc/localtime LOCALIZATION
Hardware clock /etc/adjtime LOCALIZATION
Kernel modules /etc/modules-load.d/ HARDWARE

For questioni di compatibilità, la sezione DAEMONS in /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 /etc/rc.conf e attivare i servizi in systemd. Per ogni <service_name> nella sezione DAEMONS di /etc/rc.conf, digita:

# 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 questa tabella.

Se <nome_del_servizio>.service non esiste:

  • il file .service può non essere disponibile per systemd. In questo caso, è necessario mantenere rc.conf per avviare il servizio durante il boot.
  • systemd può aver assegnato al servizio un nome diverso, ad esempio cronie.service rimpiazza il lanciatore del demone crond e alsa-restore.service rimpiazza il lanciatore del demone alsa. Un altro importante esempio è il demone 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, dbus.service sarà attivato automaticamente dopo essere stato installato. Controllare la lista dei servizi e il loro stato d'uso con il comando systemctl.

Scrivere i files .service personalizzati

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 man systemd.service per una spiegazione più dettagliata.

  • 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.
  • 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= 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

Le unità in /etc/systemd/system/ hanno la precedenza su quelle in /usr/lib/systemd/system/. Per mantenere la propria versione di una unità (che non sarà distrutta dopo un aggiornamento), copiare la vecchia unità da /usr/lib/ a /etc/ e fare le proprie modifiche qui. In alternativa si può usare .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:

/etc/systemd/system/<service-name>.service
.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

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

# systemctl reenable <unit>
# systemctl restart <unit>
Suggerimento: Si può usare systemd-delta per vedere quali unità sono state sovrascritte e quali esattamente sono stae modificate.

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-systemdAUR da AUR.

FAQ

Per una lista aggiornata dei problemi conosciuti, vedere il TODO.

Template:FAQ

Template:FAQ


Template:FAQ

Template:FAQ e si permette l'esportazione di LANG in /etc/locale.conf

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ


Ottimizzazioni

systemd-analyze

Systemd fornisce una utilità chiamata 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 python2-dbus e python2-cairo per usarlo.

Per vedere quanto tempo ha impiegato il boot del kernel e dello userspace, semplicemente si usi:

$ systemd-analyze

Suggerimento: Se si aggiunge l'aggancio a timestamp al parametro HOOKS in /etc/mkinitcpio.conf e si ricostruisce l'initramfs, systemd-analyze mostrerà anche quanto tempo ha impiegato l'initramfs.

Per elencare le unità partite, ordinate a seconda del tempo che impiegano ad avviarsi:

$ systemd-analyze blame

Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a Bootchart:

$ systemd-analyze plot > plot.svg

Attivare bootchart assieme a systemd

E' possibile usare una versione di bootchart per visualizzare la sequenza di boot. 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 bootchart2AUR di AUR nasce con un non documentato service di systemd. Dopo aver installato bootchart2 fare:

  1. systemctl enable bootchart.service

Leggere la documentazione di bootchart per ulteriori dettagli sull'uso di questa versione di bootchart.

Tasti di scelta rapida della Shell

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 ~/.bashrc per semplificare le interazioni con systemd e per migliorare l'esperienza complessiva.

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

Diminuire l'output

Cambiare verbose in 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:

  1. 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 /home, sarebbe meglio permettere ai servizi che non dipendono dalla/home di avviarsi mentre la /home sarà controllata. Ciò può essere ottenuto aggiungendo le seguenti opzioni alla voce della propria partizione /home in fstab:

noauto,x-systemd.automount

Questo controllerà e monterà la /home quando ci sarà l'accesso per la prima volta, e il kernel memorizzerà tutti gli accessi ai file della /home finché non sarà pronta.

Se si utilizzano filesystems criptati con keyfiles, è possibile aggiungere il paramtero noauto alla corrispondente voce in /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:

/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:

  1. 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 polkit 0.107 (attualmente in [testing]), ConsoleKit può essere completamente rimpiazzato da systemd-logind. Tuttavia, non c'è attualmente nessun Display Manager nei repositories di Arch Linux che supporti nativamente systemd-logind senza dipendere ancora da ConsoleKit. Il più semplice metodo per rimuovere ConsoleKit è quello di loggarsi automaticamente a una console virtuale e 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 ck-launch-session dal proprio ~/.xinitrc.

Per controllare lo stato della propria sessione utente, si può utilizzare loginctl. Per vedere se la propria sessione utente è configurata appropriatamente, controllare se il seguente comando contiene Active=yes. Tutte le azioni di 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 --with-session-tracking=systemd nel PKGBUILD.

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.

SLiM in una sessione di xfce

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. Un modo per aggirare il problema è la modifica di slim.service:

/etc/systemd/system/slim.service
[Unit]
Description=SLiM Simple Login Manager
After=systemd-user-sessions.service

[Service]
Type=forking
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 /var/tmp è un link simbolico a /tmp, porta alcuni servizi a fallire la partenza quando sono avviati tramite systemd. In questo caso, lo stato del processo (tramite systemctl status <service>) sarà "226/NAMESPACE". Per superare questo blocco, semplicemente rimuovere il proprio link simbolico a /var/tmp e reinstallare il pacchetto filesystem.

Vedi anche