https://wiki.archlinux.org/api.php?action=feedcontributions&user=Dariondol&feedformat=atomArchWiki - User contributions [en]2024-03-19T05:58:51ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=293830Systemd (Italiano)2014-01-21T13:00:53Z<p>Dariondol: piccolo refuso</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[ar:Systemd]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
[[zh-TW:Systemd]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Tratta di come installare e configurare systemd}}<br />
{{Article summary heading|Articoli correlati}}<br />
{{Article summary wiki|systemd/User}} <br />
{{Article summary wiki|systemd/Services}}<br />
{{Article summary wiki|systemd/cron functionality}}<br />
{{Article summary wiki|systemd FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <br />
{{Article summary wiki|Improve Boot Performance (Italiano)}}<br />
{{Article summary end}}<br />
<br />
Dalla pagina web del [http://freedesktop.org/wiki/Software/systemd progetto]:<br />
'"'''systemd''' è un gestore di sistema e di servizi per Linux, compatibile con gli initscript SysV e LSB. '''systemd''' fornisce una notevole capacità di parallelizzazione, usa socket e [[D-Bus]] per l'avvio dei demoni, offre un avvio su richiesta dei demoni, tiene traccia dei processi con l'utilizzo del [[cgroups|control groups]] di Linux, supporta lo snapshotting e il restore dello stato del sistema, mantiene i punti di mount e di automount e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze.<br />
<br />
{{Nota|1=Per una dettagliata spiegazione del motivo per cui Arch è passato a systemd, leggi questo [https://bbs.archlinux.org/viewtopic.php?pid&#61;1149530#p1149530 post].}}<br />
<br />
== Uso base di systemctl ==<br />
<br />
Il principale comando usato per controllare systemd è {{ic|systemctl}}. Alcuni degli utilizzi possibili sono l'esame dello stato del sistema e la gestione del sistema e dei servizi. Vedere {{ic|man 1 systemctl}} per maggiori dettagli<br />
<br />
{{Suggerimento|Si può usare il seguente comando {{ic|systemctl}} con lo switch {{ic|-H <user>@<host>}} per controllare un'istanza di systemd su una macchina remota. Si userà [[SSH]] per connettersi all'istanza remota di systemd.}}<br />
<br />
{{Nota|{{ic|systemadm}} è il frontend grafico ufficiale per {{ic|systemctl}}. E' fornito dal pacchetto {{AUR|systemd-ui-git}} di [[AUR]].}}<br />
<br />
=== Analizzare lo stato del sistema ===<br />
<br />
Lista della unità attive:<br />
<br />
$ systemctl<br />
<br />
oppure:<br />
<br />
$ systemctl list-units<br />
<br />
Lista delle unità che hanno avuto problemi:<br />
<br />
$ systemctl --failed<br />
<br />
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:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Usare le unità ===<br />
<br />
Le unità possono essere, per esempio, servizi ({{ic|.service}}), punti di montaggio ({{ic|.mount}}), dispositivi ({{ic|.device}}) oppure i sockets ({{ic|.socket}}). <br />
<br />
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}}:<br />
<br />
* Se non si specifica il suffisso, per systemctl sarà sottointeso {{ic|.service}}. Per esempio, {{ic|netcfg}} e {{ic|netcfg.service}} sono equivalenti.<br />
* I punti di montaggio saranno automaticamente tradotti nella appropriata unità {{ic|.mount}}. Per esempio, specificare {{ic|/home}} è equivalente a {{ic|home.mount}}.<br />
* Come i punti di montaggio, anche i dispositivi sono automaticamente tradotti nell'appropriata unità {{ic|.device}}, quindi specificare {{ic|/dev/sda2}} è equivalente a {{ic|dev-sda2.device}}. <br />
Vedi {{ic|man systemd.unit}} per dettagli.<br />
<br />
Attivare immediatamente una unità:<br />
<br />
# systemctl start <unit><br />
<br />
Fermare immediatamente una unità:<br />
<br />
# systemctl stop <unit><br />
<br />
Far ripartire una unità:<br />
<br />
# systemctl restart <unit><br />
<br />
Chiedere ad una unità di ricaricare la sua configurazione:<br />
<br />
# systemctl reload <unit><br />
<br />
Mostrare lo stato di una unità, compreso se sta funzionando o no:<br />
<br />
$ systemctl status <unit><br />
<br />
Controllare se una unità è già attivata o no:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Attivare l'avvio automatico al boot:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Nota| I servizi senza una sezione {{ic|[Install]}}, sono solitamente evocati automaticamente da altri servizi. Ma se occorre installarli manualmente usare il seguente comando rimpiazzando {{ic|foo}} con il nome del servizio.<br />
<br />
# ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disattivare l'avvio automatico al boot:<br />
<br />
# systemctl disable <unit><br />
<br />
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):<br />
<br />
$ systemctl help <unit><br />
<br />
Ricaricare systemd, controllo per nuove o modificate unità:<br />
<br />
# systemctl daemon-reload<br />
<br />
=== Power management ===<br />
<br />
{{ic|polkit}} è indispensabile per la gestione energetica.<br />
Se ci si trova in una sessione locale di {{ic|systemd-logind}} e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), systemd automaticamente richiederà la password di root.<br />
<br />
Spegnimento e riavvio del sistema:<br />
<br />
$ systemctl reboot<br />
<br />
Spegnimento del sistema:<br />
<br />
$ systemctl poweroff<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
Stato ibrido di riposo (o suspend-to-both):<br />
<br />
$ systemctl hybrid-sleep<br />
<br />
== Avviare DM con systemd ==<br />
<br />
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]].<br />
<br />
# systemctl enable kdm<br />
<br />
Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio {{ic|graphical.target}}).<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
=== Usare systemd-logind ===<br />
<br />
{{Nota|Dal 30 Ottobre 2012, [[ConsoleKit]] è stato [https://www.archlinux.org/news/consolekit-replaced-by-logind/ rimpiazzato da systemd-logind] come meccanismo di default per autentificarsi nei DE.}}<br />
<br />
Per controllare lo stato della propria sessione utente, si può utilizzare {{ic|loginctl}}. Tutte le azioni di [[PolicyKit]] come la sospensione del sistema o il montaggio di dispositivi esterni funzioneranno automaticamente.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Configurazione nativa ==<br />
<br />
{{Nota|E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a {{ic|644}} e il proprietario {{ic|root:root}}}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file può contenere il nome del dominio di sistema, se esiste, tuttavia nel momento di scrivere {{ic|hostnamectl}} non si può configurare il FQDN. Per configurare l'hostname corto:<br />
<br />
# hostnamectl set-hostname '''myhostname'''<br />
<br />
See {{ic|man 5 hostname}} e {{ic|man 1 hostnamectl}} per dettagli.<br />
<br />
Esempio di file:<br />
{{hc|/etc/hostname|<br />
myhostname<br />
}}<br />
<br />
=== Impostazioni locali ===<br />
<br />
{{Note|Before you set the default locale, you first need to enable locales available to the system by uncommenting them in {{ic|/etc/locale.gen}} and then executing {{ic|locale-gen}} as root. The locale set via {{ic|localectl}} must be one of the '''uncommented''' locales in {{ic|/etc/locale.gen}}.}}<br />
Le impostazioni locali di default sono configurate in {{ic|/etc/locale.conf}} Per configurare il locale di default: <br />
<br />
# localectl set-locale LANG="it_IT.utf8"<br />
<br />
Vedere {{ic|man 1 localectl}} e {{ic|man 5 locale.conf}} per dettagli.<br />
<br />
Per ulteriori informazioni vedere [[Locale_(Italiano)|Locale]].<br />
<br />
Esempio di file: <br />
{{hc|/etc/locale.conf|<nowiki><br />
LANG=it_IT.utf8<br />
</nowiki>}}<br />
<br />
=== Console virtuale ===<br />
La console virtuale (la mappatura della tastiera, i caratteri della console e la mappatura della console) è configurata in {{ic|/etc/vconsole.conf}}:<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=it<br />
FONT=<br />
FONT_MAP=}}<br />
<br />
{{Nota|Da {{pkg|systemd}}-194, si utilizzano i caratteri integrati nel kernel e la mappatura della tastiera "us" se {{ic|1=KEYMAP=}} e {{ic|1=FONT=}} sono vuoti o non configurati.}}<br />
<br />
Un altro modo di configurare la mappatura della tastiera è:<br />
<br />
# localectl set-keymap it<br />
<br />
<code>localectl</code> può essere usato anche per configurare la tastiera in ambiente X:<br />
<br />
# localectl set-x11-keymap it<br />
<br />
Vedere {{ic|man 1 localectl}} e {{ic|man 5 vconsole.conf}} per maggiori dettagli.<br />
<br />
Per maggiori informazioni vedere [[Fonts_(Italiano)#Font_per_console|i font per console]] e [[KEYMAP|configurazione tastiera]].<br />
<br />
=== Orario di sistema ===<br />
<br />
Systemd usa '''UTC''' di default per l'orologio hardware.<br />
<br />
{{Suggerimento|E' generalmente consigliato avere [[NTP|il demone Network Time Protocol]] attivo per mantenere l'orologio di sistema sincronizzato con Internet e con l'orologio del bios.}}<br />
<br />
==== Orologio hardware in localtime ====<br />
<br />
Se si vuole cambiare l'orologio hardware ad usare l'orario locale ('''ALTAMENTE SCONSIGLIATO'''):<br />
<br />
# timedatectl set-local-rtc true<br />
<br />
Se si vuole riconvertirlo a UTC:<br />
<br />
# timedatectl set-local-rtc false<br />
<br />
Attenzione che, se l'orologio hardware è configurato a localtime, la gestione dell'orario legale è persa. Se l'orario legale cambia finché il computer è spento il proprio orario sarà sbagliato al prossimo riavvio ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ulteriori approfondimenti]). I kernel recenti configurano l'orario di sistema dall'orologio hardware direttamente al boot, presupponendo che l'orologio hardware sia impostato a UTC. Questo significa che se l'orologio hardware è su locale l'orologio di sistema sarà prima configurato sbagliato e poi corretto ad ogni boot. Questa è la causa di alcuni noiosi bugs (il tempo che torna indietro è raramente una buona cosa).<br />
<br />
Una ragione per permettere che l'orologio hardware sia settato sul'orario locale è quella del dual boot con Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx il quale usa localtime]). Tuttavia, Windows è in grado di gestire l'orario con l'orologio hardware settato su UTC con un semplice [[Time#UTC in Windows|aggiustamento del registro di sistema]]. Quindi, è consigliato configurare Windows affinché usi UTC, piuttosto che Linux usi localtime. Se si usa UTC su Windows, ricordarsi inoltre di disabilitare l'opzione di Windows "Internet Time Update", al fine di evitare confusione tra windows e l'orologio hardware, nel tentativo di sincronizzazione con l'orario internet. Al contrario, occorre lasciare che Linux sincronizzi l'orario di sistema con l'orario internet attivando il demone [[NTP]], come suggerito precedentemente.<br />
<br />
* Per maggiori informazioni vedere [[Time]].<br />
<br />
=== Moduli del Kernel ===<br />
<br />
Ad oggi, tutti i moduli necessari da caricare sono gestiti automaticamente da [[udev]], cosicché, se non si vuole usare qualcuno dei moduli fuori dal kernel, non c'è bisogno di mettere i moduli che dovrebbero essere caricati al boot in nessun file di configurazione. Tuttavia, ci sono casi in cui si vuole caricare un modulo extra durante il processo di avvio oppure evitare il caricamento di un altro perché il computer funzioni correttamente.<br />
<br />
==== Moduli extra da caricare all'avvio ====<br />
<br />
I moduli extra al kernel da caricare durante il boot sono configurati in una lista statica in {{ic|/etc/modules-load.d/}}. Ogni file di configurazione ha il nome nello stile di {{ic|/etc/modules-load.d/<programma>.conf/}}. I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO. Le linee vuote o quelle dove il primo carattere che non è uno spazio è # oppure ; sono ignorate. Ad esempio:<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Carica virtio-net.ko al boot<br />
virtio-net}}<br />
<br />
vedere {{ic|man 5 modules-load.d}} per maggiori dettagli.<br />
<br />
==== Configurare le opzioni dei moduli ====<br />
<br />
Ulteriori opzioni per i moduli devono essere impostati in {{ic|/etc/modprobe.d/modprobe.conf}}.<br />
<br />
Esempio:<br />
<br />
* Abbiamo il file {{ic|/etc/modules-load.d/loop.conf}} con all'interno il modulo {{ic|loop}} da far caricare durante la fase di boot.<br />
<br />
* in {{ic|/etc/modprobe.d/modprobe.conf}} specifichiamo le opzioni addizionali, es. {{ic|options loop max_loop&#61;64}}<br />
<br />
In seguito, l'opzione appena impostato potrebbe essere verificata tramite {{ic|cat /sys/module/loop/parameters/max_loop}}<br />
<br />
==== Blacklisting ====<br />
<br />
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.<br />
<br />
=== Montaggio del filesystem ===<br />
<br />
La configurazione di default controlla e monta i filesystems prima di avviare i servizi ai quali occorre che siano montati. Per esempio, systemd automaticamente si assicura che il montaggio di filesystems come [[NFS]] o [[Samba]] avvenga solo dopo che la rete è attiva. Pertanto, il montaggio dei filesystems, sia locali che remoti, specificati in {{ic|/etc/fstab}} dovrebbe funzionare senza problemi.<br />
<br />
Vedere {{ic|man 5 systemd.mount}} per dettagli.<br />
<br />
==== Automount ====<br />
<br />
* Se si possiede una grande partizione {{ic|/home}}, sarebbe meglio permettere ai servizi che non dipendono da essa di avviarsi durante il controllo di {{ic|/home}} da parte di fsck. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in {{ic|/etc/fstab}}:<br />
<br />
noauto,x-systemd.automount<br />
<br />
Questo controllerà e monterà {{ic|/home}} al primo accesso, e il kernel memorizzerà in un buffer tutti gli accessi ai file in {{ic|/home}} finché non sarà pronta.<br />
<br />
Nota: questo renderà il filesystem {{ic|/home}} di tipo {{ic|autofs}}, che è ignorato da [[mlocate]] di default. La velocità di montaggio automatico di {{ic|/home}} non può essere maggiore di un secondo o due, a seconda del proprio sistema, quindi è possibile che non valga la pena di utilizzare questo trucco. <br />
<br />
* Lo stesso si può applicare al montaggio dei filesystems remoti. Se si desidera montarli successivamente all'accesso occorrerà usare i parametri {{ic|noauto,x-systemd.automount}}. In aggiunta, si può usare l'opzione {{ic|1=x-systemd.device-timeout=#}} per specificare un tempo di timeout in caso la risorsa di rete non sia disponibile.<br />
<br />
* Se si hanno filesystems criptati con keyfiles, si può comunque aggiungere il parametro {{ic|noauto}} alla corrispondente riga in {{ic|/etc/crypttab}}. Systemd non aprirà il supporto corispondente all'avvio, ma aspetterà finché non avverrà un accesso e quindi automaticamente aprirà il keyfile specifico prima di montarlo. Questo potrebbe far risparmiare un po' di secondi al boot se si sta per esempio utilizzando un supporto RAID criptato, in quanto systemd non deve aspettare finché il dispositivo non sarà disponibile. Per esempio:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
==== LVM ====<br />
<br />
Se si possiede un volume [[LVM]] non attivato durante [[Mkinitcpio|l'initramfs]], attivare il servizio {{ic|lvm-monitoring}} fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-monitoring.service<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di {{ic|/etc/systemd/logind.conf}}:<br />
<br />
* {{ic|HandlePowerKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio<br />
* {{ic|HandleSuspendKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione<br />
* {{ic|HandleHibernateKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione<br />
* {{ic|HandleLidSwitch}} : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.<br />
<br />
Le azioni specificate possono essere una qualsiasi di {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}} o {{ic|kexec}}.<br />
<br />
Se queste opzioni non sono configurate, systemd userà quelle di default: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
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.<br />
<br />
{{Nota|Digitare {{ic|systemctl restart systemd-logind.service}} perchè le modifiche abbiano effetto.}}<br />
<br />
{{Nota|Systemd non riesce a gestire gli eventi di alimentazione di rete e di batteria, sicché è ancora richiesto l'uso di [[Laptop Mode Tools]] o altri strumenti [[acpid]] similari.}}<br />
<br />
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.<br />
<br />
{{Attenzione|Attualmente, i gestori di alimentazione delle versioni più recenti di [[KDE]] e [[GNOME]] sono gli unici che possiedono i necessari comandi inibitori. Quando li avranno anche gli altri, occorrerà settare l'opzione {{ic|Handle}} a {{ic|ignore}} se si voglio gestire gli eventi ACPI con [[Xfce]], [[acpid]] o qualsiasi altro programma.}}<br />
<br />
{{Nota|Systemd può anche usare altri backends per la sospensione (come [[Uswsusp]] o [[TuxOnIce]]), in aggiunta al backend di default del ''kernel'', al fine di mettere il computer in uno stato di sleep o ibernazione.}}<br />
<br />
For {{ic|systemctl hibernate}} to work on your system you need to follow instructions at [[Pm-utils#Hibernation_.28suspend2disk.29|Hibernation]] and possibly at [[Pm-utils#Mkinitcpio_Resume_Hook|Mkinitcpio Resume Hook]] ({{ic|pm-utils}} does not need to be installed). <br />
<br />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}}, {{ic|systemctl hibernate}} oppure {{ic|systemctl hybrid-sleep}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce due meccanismi simili per avviare script personali in base a questi eventi. <br />
<br />
===== Suspend/resume service files =====<br />
<br />
Dei service files possono essere agganciati a suspend.target, hibernate.target e sleep.target per eseguire azioni prima o dopo la sospensione lo l'ibernazione. Files separati dovrebbero essere creati per azioni degli utenti e azioni di sistema (root). Per attivare i servizi degli utenti, {{ic|# systemctl enable suspend@<user> && systemctl enable resume@<user>}}. Esempi:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki><br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'<br />
ExecStart=/usr/bin/sflock<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<nowiki><br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStartPre=/usr/local/bin/ssh-connect.sh<br />
ExecStart=/usr/bin/mysql -e 'slave start'<br />
<br />
[Install]<br />
WantedBy=suspend.target</nowiki>}}<br />
<br />
Per azioni di sistema o root (attivare con {{ic|# systemctl enable root-suspend}}):<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki><br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki><br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
Un paio di consigli a proposito di questi servizi (maggiori informazioni in {{ic|man systemd.service}}):<br />
* Se si usa {{ic|1=<nowiki>Type=OneShot</nowiki>}} si possono usare linee {{ic|1=<nowiki>ExecStart=</nowiki>}} multiple. Altrimenti solo una linea ExecStart è permessa. Si possono aggiungere più comandi con {{ic|ExecStartPre}} oppure separandoli con un punto e virgola (vedere il primo esempio più su -- notare gli spazi prima e dopo il punto e virgola... sono indispensabili!).<br />
* Un comando preceduto da '-' causerà una uscita con stato non-zero per essere ignorato e trattato come un comando successivo. <br />
* Il miglior modo per trovare gli errori in questi servizi è naturalmente con {{ic|journalctl}}.<br />
<br />
===== Servizi combinati di Suspend/resume =====<br />
<br />
Con il servizio combinato suspend/resume, un singolo collegamento fa tutto il lavoro per le varie fasi (sleep/resume) e per i differenti targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Esempi e spiegazioni:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki><br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target</nowiki>}}<br />
<br />
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: Dopo averlo avviato, il servizio è considerato attivo fino a quando non è esplicitamente fermato.<br />
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: Quando è attivo, il servizio sarà fermato se nessun altro servizio necessita di esso. Nell'esempio specifico, sarà fermato dopo che sleep.target sarà fermato.<br />
* Perché sleep.target venga richiamato da suspend.target, hibernate.target e hybrid-sleep.target e sleep.target esso stesso è un StopWhenUnneeded service, il collegamento garantisce l'avvio e la fermata corretta per diversi compiti.<br />
<br />
===== Hooks in /usr/lib/systemd/system-sleep =====<br />
<br />
Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} oppure {{ic|hybrid-sleep}}, dipende da quello che è stato invocato.<br />
<br />
Al contrario di [[Pm-utils_(Italiano)|Pm-utils]], systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.<br />
<br />
L'output di ogni script personalizzato sarà registrato da {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}} oppure {{ic|systemd-hybrid-sleep.service}} cosicché sarà possibile vedere i propri outputs nel [[Systemd_(Italiano)#Il Journal|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}}, {{ic|hibernate.target}} oppure {{ic|hybrid-sleep.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts personalizzati.<br />
<br />
Un esempio di script personalizzato:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
<br />
;;<br />
post/* )<br />
echo "Waking up from $2..."<br />
;;<br />
esac}}<br />
<br />
Non dimenticare di rendere lo script eseguibile:<br />
+ <br />
# chmod a+x /usr/lib/systemd/system-sleep/example.sh<br />
<br />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== File temporanei ===<br />
<br />
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.<br />
<br />
I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esmpio il demone [[Samba]] si aspetta che esista la cartella {{ic|/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /run/samba 0755 root root}}<br />
<br />
I tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa {{ic|/etc/rc.local}} per disabilitare il risveglio del sistema attraverso dispositivi USB con {{ic|echo USBE > /proc/acpi/wakeup}}, si può usare in alternativa il seguente tmpfile:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<br />
{{nota|Questo metodo potrebbe non funzionare per impostare le opzioni in {{ic|/sys}} poiché il servizio {{ic|systemd-tmpfiles-setup}} può eseguirsi prima che i moduli delle periferiche appropriate siano caricati. In questo caso si potrebbe verificare che il modulo abbia un parametro per l'opzione che si desidera impostare con {{ic|modinfo <module>}} e impostare questa opzione con un [[Modprobe.d#Configuration|file di configurazione in {{ic|/etc/modprobe.d}}]]. In caso contrario si dovrà scrivere una [[Udev#About_udev_rules| regola udev]] per impostare l' attributo appropriato non appena viene visualizzato il dispositivo.}}<br />
<br />
=== Unità ===<br />
<br />
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. <br />
<br />
Vedi {{ic|man 5 systemd.unit}} per maggiori informazioni.<br />
<br />
<br />
<br />
==Scrivere i files .service personalizzati==<br />
''Vedere: [[Systemd/Services]]''<br />
<br />
===Gestire le dipendenze===<br />
<br />
Con systemd le dipendenze possono essere risolte progettando le unità correttamente.<br />
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. <br />
<br />
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.<br />
<br />
===Type===<br />
<br />
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.<br />
<br />
* {{ic|1=Type=simple}}(default): systemd presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.<br />
* {{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.<br />
* {{ic|1=Type=oneshot}}: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con {{ic|1=RemainAfterExit=yes}} in modo che systemd consideri il servizio ancora attivo anche dopo che il processo si è concluso.<br />
* {{ic|1=Type=notify}}: Identico a {{ic|1=Type=simple}}, ma con l'accorgimento che il demone invierà un segnale a systemd quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da {{ic|libsystemd-daemon.so}}.<br />
* {{ic|1=Type=dbus}}: Il servizio è considerato pronto quando lo specificato {{ic|BusName}} appare nel sistema di bus si DBus.<br />
<br />
===Rimpiazzare le unità fornite===<br />
<br />
Per editare il file unit fornito da un pacchetto, si può creare una cartella chiamata {{ic|/etc/systemd/system/<unit>.d/}} per esempio {{ic|/etc/systemd/system/httpd.service.d/}} e mettere i files {{ic|*.conf}} in essa per sovrascrivere e aggiungere nuove opzioni. Systemd controllerà questi files {{ic|*.conf}} e li applicherà al di sopra degli originali. Per esempio, se si vuole semplicemente aggiungere un dipendenza all'unità si può creare il seguente file:<br />
<br />
{{hc|/etc/systemd/system/<unit>.d/customdependency.conf|2=<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:<br />
<br />
# systemctl daemon-reload<br />
# systemctl restart <unit><br />
<br />
In alternativa si può copiare la vecchia unità da {{ic|/usr/lib/systemd/system/}} in {{ic|/etc/systemd/system/}} e fare qui le modifiche. Una unità in {{ic|/etc/systemd/system/}} sovrascriverà sempre la stessa unità in {{ic|/usr/lib/systemd/system/}}. Da notare che quando l'unità originale in {{ic|/usr/lib/}} cambia a causa di un aggiornamento, le modifiche non si rifletteranno automaticamente sulla propria unità personalizzata in {{ic|/etc/}}. In aggiunta occorre riattivarla manualmente con {{ic|systemctl reenable <unit>}}. E' raccomandato usare il metodo con il {{ic|*.conf}} descritto sopra.<br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}} Siccome le unità saranno aggiornate di volta in volta , usare systemd-delta per la manutenzione del sistema.<br />
<br />
===Evidenziazione della sintassi per le unità di systemd con Vim===<br />
<br />
L'evidenziazione della sintassi per le unità di systemd con [[Vim]] può essere attivata installando {{Pkg|vim-systemd}} dal [[Official Repositories|repo ufficiale]].<br />
<br />
== Targets ==<br />
<br />
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}}.<br />
<br />
=== Conoscere il target attuale ===<br />
<br />
Il seguente comando dovrebbe essere usato sotto systemd al posto di {{ic|runlevel}}:<br />
$ systemctl list-units --type=target<br />
<br />
=== Creare un target personalizzato ===<br />
<br />
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.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
!SysV Runlevel!!systemd Target!!Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Ferma il sistema.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Modalità utente singolo (single user).<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definita dall'utente. Preconfigurata a 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, grafica. Solitamente ha tutti i servizi del runlevel 3 con l'aggiunta di un login grafico.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Riavvio<br />
|-<br />
| emergency || emergency.target || Console di emergenza<br />
|-<br />
|}<br />
<br />
=== Cambiare il target corrente ===<br />
<br />
In systemd i targets sono esplicitati per mezzo di "target units". Si possono cambiare così:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
Questo comando cambierà solamente il target corrente e non avrà nessun effetto sul prossimo avvio. Questo è equivalente ai comandi {{ic|telinit 3}} oppure {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Cambiare il target predefinito all'avvio ===<br />
<br />
Il target standard è {{ic|default.target}}, che è abbinato in modo predefinito a {{ic|graphical.target}} (che corrisponde al vecchio runlevel 5). Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:<br />
<br />
{{Suggerimento|L'estensione {{ic|.target}} può essere tralasciata.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (che corrisponde al vecchio runevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (che corrisponde al vecchio runevel 1).<br />
<br />
In alternativa si può lasciare il bootloader inalterato e cambiare {{ic|default.target}}. Ciò può essere fatto usando {{ic|systemctl}}:<br />
<br />
# systemctl enable multi-user.target<br />
<br />
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:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
si trova nel file di configurazione del target. Attualmente, sia {{ic|multi-user.target}} che {{ic|graphical.target}} lo possiedono.<br />
<br />
== Timers ==<br />
<br />
Systemd can replace cron functionality to a great extent. For further information, please refer to [[systemd/cron functionality]].<br />
<br />
== Il Journal ==<br />
<br />
Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal. Tuttavia, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:<br />
<br />
# journalctl<br />
<br />
Di default (quando {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. La directory {{ic|/var/log/journal/}} è parte di core/systemd. Se si è cancellata intenzionalmente o se qualche programma lo ha fatto systemd '''non''' lo riicreerà automaticamente, tuttavia sarà ricreata durante il prossimo aggiornamento di systemd. Fino a quel momento i log saranno scritti in {{ic|/run/systemd/journal}}. Ciò significa che i log saranno persi al riavvio.<br />
<br />
=== Filtrare l' output ===<br />
<br />
{{ic|journalctl}} permette di filtrare l'output secondo specifici campi.<br />
<br />
Esempi:<br />
<br />
Mostrare tutti i messaggi di questo boot:<br />
<br />
# journalctl -b<br />
<br />
Tuttavia, spesso un utente può essere interessato ai messaggi non del corrente boot, ma del precedente (per esempio a causa di un non recuperabile blocco occorso). Attualmente, questa opzione non è implementata, ma esiste una discussione a [http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] (Settembre/Ottobre 2012).<br />
<br />
Come workaround al momento si può usare:<br />
<br />
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac<br />
<br />
,che provoca che il precedente boot sia come scaturito oggi. Tenere presente che, se ci sono molti messaggi per il giorno corrente, l'output di questo comando può essere ritardato per un bel po 'di tempo.<br />
<br />
Seguire i nuovi messaggi:<br />
<br />
# journalctl -f<br />
<br />
Mostrare tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostrare tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostrare tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedere {{ic|man journalctl}} e {{ic|systemd.journal-fields}} oppure il [http://0pointer.de/blog/projects/journalctl.html blog] di Lennert per dettagli.<br />
<br />
=== Limiti alla dimensione del journal ===<br />
<br />
Se il journal è persistente (non volatile) la sua dimensione è fissata al 10% della dimensione del rispettivo file system. Per esempio con {{ic|/var/log/journal}} allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal. La dimensione massima del journal persistente può essere controllata attraverso {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:<br />
<br />
SystemMaxUse=50M<br />
<br />
Fare riferimento a {{ic|man journald.conf}} per maggiori dettagli.<br />
<br />
=== Journald coesistente con syslog ===<br />
<br />
La compatibilità con il classico syslog è fornita dal socket {{ic|/run/systemd/journal/syslog}}, attraverso il quale passano tutti i messaggi.<br />
Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). Il pacchetto {{pkg|syslog-ng}} dei repo ufficiali automaticamente fornisce la necessaria configurazione.<br />
<br />
# systemctl enable syslog-ng<br />
Una buona guida a {{ic|journalctl}} è [http://0pointer.de/blog/projects/journalctl.html| qui].<br />
<br />
== Migration from SysVinit/initscripts ==<br />
{{Deletion|Arch's initscripts has been officially unsupported since 2012-11-04[https://www.archlinux.org/news/end-of-initscripts-support/].}}<br />
{{Note|<br />
* {{Pkg|systemd}} and {{Pkg|systemd-sysvcompat}} are both installed by default on installation media newer than [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13]. This section is aimed at Arch Linux installations that still rely on ''sysvinit'' and ''initscripts''.<br />
* If you are running Arch Linux inside a VPS, please see [[Virtual Private Server#Moving your VPS from initscripts to systemd]].<br />
}}<br />
<br />
=== Considerazioni prima di passare a systemd ===<br />
<br />
* [http://freedesktop.org/wiki/Software/systemd/ Documentarsi] su systemd.<br />
* Notare che systemd possiede un sistema '''journal''' che rimpiazza '''syslog''', tuttavia i due possono coesistere. Vedi [[#Il_Journal|la sezione relativa al journal]] più sotto.<br />
* 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.<br />
* Gli scripts interattivi non funzionano in systemd. In particolare, '''netcfg-menu''' non può essere usato all'avvio del sistema ({{bug|31377}}).<br />
<br />
===Procedura di installazione===<br />
<br />
{{Nota|{{pkg|systemd}} e {{pkg|systemd-sysvcompat}} sono entrambi utilizzati di default nei recenti media di installazione dal [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 13 Ottobre 2012].}}<br />
<br />
{{Nota|Se si sta utilizzando Arch Linux in un VPS, vedere [[Virtual_Private_Server#Moving_your_VPS_from_initscripts_to_systemd la pagina appropriata]].}}<br />
<br />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{AUR|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando ai [[kernel line|parametri del kernel]] nel bootloader: {{ic|1=init=/usr/lib/systemd/systemd}}<br />
# Una volta fatto è possibile abilitare qualsiasi servizio si desideri per mezzo di {{ic|systemctl enable <service_name>}} (pari a ciò che si trova nella sezione {{ic|DAEMONS}}. Nuovi nomi possono essere trovati [[Daemons_List|qui]]. ).<br />
# Riavviare il proprio sistema e verificare che {{ic|systemd}} sia attivo utilizzando il seguente comando: {{ic|cat /proc/1/comm}}. Questo dovrebbe rispondere con la stringa {{ic|systemd}}.<br />
# Assicurarsi che il proprio hostname sia configurato correttamente in systemd: {{ic|hostnamectl set-hostname myhostname}}.<br />
# Procedere rimuovendo {{pkg|initscripts}} e {{AUR|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# A scelta, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario. {{pkg|systemd-sysvcompat}} lo imposta come default.<br />
<br />
=== Informazioni supplementari ===<br />
<br />
*Se si utilizza {{ic|quiet}} nei parametri del kernel, è possibile rimuoverlo durante i primi avvii di systemd per identificare eventuali problemi durante il boot.<br />
* Aggiungere il vostro utente ai [[Users and Groups (Italiano)|gruppi]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) '''non''' è necessario per la maggior parte dei casi di uso comune con systemd. I gruppi possono anche causare alcuni malfunzionamenti. Ad esempio, il gruppo {{ic|audio}} si romperà al cambio rapido di utente e permette di bloccare le applicazioni software di mixaggio. Ogni login di PAM prevede una sessione logind , che per una sessione locale vi darà i permessi tramite le [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e consentirà alcune operazioni come il montaggio di memorizzazione rimovibile tramite [[udisks]]<br />
* Si veda l'articolo [[Configurazione della Rete]] per come impostare i target per la connessione di rete.<br />
<br />
== Correzione di errori ==<br />
<br />
=== Lo spegnimento e il riavvio sono terribilmente lunghi ===<br />
<br />
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.<br />
Per vedere se si soffre di questo problema vedere [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually questo articolo].<br />
<br />
=== I processi di breve durata non registrano nessun output ===<br />
<br />
Se {{ic|journalctl -u foounit.service}} non mostra nessun output per un processo di breve durata, controllare il PID. Per esempio, se systemd-modules-load.service fallisce, e {{ic|systemctl status systemd-modules-load}} evidenzia che è eseguito con PID 123, è possibile vedere l'output del journal per quel PID, per esempio {{ic|journalctl -b _PID&#61;123}}. I campi con metadata del journal come _SYSTEMD_UNIT e _COMM sono raccolti in modo asincrono e fanno affidamento sulla cartella {{ic|/proc}} per il processo esistente. La sistemazione di questo richiede una sistemazione del kernel per fornire questi dati per mezzo di una connessione socket, come per SCM_CREDENTIALS.<br />
<br />
=== Diagnosi dei problemi al Boot ===<br />
<br />
Avviare il sistema con questi parametri sulla linea di comando del kernel:<br />
<br />
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}<br />
<br />
[http://freedesktop.org/wiki/Software/systemd/Debugging Maggiori informazioni sul Debugging]<br />
<br />
== Vedi anche==<br />
<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Sito ufficiale]<br />
*[http://0pointer.de/public/systemd-man/ Pagine di manuale]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Trucchi e suggerimenti]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd per amministratori (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd Systemd su Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Come correggere i problemi di systemd]<br />
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] articolo introduttivo nella rivista ''The H Open''.<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]<br />
*[http://0pointer.de/blog/projects/why.html most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]</div>Dariondol