https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ambro&feedformat=atomArchWiki - User contributions [en]2024-03-19T07:45:52ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=276337Systemd (Italiano)2013-09-22T10:12:51Z<p>Ambro: </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 />
== Migration from SysVinit/initscripts ==<br />
<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 />
<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 {{pkg|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 {{pkg|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 />
== 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 monatggio ({{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. Me 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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Improving_performance_(Italiano)/Boot_process_(Italiano)&diff=276335Improving performance (Italiano)/Boot process (Italiano)2013-09-22T10:11:47Z<p>Ambro: Creata da parte di systemd</p>
<hr />
<div>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}<br />
<br />
{{DISPLAYTITLE:Incrementare la velocità di boot (Italiano)}}<br />
[[Category:Boot process]]<br />
[[ar:Improve Boot Performance]]<br />
[[cs:Improve Boot Performance]]<br />
[[es:Improve Boot Performance]]<br />
[[ja:Improve Boot Performance]]<br />
[[ru:Improve Boot Performance]]<br />
[[zh-CN:Improve Boot Performance]]<br />
{{Article summary start}}<br />
{{Article summary text|Questo articolo prova ad aggregare vari metodi per migliorare i tempi di boot di un sistema Arch Linux.}}<br />
{{Article summary end}}<br />
<br />
Incrementare la velocità di boot di un sistema riduce i tempi di attesa e significa conoscere meglio come certi files di sistema e scripts interagiscono gli uni con gli altri. Questo articolo prova ad aggregare vari metodi per migliorare i tempi di boot di un sistema Arch Linux.<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Compiling a custom kernel ==<br />
<br />
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel]].<br />
<br />
== Early start for services ==<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
== Staggered spin-up ==<br />
<br />
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:<br />
<br />
$ dmesg | grep SSS<br />
<br />
If it wasn't used during boot, there will be no output.<br />
<br />
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].<br />
<br />
== Filesystem mounts ==<br />
<br />
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings. Alternatively, one could try to mask that unit.<br />
<br />
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed. You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}. Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}<br />
<br />
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.<br />
<br />
Other filesystems like {{ic|/home}} can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.<br />
<br />
{{Note|this will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
== Initramfs ==<br />
<br />
As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem. Falconindy (Dave Reisner) has begrudgingly created a [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.<br />
{{Note|If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with {{ic|/dev/disk/by-label}}), trying to strip down your initramfs will not be a worthwhile endeavor.}}<br />
<br />
== Less output during boot ==<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
== See also ==<br />
<br />
* [[systemd]]<br />
* [[e4rat]]<br />
* [[udev]]<br />
* [[Daemon]]<br />
* [[mkinitcpio]]<br />
* [[Maximizing Performance]]<br />
* [[Bootchart]] - Tool to assist in profiling the boot process<br />
* [[Kexec]] - Tool to reboot very quickly without waiting for the whole BIOS boot process to finish.</div>Ambrohttps://wiki.archlinux.org/index.php?title=Improving_performance/Boot_process&diff=276332Improving performance/Boot process2013-09-22T10:05:56Z<p>Ambro: </p>
<hr />
<div>[[Category:Boot process]]<br />
[[ar:Improve Boot Performance]]<br />
[[cs:Improve Boot Performance]]<br />
[[es:Improve Boot Performance]]<br />
[[ja:Improve Boot Performance]]<br />
[[it:Improve Boot Performance]]<br />
[[ru:Improve Boot Performance]]<br />
[[zh-CN:Improve Boot Performance]]<br />
{{Article summary start}}<br />
{{Article summary text|This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.}}<br />
{{Article summary end}}<br />
<br />
Improving the boot performance of a system can provide reduced boot wait times and a means to learn more about how certain system files and scripts interact with one another. This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.<br />
<br />
== Analyzing the boot process ==<br />
<br />
=== Using systemd-analyze ===<br />
<br />
'''systemd''' provides a tool called {{ic|systemd-analyze}} that can be used to show timing details about the boot process, including an svg plot showing units waiting for their dependencies. You can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly.<br />
<br />
To see how much time was spent in kernelspace and userspace on boot, simply use:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|If you boot via [[UEFI]] and use a boot loader which implements systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (which currently only [[Gummiboot]] does), '''systemd-analyze''' can additionally show you how much time was spent in the EFI firmware and the boot loader itself.}}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
<br />
$ systemd-analyze blame<br />
<br />
At some points of the boot process, things can not proceed until a given unit succeeds. To see which units find themselves at these critical points in the startup chain, do:<br />
<br />
$ systemd-analyze critical-chain<br />
<br />
You can also create a SVG file which describes your boot process graphically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
See {{ic|man systemd-analyze}} for details.<br />
<br />
=== Using systemd-bootchart ===<br />
<br />
Bootchart has been merged into '''systemd''' since Oct. 2012, and you can use it to boot just as you would with the original bootchart. Add this to your kernel line:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
=== Using bootchart2 ===<br />
<br />
You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2-git}} package from [[AUR]] comes with an undocumented '''systemd''' service. After you've installed bootchart2 do:<br />
<br />
# systemctl enable bootchart<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
== Readahead ==<br />
<br />
[[Systemd]] comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
== Compiling a custom kernel ==<br />
<br />
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel]].<br />
<br />
== Early start for services ==<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
== Staggered spin-up ==<br />
<br />
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:<br />
<br />
$ dmesg | grep SSS<br />
<br />
If it wasn't used during boot, there will be no output.<br />
<br />
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].<br />
<br />
== Filesystem mounts ==<br />
<br />
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings. Alternatively, one could try to mask that unit.<br />
<br />
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed. You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}. Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}<br />
<br />
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.<br />
<br />
Other filesystems like {{ic|/home}} can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.<br />
<br />
{{Note|this will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
== Initramfs ==<br />
<br />
As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem. Falconindy (Dave Reisner) has begrudgingly created a [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.<br />
{{Note|If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with {{ic|/dev/disk/by-label}}), trying to strip down your initramfs will not be a worthwhile endeavor.}}<br />
<br />
== Less output during boot ==<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
== See also ==<br />
<br />
* [[systemd]]<br />
* [[e4rat]]<br />
* [[udev]]<br />
* [[Daemon]]<br />
* [[mkinitcpio]]<br />
* [[Maximizing Performance]]<br />
* [[Bootchart]] - Tool to assist in profiling the boot process<br />
* [[Kexec]] - Tool to reboot very quickly without waiting for the whole BIOS boot process to finish.</div>Ambrohttps://wiki.archlinux.org/index.php?title=Incrementare_la_velocit%C3%A0_di_boot_(Italiano)&diff=276329Incrementare la velocità di boot (Italiano)2013-09-22T10:02:34Z<p>Ambro: </p>
<hr />
<div>[[Category:Boot process]]<br />
[[ar:Improve Boot Performance]]<br />
[[cs:Improve Boot Performance]]<br />
[[es:Improve Boot Performance]]<br />
[[ja:Improve Boot Performance]]<br />
[[ru:Improve Boot Performance]]<br />
[[zh-CN:Improve Boot Performance]]<br />
{{Article summary start}}<br />
{{Article summary text|Questo articolo prova ad aggregare vari metodi per migliorare i tempi di boot di un sistema Arch Linux.}}<br />
{{Article summary end}}<br />
<br />
{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}<br />
<br />
Incrementare la velocità di boot di un sistema riduce i tempi di attesa e significa conoscere meglio come certi files di sistema e scripts interagiscono gli uni con gli altri. Questo articolo prova ad aggregare vari metodi per migliorare i tempi di boot di un sistema Arch Linux.<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Compiling a custom kernel ==<br />
<br />
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel]].<br />
<br />
== Early start for services ==<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
== Staggered spin-up ==<br />
<br />
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:<br />
<br />
$ dmesg | grep SSS<br />
<br />
If it wasn't used during boot, there will be no output.<br />
<br />
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].<br />
<br />
== Filesystem mounts ==<br />
<br />
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings. Alternatively, one could try to mask that unit.<br />
<br />
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed. You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}. Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}<br />
<br />
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.<br />
<br />
Other filesystems like {{ic|/home}} can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.<br />
<br />
{{Note|this will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
== Initramfs ==<br />
<br />
As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem. Falconindy (Dave Reisner) has begrudgingly created a [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.<br />
{{Note|If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with {{ic|/dev/disk/by-label}}), trying to strip down your initramfs will not be a worthwhile endeavor.}}<br />
<br />
== Less output during boot ==<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
== See also ==<br />
<br />
* [[systemd]]<br />
* [[e4rat]]<br />
* [[udev]]<br />
* [[Daemon]]<br />
* [[mkinitcpio]]<br />
* [[Maximizing Performance]]<br />
* [[Bootchart]] - Tool to assist in profiling the boot process<br />
* [[Kexec]] - Tool to reboot very quickly without waiting for the whole BIOS boot process to finish.</div>Ambrohttps://wiki.archlinux.org/index.php?title=Incrementare_la_velocit%C3%A0_di_boot_(Italiano)&diff=276328Incrementare la velocità di boot (Italiano)2013-09-22T10:01:25Z<p>Ambro: Creazione pagina collegata in precedenza con systemd</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ar:Improve Boot Performance]]<br />
[[cs:Improve Boot Performance]]<br />
[[es:Improve Boot Performance]]<br />
[[ja:Improve Boot Performance]]<br />
[[ru:Improve Boot Performance]]<br />
[[zh-CN:Improve Boot Performance]]<br />
{{Article summary start}}<br />
{{Article summary text|This article attempts to aggregate methods on how to improve the boot performance of an Arch Linux system.}}<br />
{{Article summary end}}<br />
<br />
{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}<br />
<br />
Incrementare la velocità di boot di un sistema riduce i tempi di attesa e significa conoscere meglio come certi files di sistema e scripts interagiscono gli uni con gli altri. Questo articolo prova ad aggregare vari metodi per migliorare i tempi di boot di un sistema Arch Linux.<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Compiling a custom kernel ==<br />
<br />
Compiling a custom kernel can reduce boot time and memory usage. Though with the standardization of the 64 bit architecture and the modular nature of the Linux kernel, these benefits may not be as great as expected. [[Kernel Compilation|Read more about compiling a kernel]].<br />
<br />
== Early start for services ==<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
== Staggered spin-up ==<br />
<br />
Some hardware implements [[Wikipedia:Spin-up#Staggered spin-up|staggered spin-up]], which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used:<br />
<br />
$ dmesg | grep SSS<br />
<br />
If it wasn't used during boot, there will be no output.<br />
<br />
To disable it, add {{ic|1=libahci.ignore_sss=1}} to the [[kernel line]].<br />
<br />
== Filesystem mounts ==<br />
<br />
Thanks to [[mkinitcpio]]'s {{ic|fsck}} hook, you can avoid a possibly costly remount of the root partition by changing {{ic|ro}} to {{ic|rw}} on the kernel line and removing it from {{ic|/etc/fstab}}. Options can be set with {{ic|1=rootflags=mount options...}} on the kernel line. Remember to remove the entry from your /etc/fstab file, else the systemd-remount-fs.service will continue to try to apply those settings. Alternatively, one could try to mask that unit.<br />
<br />
If btrfs is in use for the root filesystem, there is no need for a fsck on every boot like other filesystems. If this is the case, [[mkinitcpio]]'s {{ic|fsck}} hook can be removed. You may also want to mask the {{ic|systemd-fsck-root.service}}, or tell it not to fsck the root filesystem from the kernel command line using {{ic|fsck.mode&#61;skip}}. Without [[mkinitcpio]]'s {{ic|fsck}} hook, systemd will still fsck any relevant filesystems with the {{ic|systemd-fsck@.service}}<br />
<br />
You can also remove API filesystems from {{ic|/etc/fstab}}, as systemd will mount them itself (see {{ic|pacman -Ql systemd <nowiki>|</nowiki> grep '\.mount$'}} for a list). It is not uncommon for users to have a /tmp entry carried over from sysvinit, but you may have noticed from the command above that systemd already takes care of this. Ergo, it may be safely removed.<br />
<br />
Other filesystems like {{ic|/home}} can be mounted with custom mount units. Adding {{ic|noauto,x-systemd.automount}} will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.<br />
<br />
{{Note|this will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
== Initramfs ==<br />
<br />
As mentioned above, boot time can be decreased by slimming the kernel, thereby reducing the amount of data that must be loaded. This is also true for your initramfs (result of mkinitcpio), as this is loaded immediately after the kernel, and takes care of recognizing your root filesystem and mounting it. To boot, very little is actually needed and includes the storage bus, block device, and filesystem. Falconindy (Dave Reisner) has begrudgingly created a [http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html short tutorial] on how to achieve this on his blog.<br />
{{Note|If you are using anything that requires udev to be included in the initramfs (for example, lvm2, mdadm_udev, or even just specifying the filesystem label with {{ic|/dev/disk/by-label}}), trying to strip down your initramfs will not be a worthwhile endeavor.}}<br />
<br />
== Less output during boot ==<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
== See also ==<br />
<br />
* [[systemd]]<br />
* [[e4rat]]<br />
* [[udev]]<br />
* [[Daemon]]<br />
* [[mkinitcpio]]<br />
* [[Maximizing Performance]]<br />
* [[Bootchart]] - Tool to assist in profiling the boot process<br />
* [[Kexec]] - Tool to reboot very quickly without waiting for the whole BIOS boot process to finish.</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=276326Systemd (Italiano)2013-09-22T09:59:43Z<p>Ambro: /* Ottimizzazioni */</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}}<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 />
== Migration from SysVinit/initscripts ==<br />
<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 />
<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 {{pkg|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 {{pkg|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 />
== 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 monatggio ({{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. Me 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 />
== Ottimizzazioni ==<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=276323Systemd (Italiano)2013-09-22T09:48:30Z<p>Ambro: </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}}<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 />
== Migration from SysVinit/initscripts ==<br />
<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 />
<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 {{pkg|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 {{pkg|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 />
== 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 monatggio ({{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. Me 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 />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=276321Systemd (Italiano)2013-09-22T09:37:43Z<p>Ambro: </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}}<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 />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|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 {{pkg|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 />
== 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 />
== 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 monatggio ({{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. Me 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 />
==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 />
== 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 />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=255363Systemd (Italiano)2013-04-27T17:02:54Z<p>Ambro: Allineamento al 27.04.2013 00:27 (da completare)</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|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 {{pkg|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 />
* Adding your user to [[Users and Groups|groups]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) is '''not''' necessary for most use cases with systemd. The groups can even cause some functionality to break. For example, the {{ic|audio}} group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].<br />
* See the [[Network Configuration]] article for how to set up networking targets.<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 />
==== Configure module options ====<br />
<br />
Additional module options must be set in the {{ic|/etc/modprobe.d/modprobe.conf}}.<br />
<br />
Example:<br />
<br />
* we have {{ic|/etc/modules-load.d/loop.conf}} with module {{ic|loop}} inside to load during the boot.<br />
<br />
* in the {{ic|/etc/modprobe.d/modprobe.conf}} specify the additional options, e.g. {{ic|options loop max_loop&#61;64}}<br />
<br />
Afterwards, the newly set option might be verified via {{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 />
=== I files 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 />
{{note|This method may not work to set options in {{ic|/sys}} since the {{ic|systemd-tmpfiles-setup}} service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with {{ic|modinfo <module>}} and set this option with a [[Modprobe.d#Configuration|config file in {{ic|/etc/modprobe.d}}]]. Otherwise you will have to write a [[Udev#About_udev_rules|udev rule]] to set the appropriate attribute as soon as the device appears.}}<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 />
== 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 monatggio ({{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. Me 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 />
==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 />
== 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 />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
=== Diagnosing Boot Problems ===<br />
<br />
Boot with these parameters on the kernel command line:<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 More Debugging Information]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=251013Systemd (Italiano)2013-03-17T10:54:49Z<p>Ambro: Allineamento al 15.03.2013 19:00</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
{{Accuracy|reason=Nulla è cambiato riguardo i gruppi con systemd. Ci sono molti gruppi che raramente sono necessari, ma nulla è cambiato passando da consolekit a logind.}}<br />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<br />
<br />
Se il vecchio file di configurazione {{ic|/etc/timezone}} esiste si può rimuovere tranquillamente, in quanto non è usato da systemd.<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 che Windows 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 />
==== 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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 />
==== 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 />
=== I files 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 />
<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
{{Attenzione|Se si installano sia systemd (197-4 o successivo) che initscripts, e /etc/rc.local esiste, il processo di boot non arriverà a completamento (in quanto il servizio getty@tty1.service non attende rc-local.service dalla versione di systemd 197-4, sicché getty non può avviarsi). Sicché prima rimuovere o rinominare /etc/rc.local.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name>.service<br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl list-unit-files}}.<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 monatggio ({{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| 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.<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 un DE 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 />
==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}}: 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/}} 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 />
== 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/ qui].<br />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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ò. <br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|<br />
* Se si aggiunge l'hook {{ic|timestamp}} al proprio {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} e si ricostruisce l'initramfs con {{ic|mkinitcpio -p linux}}, systemd-analyze è in grado di mostrare anche quanto tempo è passato nell'initramfs.<br />
* Se si fa il boot tramite[[UEFI]] e si usa un boot loader che implementi systemds' [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] (attualmente solo [[Gummiboot]]), systemd-analyze può mostrare in aggiunta quanto tempo è trascorso nel firmware EFI firmware e nel boot loader stesso.}}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=247693ArchWiki:Translation Team (Italiano)2013-02-17T15:06:12Z<p>Ambro: /* Articoli principali */</p>
<hr />
<div>[[Category:ArchWiki (Italiano)]]<br />
[[en:ArchWiki Translation Team]]<br />
[[es:ArchWiki Translation Team]]<br />
[[hr:ArchWiki Translation Team]]<br />
[[pl:ArchWiki Translation Team]]<br />
[[tr:ArchWiki_Çeviri_Ekibi]]<br />
[[zh-CN:ArchWiki Translation Team]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questa pagina è dedicata a tutti coloro che desiderano collaborare per fornire un supporto di traduzione, correzione e mantenimento delle pagine italiane di ArchWiki. Vengono inoltre fornite tutte le informazioni necessarie per un corretto uso delle traduzioni.}}<br />
{{Article summary heading|Correlati}}<br />
{{Article summary wiki|Help:Editing (Italiano)}}<br />
{{Article summary wiki|Help:Style (Italiano)}}<br />
{{Article summary wiki|Help:Reading}}<br />
{{Article summary wiki|ArchWiki:About (Italiano)}}<br />
{{Article summary heading|Fonti Utili}}<br />
{{Article summary text|Alcuni articoli utili per aiutare nella traduzione: }}<br />
{{Article summary text|1=[http://http://www.archlinux.it/forum/viewtopic.php?f=19&t=1087 Strumenti utili per i traduttori]}}<br />
{{Article summary text|[http://tp.linux.it/buona_traduzione.html Regole per una buona traduzione]}}<br />
{{Article summary end}}<br />
<br />
Un Wiki è una collezione di documenti ipertestuali che viene aggiornata dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il testo può essere modificato da tutti gli utenti registrati, con lo scopo di condividere, scambiare, immagazzinare e ottimizzare la conoscenza in modo collaborativo.<br />
<br />
Proprio con questo intento, la [http://www.archlinux.it/ comunità ufficiale italiana] di Arch Linux ha fondato l'[[ArchWiki Translation Team (Italiano)|ArchWiki Translation Team]], un gruppo aperto e collaborativo di utenti, con lo scopo di allineare la documentazione italiana con quella inglese e tenerla costantemente aggiornata, in modo da offrire il miglior servizio possibile alla propria comunità. <br />
<br />
Come in ogni progetto collaborativo c'è sempre bisogno di utenti disponibili. Se volete aiutare la comunità italiana ad avere una documentazione sempre efficace, aggiornata e più ampia possibile, considerate la possibilità di unirvi a questo progetto. Ogni riferimento è reperibile sul forum ufficiale italiano in [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 questa discussione] dove potete '''segnalare la vostra disponibilità'''.<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i revisori==<br />
<br />
===Organizzazione interna===<br />
<br />
Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati ad uno precedentemente preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi.<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano, e ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità e verranno ''taggate'' con appositi template da inserire ad inizio articolo, per segnalare che la pagina è in fase di lavorazione:<br />
;Nel caso di Aggiornamenti e Revisioni:{{ic|<nowiki> {{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:{{ic|<nowiki>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di tradurre dell'eventuale testo antecedente e dei menu "Summary".<br />
<br />
===Linee guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
# Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
# Scrivere sempre in forma indiretta. (Es: {{ic|aprire un terminale e digitare}}... è più corretto rispetto ad {{ic|apri il terminale e digita}})<br />
# Utilizzare '''sempre''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità di poter correggere immediatamente eventuali errori.<br />
# É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare:<br />
#; <nowiki>{{ic|testo}}</nowiki>: quando si è in presenza del path di un file. (Es. {{ic|<nowiki>{{ic|/etc/fstab}}</nowiki>}}, o per evidenziare un modulo, comando o una stringa di configurazione. Es: {{ic|<nowiki>Si può utilizzare {{ic|iwconfig}} per configurare la rete...</nowiki>}} . <br />
#; <nowiki>{{bc|comando}}</nowiki>: quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: {{ic|Da terminale dare il comando <nowiki>{{bc|# iwconfig}}</nowiki>}}, a volte basta dare un enter e scrivere il comando preceduto da uno spazio bianco.<br />
#; <nowiki>{{hc|intestazione|contenuto}}</nowiki>: questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, es: {{ic|<nowiki>{{hc|nome del file/comando|contenuto di un file o l'output di un comando}}</nowiki>}}.<br />
#; <nowiki>{{keypress|tasto_funzione}}</nowiki>: quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: {{ic|premere <nowiki>{{keypress|Invio}}</nowiki> per continuare}}. <br />
#;<nowiki>{{pkg|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente nei repositori ufficiali, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere '{{ic|<nowiki>Installare linux-lts con : {{bc|pacman -S linux-lts}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>[[pacman (Italiano)|Installare]] il pacchetto {{pkg|linux-lts}}</nowiki>}}, il riferimento al wiki di Pacman è necessario solo la prima volta nell'articolo, nel caso di ripetitivi indicazioni sui pacchetti si può omettere. Es: {{ic|<nowiki>è possibile installare anche il pacchetto {{pkg|linux-lts-headers}}</nowiki>}}.<br />
#;<nowiki>{{AUR|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente in AUR, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere {{ic|<nowiki>Installare linux-lts-ck con : {{bc|yaourt -S linux-lts-ck}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>Installare il pacchetto {{AUR|linux-lts-ck}}, reperibile su [[ARU (Italiano)|AUR]]</nowiki>}},l'aggiunta del riferimento al wiki italiano di AUR è necessaria la prima volta per rimandare gli utenti a conoscerne l'uso. <br> <span style="position:relative; left:-2em;">{{Nota|1=In caso di errori del template dovuto a particolari caratteri, potrebbe essere necessario aggiungere '''1=''' prima del contenuto . La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}}</span> <br />
# É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. {{ic|Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti....}}), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (es: {{ic|<nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>}})<br />
# Per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
# Per quanto riguarda le traduzioni si ricorda che '''i primi revisori siete voi stessi'''. Di conseguenza:<br />
#* Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
#* Controllate che il contesto risulti corretto sia nel contenuto che nella forma e di facile comprensione, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
# Si consiglia di '''commentare sempre''' le modifiche che si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili.<br />
<br />
{{Nota|1=Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina. Per ogni dubbio potete chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum]}}<br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
===Pagine ad alta priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[dm-crypt with LUKS (Italiano)]]<br />
| Pagina da allineare e tradurre<br />
| maveloth<br />
| in corso<br />
|-<br />
| [[Disk_Encryption (Italiano)]]<br />
| Pagina da completare la traduzione<br />
| <br />
| traduzione incompleta<br />
|-<br />
|}<br />
<br />
=== Pagine a bassa priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Android (Italiano)]]<br />
| <br />
| SirX<br />
| In corso<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[PostgreSQL (Italiano)]]<br />
| Traduzione incompleta<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
==Revisioni==<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero: yyyy-mm-gg (es. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all<nowiki>'</nowiki>'''adozione''' del medesimo.<br />
<br />
===Adottare un wiki===<br />
<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e l'allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni:<br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra), oppure molto semplicemente andando sul wiki da seguire premere sul link '''Segui''' situato affianco a "Cronologia".<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
:{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc).<br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
===Tabella riassuntiva dei wiki revisionati e adottati===<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in due tabelle a seconda delle priorità ([[ArchWiki_Translation_Team_(Italiano)#Articoli principali|Articoli Princpali]] e [[ArchWiki_Translation_Team_(Italiano)#Articoli secondari|Articoli Secondari]]), in modo da avere le principiali guide di riferimento sempre aggiornate e sotto controllo. Lo scopo è quello di adottare per prima le pagine contenute nella tabella Articoli Principali, ed in un secondo momento occuparci degli altri articoli. Il contenuto delle tabelle viene discusso sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 froum] e può variare in base alle esigenze della comunità.<br />
<br />
Le tabelle contengono cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Redirect Ita''' - Vengono immessi qui i wiki con titolo italiano che hanno un ''redirect'' al wiki tradotto.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore. Qui immettendo '''Cedibile''' si rende pubblica la volontà di lasciare l'adozione di un wiki (in tal casoeliminare anche il proprio nome dalla colonna ''Revisore'').<br />
<br />
Le colonne contengono un link ''rapido'' di consultazione che effettua un ordinamento alfabetico.<br />
<br />
==== Articoli principali ====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center" <br />
| [[Advanced Linux Sound Architecture (Italiano)]] || 2012-02-22 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[AMD Catalyst (Italiano)]] || 2013-02-02 || umby213 || n/a || n/a<br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]] || 2012-11-12 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[Arch Linux (Italiano)]] || 2012-11-06 || icetux || n/a || n/a<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]] || 2012-11-11 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]] || 2013-01-16 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[ATI (Italiano)]] || 2012-11-10 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]] || 2013-01-23 || Veleno77 || [[Guida per Principianti]] || n/a<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]] || 2012-10-04 || icetux || [[Configurazione della Rete]] || n/a<br />
|-align="center"<br />
| [[CUPS (Italiano)]] || 2013-02-02 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[FAQ (Italiano)]] || 2012-08-20 || umby213 || [[Domande Frequenti]] || in allineamento --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 09:46, 15 December 2012 (UTC)<br />
|-align="center"<br />
| [[Fstab (Italiano)]] || 2012-12-27 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[GNOME (Italiano)]] || 2011-12-3 || Cylon || n/a || In allineamento<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]] || 2012-01-19 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Help:Style (Italiano)]] || 2012-11-13 || Kynikos || n/a || n/a<br />
|-align="center"<br />
| [[Installation Guide (Italiano)]] || 2012-12-27 || Veleno77 || [[Guida all'installazione]] || ''Official Installation Guide'' è redirect a questa pagina<br />
|-align="center"<br />
| [[Intel (Italiano)]] || 2013-01-21 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[KDE (Italiano)]] || 2013-01-21 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Laptop (Italiano)]] || 2012-10-24 || Nierro || n/a || n/a<br />
|--align="center"<br />
| [[Locale (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Main Page (Italiano)]] || 2012-12-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Makepkg (Italiano)]] || 2012-11-29 || icetux || n/a || n/a<br />
|-align="center"<br />
| [[Nouveau (Italiano)]] || 2012-12-27 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[NVIDIA (Italiano)]] || 2013-01-27 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]] || 2012-10-04 || icetux || [[Repository Ufficiali]] || n/a<br />
|-align="center"<br />
| [[Openbox (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[Pacman (Italiano)]] || 2012-11-11 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]] || 2012-01-19 || Ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]] || 2012-02-10 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[PulseAudio/Examples (Italiano)]] || 2012-02-10 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[RAID (Italiano)]] || 2012-11-04 || maveloth || n/a || n/a<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Start X at Login (Italiano)]] || 2011-09-20 || Hilinus || [[Far partire X al boot]] || n/a<br />
|- align="center"<br />
| [[Syslinux (Italiano)]] || 2012-08-01 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Systemd (Italiano)]] || 2013-02-16 || ambro || n/a || n/a<br />
|-align="center"<br />
| [[Systemd FAQ (Italiano)]] || 2012-11-04 || ambro || n/a || n/a<br />
|-align="center"<br />
| [[systemd/User (Italiano)]] || 2013-01-10 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[SysVinit (Italiano)]] || 2012-11-01 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]] || 2012-09-06 || icetux || [[Il Metodo Arch]] || n/a<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]] || 2011-04-19 || ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[Udev (Italiano)]] || 2011-12-08 || ninquitassar || n/a || n/a<br />
|-align="center"<br />
| [[Unified Extensible Firmware Interface (Italiano)]] || 2013-02-11 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[USB Installation Media (Italiano)]] || 2013-02-03 || umby213 || [[Installare da supporto USB]] || n/a<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]] || 2013-01-18 || Veleno77 || [[Utenti e Gruppi]] || n/a <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] || 2012-02-13 || Hilinus || [[Configurazione Wireless]] || n/a<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]] || 2012-02-07 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[Xfce (Italiano)]] || 2011-04-19 || ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]] || 2013-01-26 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Xorg (Italiano)]] || 2011-12-06 || ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
====Articoli secondari====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Acer Extensa 5220 (Italiano)]] || n/a || n/a || n/a || ok --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ACPI modules (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Acpid (Italiano)]] || 2012-10-13 || Nierro || n/a || n/a <br />
|-align="center"<br />
| [[Activating Numlock on Bootup (Italiano)]] || n/a || n/a || [[Attivare Numlock all'Avvio]] || Out of date<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]] || 2012-12-16 || umby213 || [[Permettere Spegnimento agli Utenti]] || n/a <br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Android Notifier (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Arch Compared to Other Distributions (Italiano)]] || 2012-01-19 || Toketin || [[Arch Comparato con altre Distribuzioni]] || Da controllare la formattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[ArchBang (Italiano)]] || n/a || n/a || n/a || Versione inglese è redirect a [[Arch Based Distributions (Active)]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Archiso (Italiano)]] || 2012-02-05 || n/a || n/a || '''da riallineare''' -- [[User:Kynikos|Kynikos]] 07:06, 24 March 2012 (EDT)<br />
|-align="center"<br />
| [[ArchWiki:About (Italiano)]] || n/a || n/a || n/a || '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Asus Eee PC 900A (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Autofs (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]] || 2012-12-21 || umby213 || [[Login Automatico in una console virtuale]] || n/a <br />
|-align="center"<br />
| [[Awesome3 (Italiano)]] || 2011-01-06 || Delcaran || n/a || '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]] || 2012-02-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Bluetooth (Italiano)]] || 2012-10-14 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[BOINC (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Bootchart (Italiano)]] || n/a || n/a || n/a || Out of date; versione inglese segnata a sua volta come Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]] || 2012-12-28 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Burg (Italiano)]] || 2011-09-21 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[CD Burning (Italiano)]] || 2012-01-19 || n/a || n/a || n/a |<br />
|-align="center"<br />
| [[Chromium (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Cinergy T stick (Italiano)]] || n/a || n/a || n/a || Versione inglese non esiste; riferimenti a kernel26 --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ClamAV (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Clyde (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Codecs (Italiano)]] || 2012-12-28 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]] || 2012-02-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Compiz (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Conky (Italiano)]] || 2011-09-21 || Ninquitassar || n/a ||'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Connman (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[ConsoleKit (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]] || 2013-01-27 || Veleno77 || [[Variazione di frequenza CPU]] || n/a <br />
|-align="center"<br />
| [[Creating Packages (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Cwm (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Daemon (Italiano)]] || 2012-11-06 || n/a || [[Demoni]] || n/a <br />
|-align="center"<br />
| [[Dell XPS M1530 (Italiano)]] || n/a || n/a || n/a || Out of date e stub --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Deltup (Italiano)]] || n/a || n/a || n/a || out of date; versione inglese "need expansions" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[DenyHosts (Italiano)]] || n/a || n/a || n/a || le versioni sono allineate ma entrambe out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]] || 2012-01-23 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]] || 2012-01-19 || n/a || [[Fotocamere Digitali]] || n/a <br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Display Manager (Italiano)]] || 2012-01-19 || Hilinus || [[Avviare automaticamente un gestore login grafico all'avvio]] || n/a <br />
|-align="center"<br />
| [[Dnsmasq (Italiano)]] || 2012-11-20 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Dropbox (Italiano)]] || 2013-02-12 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Drupal (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[E17 (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Eclipse Plugin Package Guidelines (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile'''<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Evilwm (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Exaile (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Execute on USB insert (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ext3 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ext4 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[FAM (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]] || 2012-01-26 || n/a || [[Controllo ventola CPU]] || n/a <br />
|-align="center"<br />
| [[Fbsplash (Italiano)]] || 2012-01-19 || Cylon || n/a || n/a <br />
|-align="center"<br />
| [[Feh (Italiano)]] || 2013-01-26 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[File Systems (Italiano)]] || 2012-11-24 || Veleno77 || [[Formattare una Periferica]], [[Format a device (Italiano)]] è un redirect || n/a <br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]] || 2012-01-19 || n/a || n/a || Versione inglese rinominata in [[Arch filesystem hierarchy]] [[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firefox (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firewalls (Italiano)]] || 2012-12-08 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Fluxbox (Italiano)]] || 2013-01-29 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Font Configuration (Italiano)]] || 2012-09-11 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Fonts (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[FVWM (Italiano)]] || 2012-10-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Games (Italiano)]] || n/a || n/a || n/a || da includere in [[List of Applications]] [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 22:22, 27 December 2012 (UTC)<br />
|-align="center"<br />
| [[Gamin (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come "stub"; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]] || 2012-01-19 || asa || [[Raccomandazioni Generali]] [[Suggerimenti Post Installazione]] ||'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]] || 2012-03-12 || Kynikos || [[Come contribuire]] || '''Cedibile''', '''da riallineare''' -- [[User:Kynikos|Kynikos]] 06:51, 13 March 2012 (EDT)<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]] || 2011-03-22 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Google Earth (Italiano)]] || n/a || n/a || n/a || Versione italiana più completa di quella inglese; credo che comunque sia da rivedere e aggiornare --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Grub-gfx (Italiano)]] || n/a || n/a || n/a || Out of Date; versione inglese a sua volta out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[GRUB Legacy (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[GTK+ (Italiano)]] || 2012-08-28 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[HAL (Italiano)]] || n/a || n/a || n/a || Hal è un redirect a [[udev (Italiano)]]<br />
|-align="center"<br />
| [[Hardware Diagnostics (Italiano)]] || n/a || n/a || [[Diagnostica Hardware]] || Segnata come "out of date"; non esiste versione inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]] || 2012-01-19 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Help:Editing (Italiano)]] || n/a || n/a || n/a || Out of Date<br />
|-align="center"<br />
| [[High Performance Firewall (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come: poorly written, merging in [[Router]]; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[IceWM (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Improve Pacman Performance (Italiano)]] || 2012-02-04 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]] || 2012-02-02 || Stele || n/a || n/a <br />
|-align="center"<br />
| [[Install from SSH (Italiano)]] || 2012-06-15 || Stele || n/a || n/a <br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Internet key Momo Design (Italiano)]] || n/a || n/a || n/a || la versione inglese è scritta in italiano '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Internet Share (Italiano)]] || n/a || n/a || [[Condivisione connessione internet]] || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Intel C++ (Italiano)]] || 2012-09-16 || bred || n/a || n/a <br />
|-align="center"<br />
| [[Iptables (Italiano)]] || 2012-11-13 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Java (Italiano)]] || 2013-02-02 || thewall || n/a || n/a <br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[JWM (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[KDM (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]] || 2010-12-30 || n/a || n/a || Versione inglese "need expansions"; entrambe le pagine puntano a kernel26<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]] || 2012-08-08 || Kynikos || n/a || da riallineare -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:09, 4 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernel Panics (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernels (Italiano)]] || 2012-04-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Arch Build System (Italiano)]] || 2012-03-23 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Script (Italiano)]] || 2012-04-09 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Traditional (Italiano)]] || 2012-04-20 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[KVM (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[LAMP (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]] || 2012-11-05 || veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[List of Applications (Italiano)]] || 2011-12-16 || Veleno77 || n/a ||In fase di revisione]]<br />
|-align="center"<br />
| [[LVM (Italiano)]] || 2012-12-08 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[LXDE (Italiano)]] || 2011-01-06 || xaber || n/a || La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[MacBook (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]] || 2013-02-01 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[MATE (Italiano)]] || 2012-07-29 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Mathematica (Italiano)]] || n/a || n/a || n/a || Segnate come "stub" entrambe le versioni --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Media Center (Italiano)]] || n/a || Stele || n/a || '''É una pagina italiana e non ha il corrispettivo inglese'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]] || 2013-02-02 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]] || 2012-02-13 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Mpd (Italiano)]] || 2011-01-08 || Delcaran || n/a ||'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[MPlayer (Italiano)]] || 2012-12-15 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Mutt (Italiano)]] || 2012-07-06 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[MySQL (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Namcap (Italiano)]] || 2012-09-29 || thewall || n/a || n/a <br />
|-align="center"<br />
| [[Nano (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]] || 2012-01-14 || Ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[Netcfg (Italiano)]] || 2012-10-03 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[Netbook Games (Italiano)]] || 2013-01-28 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[NetworkManager (Italiano)]] || 2013-01-14 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[NFS (Italiano)]] || 2012-01-27 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[NFSv4 (Italiano)]] || 2012-02-18 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Notify OSD (Italiano)]] || n/a || n/a || n/a || Versione inglese è redirect a [[Unity]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ntop (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]] || 2012-01-19 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[OpenOffice (Italiano)]] || n/a || n/a || n/a || Scritta in inglese e Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Opera (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Osiris (Italiano)]] || n/a || n/a || n/a || Versione inglese non esiste --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OSS (Italiano)]] || 2012-01-19 || asa || n/a ||'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman GUI Frontends (Italiano)]] || n/a || n/a || [[Interfacce Grafiche per Pacman]] || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacman Tips (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacnew and Pacsave Files (Italiano)]] || n/a || n/a || [[File Pacnew e Pacsave]] || out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Palm Pre (Italiano)]] || n/a || n/a || n/a || Versione inglese scritta in italiano --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Partitioning (Italiano)]] || 2012-07-12 || n/a || n/a || Out of date [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:26, 30 September 2012 (UTC)<br />
|-align="center"<br />
| [[Password Recovery (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Pawm (Italiano)]] || 2012-11-01 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[PekWM (Italiano)]] || 2012-12-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]] || 2011-09-23 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Plymouth (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]] || 2012-10-06 || Nierro || n/a || n/a <br />
|-align="center"<br />
| [[Powerpill (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Privoxy (Italiano)]] || 2011-09-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Readline (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]] || 2011-11-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Samba (Italiano)]] || 2011-11-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Secure Shell (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]] || 2011-10-20 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[SLiM (Italiano)]] || 2013-01-26 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Small Business Server (Italiano)]] || n/a || n/a || n/a || '''Pagina italiana più aggiornata, contiene sottopagine''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]] || 2011-09-05 || n/a || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]] || 2011-02-21 || asa || n/a || n/a <br />
|-align="center"<br />
| [[SSH Keys (Italiano)]] || 2011-12-17 || n/a || n/a || '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sshfs (Italiano)]] || 2011-11-13 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Sudo (Italiano)]] || 2011-12-06 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Sugar (Italiano)]] || 2012-07-16 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[swap (Italiano)]] || 2012-09-17 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Synergy (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile''' <br />
|-align="center"<br />
| [[Table of Contents (Italiano)]] || 2012-09-04 || Kynikos || n/a || La struttura della lista viene aggiornata automaticamente e periodicamente da [[User:Kynikos.bot|Kynikos.bot]]<br />
|-align="center"<br />
| [[TeXLive (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[The Arch Way v2.0 (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Thunar (Italiano)]] || 2013-01-26 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Thunderbird (Italiano)]] || n/a || n/a || n/a || Out of Date; scritta in inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]] || 2011-10-09 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[TuPac (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Twm (Italiano)]] || 2012-11-01 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]] || 2011-06-02 || Ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[USB Storage Devices (Italiano)]] || n/a || n/a || n/a || Out of date<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Uvesafb (Italiano)]] || 2011-10-17 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]] || 2011-09-28 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Vim (Italiano)]] || 2012-05-15 || n/a || n/a || '''Da riallineare''' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 12 July 2012 (UTC)<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[VirtualBox (Italiano)]] || 2011-03-21 || ant84 || n/a || n/a <br />
|-align="center"<br />
| [[VMware (Italiano)]] || 2012-02-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Webmin (Italiano)]] || 2011-08-10 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Wicd (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Window Maker (Italiano)]] || 2012-11-05 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Window Manager (Italiano)]] || 2012-02-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Wine (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Xampp (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[xf86-video-sis (Italiano)]] || 2012-10-06 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[XFS (Italiano)]] || n/a || n/a || n/a || out of date; versione inglese segnata come "stub" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Yaourt (Italiano)]] || 2012-12-29 || umby213 || n/a || n/a <br />
|}<br />
<br />
==Staff tecnico==<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Coordinatore<br />
:# [[User:4javier|4javier]]<br />
:# [[User:Kynikos|Kynikos]] - [[ArchWiki:Administrators|Amministratore ArchWiki ]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
:# [[User:love89|Love89]]<br />
:# [[User:maveloth|maveloth]]<br />
:# [[User:nierro|Nierro]]<br />
:# [[User:Dariocent|Dario]]<br />
:# [[User:Ambro|Ambro]]<br />
<br />
==Ulteriori informazioni e supporto==<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum italiano].</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=247692Systemd (Italiano)2013-02-17T15:04:25Z<p>Ambro: Allineamento al 16.02.2013 10.02</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
{{Accuracy|reason=Nulla è cambiato riguardo i gruppi con systemd. Ci sono molti gruppi che raramente sono necessari, ma nulla è cambiato passando da consolekit a logind.}}<br />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<br />
<br />
Se il vecchio file di configurazione {{ic|/etc/timezone}} esiste si può rimuovere tranquillamente, in quanto non è usato da systemd.<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 che Windows 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 />
==== 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 />
=== I files 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 />
<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
{{Attenzione|Se si installano sia systemd (197-4 o successivo) che initscripts, e /etc/rc.local esiste, il processo di boot non arriverà a completamento (in quanto il servizio getty@tty1.service non attende rc-local.service dalla versione di systemd 197-4, sicché getty non può avviarsi). Sicché prima rimuovere o rinominare /etc/rc.local.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name>.service<br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl list-unit-files}}.<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 monatggio ({{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| 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.<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 un DE 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 />
==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}}: 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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/ qui].<br />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=244913Systemd (Italiano)2013-01-23T16:53:45Z<p>Ambro: Allineamento al 23.01.2013 06:02</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<br />
<br />
Se il vecchio file di configurazione {{ic|/etc/timezone}} esiste si può rimuovere tranquillamente, in quanto non è usato da systemd.<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 che Windows 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 />
==== 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 />
===== 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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
{{Attenzione|Se si installano sia systemd (197-4 o successivo) che initscripts, e /etc/rc.local esiste, il processo di boot non arriverà a completamento (in quanto il servizio getty@tty1.service non attende rc-local.service dalla versione di systemd 197-4, sicché getty non può avviarsi). Sicché prima rimuovere o rinominare /etc/rc.local.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name>.service<br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 un DE 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 />
==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}}: 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare systemd-bootchart====<br />
<br />
Bootchart è stato implementato in systemd dal 17 Ottobre 2012, e si può utilizzarlo per il boot proprio come si farebbe con il bootchart originale. Aggiongere alla linea del kernel:<br />
<br />
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart<br />
<br />
==== Usare bootchart2 ====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Correzione di errori ==<br />
<br />
=== "Error: No space left on device" quando si prova ad avviare o a riavviare un servizio ===<br />
Nota: Non so se si tratta di una soluzione appropriata, ma a me appare funzionante<br />
<br />
Vedere il link: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]<br />
<br />
Grazie a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum] per la segnalazione del sito.<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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=243345Systemd (Italiano)2013-01-09T21:20:25Z<p>Ambro: Allineamento al 08.01.2013 16:12</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<br />
<br />
Se il vecchio file di configurazione {{ic|/etc/timezone}} esiste si può rimuovere tranquillamente, in quanto non è usato da systemd.<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 che Windows 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 />
==== 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 />
===== 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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 un DE 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 />
==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}}: 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Correzione di errori ==<br />
<br />
=== "Error: No space left on device" quando si prova ad avviare o a riavviare un servizio ===<br />
Nota: Non so se si tratta di una soluzione appropriata, ma a me appare funzionante<br />
<br />
Vedere il link: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]<br />
<br />
Grazie a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum] per la segnalazione del sito.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=243176ArchWiki:Translation Team (Italiano)2013-01-07T17:39:05Z<p>Ambro: /* Articoli principali */</p>
<hr />
<div>[[Category:ArchWiki (Italiano)]]<br />
[[en:ArchWiki Translation Team]]<br />
[[es:ArchWiki Translation Team]]<br />
[[hr:ArchWiki Translation Team]]<br />
[[pl:ArchWiki Translation Team]]<br />
[[tr:ArchWiki_Çeviri_Ekibi]]<br />
[[zh-CN:ArchWiki Translation Team]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questa pagina è dedicata a tutti coloro che desiderano collaborare per fornire un supporto di traduzione, correzione e mantenimento delle pagine italiane di ArchWiki. Vengono inoltre fornite tutte le informazioni necessarie per un corretto uso delle traduzioni.}}<br />
{{Article summary heading|Correlati}}<br />
{{Article summary wiki|Help:Editing (Italiano)}}<br />
{{Article summary wiki|Help:Style (Italiano)}}<br />
{{Article summary wiki|Help:Reading}}<br />
{{Article summary wiki|ArchWiki:About (Italiano)}}<br />
{{Article summary heading|Fonti Utili}}<br />
{{Article summary text|Alcuni articoli utili per aiutare nella traduzione: }}<br />
{{Article summary text|1=[http://http://www.archlinux.it/forum/viewtopic.php?f=19&t=1087 Strumenti utili per i traduttori]}}<br />
{{Article summary text|[http://tp.linux.it/buona_traduzione.html Regole per una buona traduzione]}}<br />
{{Article summary end}}<br />
<br />
Un Wiki è una collezione di documenti ipertestuali che viene aggiornata dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il testo può essere modificato da tutti gli utenti registrati, con lo scopo di condividere, scambiare, immagazzinare e ottimizzare la conoscenza in modo collaborativo.<br />
<br />
Proprio con questo intento, la [http://www.archlinux.it/ comunità ufficiale italiana] di Arch Linux ha fondato l'[[ArchWiki Translation Team (Italiano)|ArchWiki Translation Team]], un gruppo aperto e collaborativo di utenti, con lo scopo di allineare la documentazione italiana con quella inglese e tenerla costantemente aggiornata, in modo da offrire il miglior servizio possibile alla propria comunità. <br />
<br />
Come in ogni progetto collaborativo c'è sempre bisogno di utenti disponibili. Se volete aiutare la comunità italiana ad avere una documentazione sempre efficace, aggiornata e più ampia possibile, considerate la possibilità di unirvi a questo progetto. Ogni riferimento è reperibile sul forum ufficiale italiano in [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 questa discussione] dove potete '''segnalare la vostra disponibilità'''.<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i revisori==<br />
<br />
===Organizzazione interna===<br />
<br />
Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati ad uno precedentemente preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi.<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano, e ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità e verranno ''taggate'' con appositi template da inserire ad inizio articolo, per segnalare che la pagina è in fase di lavorazione:<br />
;Nel caso di Aggiornamenti e Revisioni:{{ic|<nowiki> {{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:{{ic|<nowiki>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di tradurre dell'eventuale testo antecedente e dei menu "Summary".<br />
<br />
===Linee guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
# Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
# Scrivere sempre in forma indiretta. (Es: {{ic|aprire un terminale e digitare}}... è più corretto rispetto ad {{ic|apri il terminale e digita}})<br />
# Utilizzare '''sempre''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità di poter correggere immediatamente eventuali errori.<br />
# É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare:<br />
#; <nowiki>{{ic|testo}}</nowiki>: quando si è in presenza del path di un file. (Es. {{ic|<nowiki>{{ic|/etc/fstab}}</nowiki>}}, o per evidenziare un modulo, comando o una stringa di configurazione. Es: {{ic|<nowiki>Si può utilizzare {{ic|iwconfig}} per configurare la rete...</nowiki>}} . <br />
#; <nowiki>{{bc|comando}}</nowiki>: quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: {{ic|Da terminale dare il comando <nowiki>{{bc|# iwconfig}}</nowiki>}}, a volte basta dare un enter e scrivere il comando preceduto da uno spazio bianco.<br />
#; <nowiki>{{hc|intestazione|contenuto}}</nowiki>: questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, es: {{ic|<nowiki>{{hc|nome del file/comando|contenuto di un file o l'output di un comando}}</nowiki>}}.<br />
#; <nowiki>{{keypress|tasto_funzione}}</nowiki>: quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: {{ic|premere <nowiki>{{keypress|Invio}}</nowiki> per continuare}}. <br />
#;<nowiki>{{pkg|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente nei repositori ufficiali, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere '{{ic|<nowiki>Installare linux-lts con : {{bc|pacman -S linux-lts}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>[[pacman (Italiano)|Installare]] il pacchetto {{pkg|linux-lts}}</nowiki>}}, il riferimento al wiki di Pacman è necessario solo la prima volta nell'articolo, nel caso di ripetitivi indicazioni sui pacchetti si può omettere. Es: {{ic|<nowiki>è possibile installare anche il pacchetto {{pkg|linux-lts-headers}}</nowiki>}}.<br />
#;<nowiki>{{AUR|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente in AUR, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere {{ic|<nowiki>Installare linux-lts-ck con : {{bc|yaourt -S linux-lts-ck}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>Installare il pacchetto {{AUR|linux-lts-ck}}, reperibile su [[ARU (Italiano)|AUR]]</nowiki>}},l'aggiunta del riferimento al wiki italiano di AUR è necessaria la prima volta per rimandare gli utenti a conoscerne l'uso. <br> <span style="position:relative; left:-2em;">{{Nota|1=In caso di errori del template dovuto a particolari caratteri, potrebbe essere necessario aggiungere '''1=''' prima del contenuto . La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}}</span> <br />
# É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. {{ic|Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti....}}), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (es: {{ic|<nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>}})<br />
# Per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
# Per quanto riguarda le traduzioni si ricorda che '''i primi revisori siete voi stessi'''. Di conseguenza:<br />
#* Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
#* Controllate che il contesto risulti corretto sia nel contenuto che nella forma e di facile comprensione, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
# Si consiglia di '''commentare sempre''' le modifiche che si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili.<br />
<br />
{{Nota|1=Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina. Per ogni dubbio potete chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum]}}<br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
===Pagine ad alta priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[dm-crypt with LUKS (Italiano)]]<br />
| Pagina da allineare e tradurre<br />
| maveloth<br />
| in corso<br />
|-<br />
| [[Disk_Encryption (Italiano)]]<br />
| Pagina da completare la traduzione<br />
| <br />
| traduzione incompleta<br />
|-<br />
|}<br />
<br />
=== Pagine a bassa priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Android (Italiano)]]<br />
| <br />
| SirX<br />
| In corso<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[PostgreSQL (Italiano)]]<br />
| Traduzione incompleta<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
==Revisioni==<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero: yyyy-mm-gg (es. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all<nowiki>'</nowiki>'''adozione''' del medesimo.<br />
<br />
===Adottare un wiki===<br />
<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e l'allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni:<br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra), oppure molto semplicemente andando sul wiki da seguire premere sul link '''Segui''' situato affianco a "Cronologia".<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
:{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc).<br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
===Tabella riassuntiva dei wiki revisionati e adottati===<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in due tabelle a seconda delle priorità ([[ArchWiki_Translation_Team_(Italiano)#Articoli principali|Articoli Princpali]] e [[ArchWiki_Translation_Team_(Italiano)#Articoli secondari|Articoli Secondari]]), in modo da avere le principiali guide di riferimento sempre aggiornate e sotto controllo. Lo scopo è quello di adottare per prima le pagine contenute nella tabella Articoli Principali, ed in un secondo momento occuparci degli altri articoli. Il contenuto delle tabelle viene discusso sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 froum] e può variare in base alle esigenze della comunità.<br />
<br />
Le tabelle contengono cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Redirect Ita''' - Vengono immessi qui i wiki con titolo italiano che hanno un ''redirect'' al wiki tradotto.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore. Qui immettendo '''Cedibile''' si rende pubblica la volontà di lasciare l'adozione di un wiki (in tal casoeliminare anche il proprio nome dalla colonna ''Revisore'').<br />
<br />
Le colonne contengono un link ''rapido'' di consultazione che effettua un ordinamento alfabetico.<br />
<br />
==== Articoli principali ====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center" <br />
| [[Advanced Linux Sound Architecture (Italiano)]] || 2012-02-22 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[AMD Catalyst (Italiano)]] || 2012-12-25 || umby213 || n/a || n/a<br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]] || 2012-11-12 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[Arch Linux (Italiano)]] || 2012-11-06 || icetux || n/a || n/a<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]] || 2012-11-11 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]] || 2012-12-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[ATI (Italiano)]] || 2012-11-10 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]] || 2013-01-06 || Veleno77 || [[Guida per Principianti]] || n/a<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]] || 2012-10-04 || icetux || [[Configurazione della Rete]] || n/a<br />
|-align="center"<br />
| [[CUPS (Italiano)]] || 2012-12-31 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[FAQ (Italiano)]] || 2012-08-20 || umby213 || [[Domande Frequenti]] || in allineamento --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 09:46, 15 December 2012 (UTC)<br />
|-align="center"<br />
| [[Fstab (Italiano)]] || 2012-12-27 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[GNOME (Italiano)]] || 2011-12-3 || Cylon || n/a || In allineamento<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]] || 2012-01-19 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Help:Style (Italiano)]] || 2012-11-13 || Kynikos || n/a || n/a<br />
|-align="center"<br />
| [[Installation Guide (Italiano)]] || 2012-12-27 || Veleno77 || [[Guida all'installazione]] || ''Official Installation Guide'' è redirect a questa pagina<br />
|-align="center"<br />
| [[Intel (Italiano)]] || 2012-12-27 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[KDE (Italiano)]] || 2013-01-07 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Laptop (Italiano)]] || 2012-10-24 || Nierro || n/a || n/a<br />
|--align="center"<br />
| [[Locale (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Main Page (Italiano)]] || 2012-12-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Makepkg (Italiano)]] || 2012-11-29 || icetux || n/a || n/a<br />
|-align="center"<br />
| [[Nouveau (Italiano)]] || 2012-12-27 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[NVIDIA (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]] || 2012-10-04 || icetux || [[Repository Ufficiali]] || n/a<br />
|-align="center"<br />
| [[Openbox (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[Pacman (Italiano)]] || 2012-11-11 || Kynikos || n/a || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]] || 2012-01-19 || Ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]] || 2012-02-10 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[PulseAudio/Examples (Italiano)]] || 2012-02-10 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[RAID (Italiano)]] || 2012-11-04 || maveloth || n/a || n/a<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Start X at Login (Italiano)]] || 2011-09-20 || Hilinus || [[Far partire X al boot]] || n/a<br />
|- align="center"<br />
| [[Syslinux (Italiano)]] || 2012-08-01 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Systemd (Italiano)]] || 2013-01-04 || ambro || n/a || n/a<br />
|-align="center"<br />
| [[Systemd FAQ (Italiano)]] || 2012-11-04 || ambro || n/a || n/a<br />
|-align="center"<br />
| [[SysVinit (Italiano)]] || 2012-11-01 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]] || 2012-09-06 || icetux || [[Il Metodo Arch]] || n/a<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]] || 2011-04-19 || ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[Udev (Italiano)]] || 2011-12-08 || ninquitassar || n/a || n/a<br />
|-align="center"<br />
| [[Unified Extensible Firmware Interface (Italiano)]] || 2013-01-03 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[USB Installation Media (Italiano)]] || 2012-12-30 || umby213 || [[Installare da supporto USB]] || n/a<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]] || 2013-01-06 || Veleno77 || [[Utenti e Gruppi]] || n/a <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] || 2012-02-13 || Hilinus || [[Configurazione Wireless]] || n/a<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]] || 2012-02-07 || Hilinus || n/a || n/a<br />
|-align="center"<br />
| [[Xfce (Italiano)]] || 2011-04-19 || ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]] || 2012-12-25 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Xorg (Italiano)]] || 2011-12-06 || ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
====Articoli secondari====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Acer Extensa 5220 (Italiano)]] || n/a || n/a || n/a || ok --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ACPI modules (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Acpid (Italiano)]] || 2012-10-13 || Nierro || n/a || n/a <br />
|-align="center"<br />
| [[Activating Numlock on Bootup (Italiano)]] || n/a || n/a || [[Attivare Numlock all'Avvio]] || Out of date<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]] || 2012-12-16 || umby213 || [[Permettere Spegnimento agli Utenti]] || n/a <br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Android Notifier (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Arch Compared to Other Distributions (Italiano)]] || 2012-01-19 || Toketin || [[Arch Comparato con altre Distribuzioni]] || Da controllare la formattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[ArchBang (Italiano)]] || n/a || n/a || n/a || Versione inglese è redirect a [[Arch Based Distributions (Active)]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Archiso (Italiano)]] || 2012-02-05 || n/a || n/a || '''da riallineare''' -- [[User:Kynikos|Kynikos]] 07:06, 24 March 2012 (EDT)<br />
|-align="center"<br />
| [[ArchWiki:About (Italiano)]] || n/a || n/a || n/a || '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Asus Eee PC 900A (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Autofs (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]] || 2012-12-21 || umby213 || [[Login Automatico in una console virtuale]] || n/a <br />
|-align="center"<br />
| [[Awesome3 (Italiano)]] || 2011-01-06 || Delcaran || n/a || '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]] || 2012-02-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Bluetooth (Italiano)]] || 2012-10-14 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[BOINC (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Bootchart (Italiano)]] || n/a || n/a || n/a || Out of date; versione inglese segnata a sua volta come Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]] || 2012-12-28 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Burg (Italiano)]] || 2011-09-21 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[CD Burning (Italiano)]] || 2012-01-19 || n/a || n/a || n/a |<br />
|-align="center"<br />
| [[Chromium (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Cinergy T stick (Italiano)]] || n/a || n/a || n/a || Versione inglese non esiste; riferimenti a kernel26 --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ClamAV (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Clyde (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Codecs (Italiano)]] || 2012-12-28 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]] || 2012-02-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Common Applications (Italiano)]] || 2011-12-16 || Veleno77 || n/a ||In fase di revisione, un riassunto è disponibile a [[Talk:Common Applications#Summary of related changes]]<br />
|-align="center"<br />
| [[Compiz (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Conky (Italiano)]] || 2011-09-21 || Ninquitassar || n/a ||'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Connman (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[ConsoleKit (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]] || 2012-12-01 || Veleno77 || [[Variazione di frequenza CPU]] || n/a <br />
|-align="center"<br />
| [[Creating Packages (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Cwm (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Daemon (Italiano)]] || 2012-11-06 || n/a || [[Demoni]] || n/a <br />
|-align="center"<br />
| [[Dell XPS M1530 (Italiano)]] || n/a || n/a || n/a || Out of date e stub --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Deltup (Italiano)]] || n/a || n/a || n/a || out of date; versione inglese "need expansions" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[DenyHosts (Italiano)]] || n/a || n/a || n/a || le versioni sono allineate ma entrambe out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]] || 2012-12-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]] || 2012-01-19 || n/a || [[Fotocamere Digitali]] || n/a <br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Display Manager (Italiano)]] || 2012-01-19 || Hilinus || [[Avviare automaticamente un gestore login grafico all'avvio]] || n/a <br />
|-align="center"<br />
| [[Dnsmasq (Italiano)]] || 2012-11-20 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Dropbox (Italiano)]] || 2012-09-19 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Drupal (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[E17 (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Eclipse Plugin Package Guidelines (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile'''<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]] || 2013-01-06 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Evilwm (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Exaile (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Execute on USB insert (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ext3 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ext4 (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[FAM (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]] || 2012-01-26 || n/a || [[Controllo ventola CPU]] || n/a <br />
|-align="center"<br />
| [[Fbsplash (Italiano)]] || 2012-01-19 || Cylon || n/a || n/a <br />
|-align="center"<br />
| [[Feh (Italiano)]] || 2012-10-11 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[File Systems (Italiano)]] || 2012-11-24 || Veleno77 || [[Formattare una Periferica]], [[Format a device (Italiano)]] è un redirect || n/a <br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]] || 2012-01-19 || n/a || n/a || Versione inglese rinominata in [[Arch filesystem hierarchy]] [[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firefox (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firewalls (Italiano)]] || 2012-12-08 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Fluxbox (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Font Configuration (Italiano)]] || 2012-09-11 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Fonts (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[FVWM (Italiano)]] || 2012-10-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Games (Italiano)]] || n/a || n/a || n/a || da includere in [[List of Applications]] [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 22:22, 27 December 2012 (UTC)<br />
|-align="center"<br />
| [[Gamin (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come "stub"; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]] || 2012-01-19 || asa || [[Raccomandazioni Generali]] [[Suggerimenti Post Installazione]] ||'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]] || 2012-03-12 || Kynikos || [[Come contribuire]] || '''Cedibile''', '''da riallineare''' -- [[User:Kynikos|Kynikos]] 06:51, 13 March 2012 (EDT)<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]] || 2011-03-22 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Google Earth (Italiano)]] || n/a || n/a || n/a || Versione italiana più completa di quella inglese; credo che comunque sia da rivedere e aggiornare --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Grub-gfx (Italiano)]] || n/a || n/a || n/a || Out of Date; versione inglese a sua volta out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[GRUB Legacy (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[GTK+ (Italiano)]] || 2012-08-28 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[HAL (Italiano)]] || n/a || n/a || n/a || Hal è un redirect a [[udev (Italiano)]]<br />
|-align="center"<br />
| [[Hardware Diagnostics (Italiano)]] || n/a || n/a || [[Diagnostica Hardware]] || Segnata come "out of date"; non esiste versione inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]] || 2012-01-19 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Help:Editing (Italiano)]] || n/a || n/a || n/a || Out of Date<br />
|-align="center"<br />
| [[High Performance Firewall (Italiano)]] || n/a || n/a || n/a || Versione inglese segnata come: poorly written, merging in [[Router]]; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[IceWM (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Improve Pacman Performance (Italiano)]] || 2012-02-04 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]] || 2012-02-02 || Stele || n/a || n/a <br />
|-align="center"<br />
| [[Install from SSH (Italiano)]] || 2012-06-15 || Stele || n/a || n/a <br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Internet key Momo Design (Italiano)]] || n/a || n/a || n/a || la versione inglese è scritta in italiano '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Internet Share (Italiano)]] || n/a || n/a || [[Condivisione connessione internet]] || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Intel C++ (Italiano)]] || 2012-09-16 || bred || n/a || n/a <br />
|-align="center"<br />
| [[Iptables (Italiano)]] || 2012-11-13 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[Java (Italiano)]] || 2012-12-13 || thewall || n/a || n/a <br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[JWM (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[KDM (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]] || 2010-12-30 || n/a || n/a || Versione inglese "need expansions"; entrambe le pagine puntano a kernel26<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]] || 2012-08-08 || Kynikos || n/a || da riallineare -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:09, 4 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernel Panics (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernels (Italiano)]] || 2012-04-01 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Arch Build System (Italiano)]] || 2012-03-23 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Script (Italiano)]] || 2012-04-09 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Kernels/Compilation/Traditional (Italiano)]] || 2012-04-20 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[KVM (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[LAMP (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]] || 2012-11-05 || veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[LVM (Italiano)]] || 2012-12-08 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[LXDE (Italiano)]] || 2011-01-06 || xaber || n/a || La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[MacBook (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]] || 2012-10-01 || maveloth || n/a || n/a <br />
|-align="center"<br />
| [[MATE (Italiano)]] || 2012-07-29 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Mathematica (Italiano)]] || n/a || n/a || n/a || Segnate come "stub" entrambe le versioni --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Media Center (Italiano)]] || n/a || Stele || n/a || '''É una pagina italiana e non ha il corrispettivo inglese'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]] || 2012-02-13 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Mpd (Italiano)]] || 2011-01-08 || Delcaran || n/a ||'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[MPlayer (Italiano)]] || 2012-12-15 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Mutt (Italiano)]] || 2012-07-06 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[MySQL (Italiano)]] || 2012-01-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Namcap (Italiano)]] || 2012-09-29 || thewall || n/a || n/a <br />
|-align="center"<br />
| [[Nano (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]] || 2012-01-14 || Ninquitassar || n/a || n/a <br />
|-align="center"<br />
| [[Netcfg (Italiano)]] || 2012-10-03 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]] || 2012-11-06 || icetux || n/a || n/a <br />
|-align="center"<br />
| [[NetworkManager (Italiano)]] || 2013-01-02 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[NFS (Italiano)]] || 2012-01-27 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[NFSv4 (Italiano)]] || 2012-02-18 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Notify OSD (Italiano)]] || n/a || n/a || n/a || Versione inglese è redirect a [[Unity]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Ntop (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]] || 2012-01-19 || Toketin || n/a || n/a <br />
|-align="center"<br />
| [[OpenOffice (Italiano)]] || n/a || n/a || n/a || Scritta in inglese e Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Opera (Italiano)]] || n/a || n/a || n/a || Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Osiris (Italiano)]] || n/a || n/a || n/a || Versione inglese non esiste --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OSS (Italiano)]] || 2012-01-19 || asa || n/a ||'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman GUI Frontends (Italiano)]] || n/a || n/a || [[Interfacce Grafiche per Pacman]] || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacman Tips (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacnew and Pacsave Files (Italiano)]] || n/a || n/a || [[File Pacnew e Pacsave]] || out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Palm Pre (Italiano)]] || n/a || n/a || n/a || Versione inglese scritta in italiano --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Partitioning (Italiano)]] || 2012-07-12 || n/a || n/a || Out of date [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:26, 30 September 2012 (UTC)<br />
|-align="center"<br />
| [[Password Recovery (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Pawm (Italiano)]] || 2012-11-01 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[PekWM (Italiano)]] || 2012-12-30 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]] || 2011-09-23 || Hilinus || n/a || n/a <br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Plymouth (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]] || 2012-10-06 || Nierro || n/a || n/a <br />
|-align="center"<br />
| [[Powerpill (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Privoxy (Italiano)]] || 2011-09-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Readline (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]] || 2011-11-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Samba (Italiano)]] || 2011-11-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Secure Shell (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]] || 2011-10-20 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[SLiM (Italiano)]] || 2013-01-02 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Small Business Server (Italiano)]] || n/a || n/a || n/a || '''Pagina italiana più aggiornata, contiene sottopagine''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]] || 2011-09-05 || n/a || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]] || 2011-02-21 || asa || n/a || n/a <br />
|-align="center"<br />
| [[SSH Keys (Italiano)]] || 2011-12-17 || n/a || n/a || '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sshfs (Italiano)]] || 2011-11-13 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Sudo (Italiano)]] || 2011-12-06 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Sugar (Italiano)]] || 2012-07-16 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[swap (Italiano)]] || 2012-09-17 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Synergy (Italiano)]] || 2012-09-04 || Kynikos || n/a || '''Cedibile''' <br />
|-align="center"<br />
| [[Table of Contents (Italiano)]] || 2012-09-04 || Kynikos || n/a || La struttura della lista viene aggiornata automaticamente e periodicamente da [[User:Kynikos.bot|Kynikos.bot]]<br />
|-align="center"<br />
| [[TeXLive (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[The Arch Way v2.0 (Italiano)]] || n/a || n/a || n/a || Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Thunar (Italiano)]] || 2012-12-24 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Thunderbird (Italiano)]] || n/a || n/a || n/a || Out of Date; scritta in inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]] || 2011-10-09 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[TuPac (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]] || 2012-02-26 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Twm (Italiano)]] || 2012-11-01 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]] || 2011-06-02 || Ninquitassar || n/a ||'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[USB Storage Devices (Italiano)]] || n/a || n/a || n/a || Out of date<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]] || 2012-01-31 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Uvesafb (Italiano)]] || 2011-10-17 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]] || 2012-02-07 || 4javier || n/a || n/a <br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]] || 2011-09-28 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Vim (Italiano)]] || 2012-05-15 || n/a || n/a || '''Da riallineare''' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 12 July 2012 (UTC)<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]] || 2012-01-19 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[VirtualBox (Italiano)]] || 2011-03-21 || ant84 || n/a || n/a <br />
|-align="center"<br />
| [[VMware (Italiano)]] || 2012-02-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Webmin (Italiano)]] || 2011-08-10 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Wicd (Italiano)]] || 2011-12-08 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Window Maker (Italiano)]] || 2012-11-05 || Veleno77 || n/a || n/a <br />
|-align="center"<br />
| [[Window Manager (Italiano)]] || 2012-02-02 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Wine (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]] || 2011-10-11 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[Xampp (Italiano)]] || n/a || n/a || n/a || out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[xf86-video-sis (Italiano)]] || 2012-10-06 || n/a || n/a || n/a <br />
|-align="center"<br />
| [[XFS (Italiano)]] || n/a || n/a || n/a || out of date; versione inglese segnata come "stub" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] || 2012-12-16 || umby213 || n/a || n/a <br />
|-align="center"<br />
| [[Yaourt (Italiano)]] || 2012-12-29 || umby213 || n/a || n/a <br />
|}<br />
<br />
==Staff tecnico==<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Coordinatore<br />
:# [[User:4javier|4javier]]<br />
:# [[User:Kynikos|Kynikos]] - [[ArchWiki:Administrators|Amministratore ArchWiki ]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
:# [[User:love89|Love89]]<br />
:# [[User:maveloth|maveloth]]<br />
:# [[User:nierro|Nierro]]<br />
:# [[User:Dariocent|Dario]]<br />
:# [[User:Ambro|Ambro]]<br />
<br />
==Ulteriori informazioni e supporto==<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum italiano].</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=243175Systemd (Italiano)2013-01-07T17:37:51Z<p>Ambro: Aggiornamento al 04.01.2013 11:05</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<br />
<br />
Se il vecchio file di configurazione {{ic|/etc/timezone}} esiste si può rimuovere tranquillamente, in quanto non è usato da systemd.<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 che Windows 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 />
==== 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 />
===== 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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
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 un DE 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 />
==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}}: 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Correzione di errori ==<br />
<br />
=== "Error: No space left on device" quando si prova ad avviare o a riavviare un servizio ===<br />
Nota: Non so se si tratta di una soluzione appropriata, ma a me appare funzionante<br />
<br />
Vedere il link: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]<br />
<br />
Grazie a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum] per la segnalazione del sito.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Apache_HTTP_Server_(Italiano)&diff=243172Apache HTTP Server (Italiano)2013-01-07T17:18:30Z<p>Ambro: </p>
<hr />
<div>[[Category:Web Server (Italiano)]]<br />
[[cs:LAMP]]<br />
[[de:LAMP Installation]]<br />
[[el:LAMP]]<br />
[[en:LAMP]]<br />
[[es:LAMP]]<br />
[[fr:Lamp]]<br />
[[pl:LAMP]]<br />
[[ru:LAMP]]<br />
[[sr:LAMP]]<br />
[[tr:LAMP]]<br />
[[zh-CN:LAMP]]<br />
{{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}<br />
[http://en.wikipedia.org/wiki/LAMP_%28software_bundle%29 LAMP] costituisce una combinazione comune di vari software utilizzati in molti server web: '''L'''inux, '''A'''pache, '''M'''ySQL, e '''P'''HP. Questo documento descrive i passi necessari per configurare un [http://httpd.apache.org Apache HTTP Server] su un sistema Arch Linux. Spiega inoltre come installare [[PHP]] e [[MySQL]] ed integrarli con il server Apache.<br />
<br />
Avendo bisogno di solo un server web per sviluppo e test, [[Xampp]] potrebbe essere la scelta migliore, oltre che la più facile.<br />
<br />
==Installazione==<br />
# pacman -S apache php php-apache mysql<br />
<br />
Questo documento presuppone che verranno installati Apache, PHP e MySQL insieme. Se lo si desidera tuttavia, è possibile installare Apache, PHP e MySQL separatamente e fare riferimento alle relative sezioni in seguito.<br />
<br />
{{Note|Nuovi utente e gruppo di default: Invece del gruppo "nobody", apache viene eseguito ora come utente/gruppo "http". È preferibile modificare il file httpd.conf in base a questo cambiamento, anche se è possibile eseguire httpd comunque.}}<br />
<br />
==Configurazione==<br />
<br />
===Apache===<br />
Per motivi di sicurezza, non appena Apache viene avviato dall'utente root (direttamente o tramite script di avvio) passa alla UID/GID specificata in {{ic|/etc/httpd/conf/httpd.conf}}<br />
<br />
* Verificare l'esistenza degli utenti http, cercando ''http'' nell'output del seguente comando:<br />
# grep http /etc/passwd<br />
<br />
* Creare l'utente http in caso non esista già:<br />
# useradd -d /srv/http -r -s /bin/false -U http<br />
:Questo crea l'utente http con la home directory {{ic|/srv/http/}}, come un account di sistema (-r), con una shell fasulla (-s {{ic|/bin/false}}) e crea un gruppo con lo stesso nome (-U).<br />
<br />
* Aggiungere questa riga in {{ic|/etc/hosts}} (se il file non esiste, crearlo):<br />
127.0.0.1 localhost.localdomain localhost<br />
:Se si preferisce un hostname differente, posizionarlo alla fine:<br />
127.0.0.1 localhost.localdomain localhost myhostname<br />
<br />
* Editare {{ic|/etc/[[rc.conf]]}}: Se nel primo passo è stato messo un hostname, la variabile {{Ic|HOSTNAME}} deve avere lo stesso valore; altrimenti, usare {{Ic|"localhost"}}:<br />
#<br />
# Networking<br />
#<br />
HOSTNAME="localhost"<br />
<br />
* Assicurarsi che l'hostname sia presente in {{ic|/etc/hosts}} o apache non potrà essere avviato. In alternativa, è possibile editare {{ic|/etc/httpd/conf/httpd.conf}} e commentare il modulo seguente:<br />
LoadModule unique_id_module modules/mod_unique_id.so<br />
<br />
* Personalizzare ora la propria configurazione: cambiare per lo meno {{ic|httpd.conf}} e {{ic|extra/httpd-default.conf}} secondo le proprie esigenze. Per ragioni di sicurezza, sarebbe preferibile modificare '''ServerTokens Full''' a '''ServerTokens Prod''' e '''ServerSignature On''' a '''ServerSignature Off''' in {{ic|extra/httpd-default.conf}}.<br />
<br />
* Per avviare il server HTTP lanciare da terminale :<br />
# /etc/rc.d/httpd start<br />
<br />
:Apache ora dovrebbe essere attivo. Testarlo visitando http://localhost/ da un browser. Si dovrebbe vedere una semplice pagina di test di Apache. In caso di errore 403, decommentare le righe seguenti in {{ic|/etc/httpd/conf/httpd.conf}}:<br />
Include conf/extra/httpd-userdir.conf<br />
<br />
* Per avviare Apache automaticamente al boot, editare {{ic|/etc/rc.conf}} e aggiungere il demone '''httpd''':<br />
DAEMONS=(... '''httpd''' ...)<br />
<br />
<br />
====Cartelle utente====<br />
* Se non si desidera che le cartelle dell'utente siano disponibili sul web (ad es. {{ic|~/public_html}} sulla macchina usata per l'accesso come http://localhost/~user/), commentare la seguente riga in {{ic|/etc/httpd/conf/httpd.conf}} dal momento che sono attivate di default:<br />
Include conf/extra/httpd-userdir.conf<br />
<br />
* È necessario che le autorizzazioni della home directory siano impostate correttamente in modo che Apache possa collegarvisi. La home directory e {{ic|~/public_html/}} devono essere eseguibili per gli altri ("resto del mondo"). Questo sembra essere accettabile:<br />
$ chmod o+x ~<br />
$ chmod o+x ~/public_html<br />
<br />
* Il modo più sicuro per condividere la propria cartella home con apache è quello di aggiungere '''http user''' nel gruppo al quale appartiene la cartella home. Per esempio, se la cartella home e le altre sotto-cartelle appartengono al gruppo '''piter''', tutto quello che si deve fare è:<br />
<br />
$ usermod -aG piter http<br />
<br />
* Naturalmente bisogna assegnare i permessi di ''lettura'' ed ''esecuzione'' a {{ic|~/}}, {{ic|~/public_html}}, e tutte le altre sotto-cartelle in {{ic|~/public_html}} ai membri del gruppo (gruppo '''piter''' in questo caso). Provare qualcosa di simile ('''modificando i comandi secondo necessità'''):<br />
<br />
$ chmod g+xr-w /home/''yourusername''<br />
$ chmod -R g+xr-w /home/''yourusername''/public_html<br />
<br />
{{Note|In questo modo non c'è bisogno di dare accesso alla propria cartella ad ogni singolo utente per dare accesso al '''http user'''. Solo l' '''http user''' ed altri potenziali utenti del gruppo '''piter''' avranno accesso alla propria cartella home.}}<br />
<br />
E poi<br />
<br />
$ /etc/rc.d/httpd restart<br />
<br />
per riavviare apache.<br />
<br />
====SSL====<br />
Creare certificato autofirmato (è possibile modificare le dimensioni della chiave e giorni di validità)<br />
# cd /etc/httpd/conf<br />
# openssl genrsa -des3 -out server.key 1024<br />
# openssl req -new -key server.key -out server.csr<br />
# cp server.key server.key.org<br />
# openssl rsa -in server.key.org -out server.key<br />
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt<br />
In {{ic|/etc/httpd/conf/httpd.conf}} decommentare la riga<br />
Include conf/extra/httpd-ssl.conf<br />
Riavviare apache<br />
# /etc/rc.d/httpd restart<br />
<br />
====Host virtuali====<br />
Se si desidera più di un host, assicurarsi di avere<br />
<pre><br />
# Virtual hosts<br />
Include conf/extra/httpd-vhosts.conf<br />
</pre><br />
in {{ic|/etc/httpd/conf/httpd.conf}}.<br />
<br />
In {{ic|/etc/httpd/conf/extra/httpd-vhosts.conf}} impostare gli host virtuali secondo l'esempio:<br />
<pre><br />
NameVirtualHost *:80<br />
<br />
#this first virtualhost enables: http://127.0.0.1, or: http://localhost, <br />
#to still go to /srv/http/*index.html(otherwise it will 404_error).<br />
#the reason for this: once you tell httpd.conf to include extra/httpd-vhosts.conf, <br />
#ALL vhosts are handled in httpd-vhosts.conf(including the default one),<br />
# E.G. the default virtualhost in httpd.conf is not used and must be included here, <br />
#otherwise, only domainname1.dom & domainname2.dom will be accessible<br />
#from your web browser and NOT http://127.0.0.1, or: http://localhost, etc.<br />
#<br />
<br />
<VirtualHost *:80><br />
DocumentRoot "/srv/http"<br />
ServerAdmin root@localhost<br />
ErrorLog "/var/log/httpd/127.0.0.1-error_log"<br />
CustomLog "/var/log/httpd/127.0.0.1-access_log" common<br />
<Directory /srv/http/><br />
DirectoryIndex index.htm index.html<br />
AddHandler cgi-script .cgi .pl<br />
Options ExecCGI Indexes FollowSymLinks MultiViews +Includes<br />
AllowOverride None<br />
Order allow,deny<br />
allow from all<br />
</Directory><br />
</VirtualHost><br />
<br />
<br />
<VirtualHost *:80><br />
ServerAdmin your@domainname1.dom<br />
DocumentRoot "/home/username/yoursites/domainname1.dom/www"<br />
ServerName domainname1.dom<br />
ServerAlias domainname1.dom<br />
<Directory /home/username/yoursites/domainname1.dom/www/><br />
DirectoryIndex index.htm index.html<br />
AddHandler cgi-script .cgi .pl<br />
Options ExecCGI Indexes FollowSymLinks MultiViews +Includes<br />
AllowOverride None<br />
Order allow,deny<br />
allow from all<br />
</Directory><br />
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
ServerAdmin your@domainname2.dom<br />
DocumentRoot "/home/username/yoursites/domainname2.dom/www"<br />
ServerName domainname2.dom<br />
ServerAlias domainname2.dom<br />
<Directory /home/username/yoursites/domainname2.dom/www/><br />
DirectoryIndex index.htm index.html<br />
AddHandler cgi-script .cgi .pl<br />
Options ExecCGI Indexes FollowSymLinks MultiViews +Includes<br />
AllowOverride None<br />
Order allow,deny<br />
allow from all<br />
</Directory><br />
</VirtualHost><br />
</pre><br />
<br />
Aggiungere i nomi dei propri host virtuali al file {{ic|/etc/hosts}} (NON è necessario se questi domini sono già vincolati, ma comunque non fa male):<br />
<pre>127.0.0.1 domainname1.dom<br />
127.0.0.1 domainname2.dom</pre><br />
<br />
Riavviare Apache:<br />
<pre>sudo /etc/rc.d/httpd restart</pre><br />
<br />
Se si impostano gli host virtuali nella propria cartella utente, a volte possono interferire con le impostazioni delle "Userdir" di Apache. Per evitare problemi disabilitare le "Userdir" decommentandole:<br />
<pre><br />
# User home directories<br />
#Include conf/extra/httpd-userdir.conf</pre><br />
<br />
Come già detto sopra, fare attenzione, dal momento che si dispone delle autorizzazioni appropriate:<br />
<pre>sudo chmod 0775 /home/yourusername/</pre><br />
<br />
Se si dispone di una quantità enorme di host virtuali, sarebbe comodo poterli disabilitare e abilitare facilmente. Si consiglia quindi di creare un file di configurazione per ogni host virtuale e memorizzarli tutti in una cartella, ad es: {{ic|/etc/httpd/conf/vhosts}}.<br />
Per prima cosa creare la cartella:<br />
<pre>sudo mkdir /etc/httpd/conf/vhosts</pre><br />
<br />
Quindi inserire i singoli file di configurazione all'interno:<br />
<pre>sudo nano /etc/httpd/conf/vhosts/domainname1.dom<br />
sudo nano /etc/httpd/conf/vhosts/domainname2.dom<br />
...</pre><br />
<br />
Come ultimo passo, includere le singole configurazioni a {{ic|/etc/httpd/conf/httpd.conf}}:<br />
<pre>#Enabled Vhosts:<br />
Include conf/vhosts/domainname1.dom<br />
#Include conf/vhosts/domainname1.dom</pre><br />
<br />
È possibile attivare e disattivare ogni singolo host virtuale commentandolo o decommentandolo.<br />
<br />
====Opzioni avanzate====<br />
Si potrebbe essere interessati a queste opzioni in {{ic|/etc/httpd/conf/httpd.conf}}:<br />
<br />
# Listen 80<br />
Questa è la porta su cui Apache rimarrà in ascolto. Per l'accesso a Internet con un router, sarà necessario impostare correttamente la porta.<br />
<br />
Se Apache è stato impostato per lo sviluppo locale è possibile che sia accessibile solo dal proprio computer. Modificare quindi questa riga:<br />
# Listen 127.0.0.1:80<br />
<br />
Questo è l'indirizzo email dell'amministratore che può essere trovato nelle pagine di errore:<br />
# ServerAdmin sample@sample.com<br />
<br />
Questa è la directory dove si dovrebbero mettere le proprie pagine web:<br />
# DocumentRoot "/srv/http"<br />
<br />
Modificarla se lo si desidera, ma non dimenticare di cambiare anche la<br />
<Directory "/srv/http"><br />
compatibilmente con le modifiche apportate a DocumentRoot, o probabilmente si riscontrerà l'errore 403 (mancanza di privilegi) quando si tenta di accedere al nuovo documento root. Non dimenticare di cambiare l'opzione "Deny" da tutte le righe, altrimenti si otterrà nuovamente l'errore 403.<br />
<br />
# AllowOverride None<br />
Questa direttiva nella sezione <Directory> è la causa per cui apache ignora completamente i file {{ic|.htaccess}}. Se si intende utilizzare la modalità "rewrite" o altre impostazioni nei file {{ic|.htaccess}}, è possibile consentire che le direttive dichiarate in quel file possano sovrascrivere la configurazione del server. Per maggiori informazioni fare riferimento a http://httpd.apache.org/docs/current/mod/core.html#allowoverride<br />
<br />
{{Note|In caso di problemi con la configurazione si può fare in modo che apache controlli la configurazione con:<br />
{{Ic|apachectl configtest}}}}<br />
<br />
===PHP===<br />
* Installare il pacchetto "php-apache" da extra con pacman.<br />
<br />
* Aggiungere questa riga a {{ic|/etc/httpd/conf/httpd.conf}}:<br />
:Inserirla nella lista "LoadModule", dove si preferisca, ma dopo {{Ic|LoadModule dir_module modules/mod_dir.so}}:<br />
LoadModule php5_module modules/libphp5.so<br />
<br />
:Inserire la riga seguente alla fine della lista "Include":<br />
Include conf/extra/php5_module.conf<br />
<br />
:Assicurarsi che la riga che segue sia decommentata in {{ic|httpd.conf}} nella sezione/(dopo la riga){{Ic|<IfModule mime_module>}}:<br />
TypesConfig conf/mime.types<br />
<br />
:Decommentare la seguente riga in {{ic|httpd.conf}} (opzionale):<br />
MIMEMagicFile conf/magic<br />
<br />
<br />
* Aggiungere questa riga in {{ic|/etc/httpd/conf/mime.types}}:<br />
application/x-httpd-php php<br />
<br />
<br />
{{Note|Se non è visibile {{ic|libphp5.so}} nella cartella dei moduli Apache ({{Ic|/etc/httpd/modules}}), si può aver dimenticato di installare il pacchetto ''php-apache''.}}<br />
<br />
* Se il proprio {{Ic|DocumentRoot}} non è {{Ic|/srv/http}}, aggiungerlo a {{Ic|open_basedir}} in {{ic|/etc/php/php.ini}} così:<br />
open_basedir=/srv/http/:/home/:/tmp/:/usr/share/pear/:/path/to/documentroot<br />
<br />
* Riavviare il servizio Apache per rendere effettive le modifiche:<br />
# /etc/rc.d/httpd restart<br />
<br />
* Creare il file {{ic|test.php}} nella cartella Apache DocumentRoot (Ad es. /srv/http/ o ~/public_html) ed all'interno inserire:<br />
<?php phpinfo(); ?><br />
<br />
* Assicurarsi di copiare questo file in {{Ic|~/public_html}} se si è permessa tale configurazione.<!-- e ricordarsi di renderlo eseguibile ({{Ic|chmod o+x test.php}}).--><br />
<br />
* Testare PHP: http://localhost/test.php o http://localhost/~myname/test.php<br />
<br />
:Se l'istruzione PHP non viene eseguita (si visualizza: <html>...</html>), controllare di avere "Includes" alla riga "Options" per la root directory. Inoltre, verificare che TypesConfig conf/mime.types sia decommentato nella sezione <IfModule mime_module>; si può anche provare ad aggiungere quanto segue a <IfModule mime_module> in {{ic|httpd.conf}}:<br />
AddHandler application/x-httpd-php .php<br />
<br />
====Opzioni avanzate====<br />
* Aggiungere, se può risultare comodo, un gestore di file per. phtml in {{ic|/etc/httpd/conf/extra/php5_module.conf}}:<br />
DirectoryIndex index.php index.phtml index.html<br />
<br />
* Se si desidera il modulo libGD, installare il pacchetto php-gd e decommentare la seguente riga in {{ic|/etc/php/php.ini}}:<br />
{{Note|php-gd richiede libpng, libjpeg, e freetype2}}<br />
;extension=gd.so<br />
a<br />
extension=gd.so<br />
<br />
:Prestare attenzione a quale estensione si vuole decommentare: spesso è presente un qualche commento esplicativo prima della riga stessa.<br />
<br />
<br />
* Se si desidera visualizzare gli errori di debug del codice php, modificare questa riga in {{ic|/etc/php/php.ini}}:<br />
display_errors=Off<br />
a<br />
display_errors=On<br />
<br />
* Se si desidera il modulo mcrypt, installare il pacchetto php-mcrypt e decommentare in {{ic|/etc/php/php.ini}}:<br />
;extension=mcrypt.so<br />
a<br />
extension=mcrypt.so<br />
{{Warning|In caso di questo tipo di errore:<br />
<pre><br />
[XXX Debug] PHP Notice: in file /index.php on line 86: date(): It is not safe to rely on the system'XXXX<br />
[XXX Debug] PHP Notice: in file /index.php on line 86: getdate(): It is not safe to rely on the system's timezone settings.XXXX</pre><br />
}}<br />
modificare questa riga in {{ic|/etc/php/php.ini}} <br />
;date.timezone = <br />
a <br />
date.timezone = Europe/Berlin<br />
{{note| Ulteriori informazioni riguardo [http://php.net/manual/en/datetime.configuration.php#ini.date.timezone Time Zone in PHP] }}<br />
riavviare httpd con <br />
# /etc/rc.d/httpd restart<br />
<br />
==== Utilizzare php5 con apache2-mpm-worker e mod_fcgid ====<br />
<br />
Decommentare quanto segue in {{ic|/etc/conf.d/apache}}:<br />
HTTPD=/usr/sbin/httpd.worker<br />
Decommentare quanto segue in {{ic|/etc/httpd/conf/httpd.conf}}:<br />
Include conf/extra/httpd-mpm.conf<br />
Installare i pacchetti mod_fcgid e php-cgi:<br />
# pacman -S mod_fcgid php-cgi<br />
Creare {{ic|/etc/httpd/conf/extra/php5_fcgid.conf}} ed aggiungerci il seguente contenuto:<br />
<pre><br />
# Required modules: fcgid_module<br />
<br />
<IfModule fcgid_module><br />
AddHandler php-fcgid .php<br />
AddType application/x-httpd-php .php<br />
Action php-fcgid /fcgid-bin/php-fcgid-wrapper<br />
ScriptAlias /fcgid-bin/ /srv/http/fcgid-bin/<br />
SocketPath /var/run/httpd/fcgidsock<br />
SharememPath /var/run/httpd/fcgid_shm<br />
PHP_Fix_Pathinfo_Enable 1<br />
# Path to php.ini – defaults to /etc/phpX/cgi<br />
DefaultInitEnv PHPRC=/etc/php/<br />
# Number of PHP childs that will be launched. Leave undefined to let PHP decide.<br />
#DefaultInitEnv PHP_FCGI_CHILDREN 3<br />
# Maximum requests before a process is stopped and a new one is launched<br />
#DefaultInitEnv PHP_FCGI_MAX_REQUESTS 5000<br />
<Location /fcgid-bin/><br />
SetHandler fcgid-script<br />
Options +ExecCGI<br />
</Location><br />
</IfModule><br />
</pre><br />
<br />
Creare le directory necessarie e creare dei link simbolici per php wrapper:<br />
# mkdir /srv/http/fcgid-bin<br />
# ln -s /usr/bin/php-cgi /srv/http/fcgid-bin/php-fcgid-wrapper<br />
<br />
Editare {{ic|/etc/httpd/conf/httpd.conf:}}<br />
#LoadModule php5_module modules/libphp5.so<br />
LoadModule fcgid_module modules/mod_fcgid.so<br />
Include conf/extra/php5_fcgid.conf<br />
Assicurarsi che {{ic|/etc/php/php.ini}} abbia le direttive abilitate:<br />
cgi.fix_pathinfo=1<br />
Bisognerà riavviare apache:<br />
# rc.d restart httpd<br />
<br />
===MySQL===<br />
* Configurare MySQL come descritto da [[MySQL]].<br />
<br />
* Editare {{ic|/etc/php/php.ini}} (reperibile in {{ic|/usr/etc}} sui sistemi più datati) e decommentare la seguente riga (''Rimuovendo {{Ic|;}}''):<br />
;extension=mysqli.so<br />
;extension=mysql.so<br />
<br />
<br />
:'''Attenzione: '''Alcuni utenti hanno segnalato errori di battitura su questa riga. Assicurarsi che legga {{Ic|;extension&#61;mysql.so}} e non {{Ic|;extension&#61;msql.so}}.<br />
<br />
* È possibile aggiungere utenti con meno privilegi per gli script web modificando le tabelle nel database {{Ic|mysql}}. Occorre riavviare MySQL per rendere effettive le modifiche. Ricordarsi di controllare la tabella {{Ic|mysql/users}}. Se c'è una seconda voce per root e il proprio hostname è sprovvisto di password, chiunque potrebbe ottenere l'accesso completo da tale host. Vedere la sezione successiva per questo tipo di problematiche.<br />
<br />
* Eseguire in un terminale:<br />
# /etc/rc.d/mysqld start<br />
<br />
* Potrebbe anche essere necessario riavviare Apache. Da terminale:<br />
# /etc/rc.d/httpd restart<br />
<br />
* MySQL dovrebbe essere in esecuzione ora. Impostare la password di root e testarlo eseguendo:<br />
# mysqladmin -u root password ''password''<br />
# mysql -u root -p<br />
<br />
:Digitare ''exit'' per uscire dalla riga di comando del client MySQL <br />
<br />
* Editare {{ic|/etc/rc.conf}} (per avviare MySQL all'avvio):<br />
DAEMONS=(... '''mysqld''' ...)<br />
Oppure aggiungere questa riga a {{ic|rc.local}}:<br />
/etc/rc.d/mysqld start<br />
<br />
* Potrebbe anche essere necessario modificare {{ic|/etc/mysql/my.cnf}} e decommentare {{Ic|skip-networking}} da così:<br />
skip-networking<br />
a<br />
#skip-networking<br />
<br />
{{Tip|Si consiglia di installare [[PhpMyAdmin|phpmyadmin]], {{AUR|mysql-workbench}} o [[Adminer|adminer]] per lavorare con i database.}}<br />
<br />
<br />
==Vedere anche==<br />
* [[MySQL]] - Articolo wiki per MySQL<br />
* [[PhpMyAdmin]] - Interfaccia web per MySQL tipica degli ambienti LAMP<br />
* [[Adminer]] - Un completo strumento di gestione dei database disponibile per MySQL, PostgreSQL, SQLite, MS SQL e Oracle<br />
* [[Xampp]] - Server-web autonomo che supporta PHP, Perl e MySQL<br />
<br />
==Collegamenti esterni==<br />
* http://www.apache.org/<br />
* http://www.php.net/<br />
* http://www.mysql.com/<br />
* http://www.akadia.com/services/ssh_test_certificate.html<br />
* http://wiki.apache.org/httpd/CommonMisconfigurations</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=241438Systemd (Italiano)2012-12-23T23:57:00Z<p>Ambro: Allineamento al 23.12.2012 06:30</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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-suspend.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-resume.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 -9 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 />
===== 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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
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 un DE 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 />
==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}}: 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Correzione di errori ==<br />
<br />
=== "Error: No space left on device" quando si prova ad avviare o a riavviare un servizio ===<br />
Nota: Non so se si tratta di una soluzione appropriata, ma a me appare funzionante<br />
<br />
Vedere il link: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]<br />
<br />
Grazie a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum] per la segnalazione del sito.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=239965Systemd (Italiano)2012-12-11T20:34:23Z<p>Ambro: Allineamento al 11.12.2012 19.53</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
== Correzione di errori ==<br />
<br />
=== "Error: No space left on device" quando si prova ad avviare o a riavviare un servizio ===<br />
Nota: Non so se si tratta di una soluzione appropriata, ma a me appare funzionante<br />
<br />
Vedere il link: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]<br />
<br />
Grazie a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum] per la segnalazione del sito.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=239961Systemd (Italiano)2012-12-11T20:13:46Z<p>Ambro: Allineamento al 11.12.2012 19.53</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<br />
<br />
* Se si montano dispositivi LVM in fstab il proprio sistema andrà in attesa e poi in time out. Attendere che vada in time out e inserire la password di root nella console di emergenza. Dopodiché digitare {{ic|systemctl enable lvm}} per attivare lvm in systemd. Dopo un altro riavvio i dispositivi lvm dovrebbero essere disponibili.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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.service<br />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=238086Systemd (Italiano)2012-12-03T22:58:26Z<p>Ambro: Allineamento al 03.12.2012 21:02</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 [https://wiki.archlinux.org/index.php/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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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.service<br />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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|systemctl -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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=237260Systemd (Italiano)2012-11-28T23:28:11Z<p>Ambro: Allineamento al 28.11.2012 02:00</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 [https://wiki.archlinux.org/index.php/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 {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare il servizio {{ic|lvm-on-crypt}} anch'esso fornito dal pacchetto {{pkg|lvm2}}:<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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|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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== 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 un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=236805Systemd (Italiano)2012-11-25T23:46:29Z<p>Ambro: Allineamento al 24.11.2012 16:58</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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}}, con [[Daemons_List|nomi differenti]]. ).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 {{ic|lvm-monitoring.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm-monitoring.service<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=236639Systemd (Italiano)2012-11-24T13:50:00Z<p>Ambro: Allineamento al 23.11.2012 16:52</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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-cairo}} e {{Pkg|python2-gobject}} per usarlo.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=236307Systemd (Italiano)2012-11-21T20:48:21Z<p>Ambro: fix type</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=236306Systemd (Italiano)2012-11-21T20:47:47Z<p>Ambro: Allineamento al 20.11.2012 16:56</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
{merge|Improve Boot Performance|reason=Dovrebbe essere spostato l'articolo per coprire l'argomento.}}<br />
<br />
Vedere [[Improve Boot Performance]].<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=236042Systemd (Italiano)2012-11-19T22:46:22Z<p>Ambro: Allineamento al 18.11.2012 13:42</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
* La rimozione del pacchetto {{Pkg|initscripts}} comprometterà la compatibilità con {{ic|rc.conf}}. Fare attenzione se si ha una configurazione di rete statica o se si usano dei demoni che non sono ancora migrati a systemd. Vedere [[#Emulazione_degli_Initscripts|la sezione Emulazione degli Initscripts]] per maggiori dettagli e come i due sistemi possono coesistere.<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)/FAQ_(Italiano)&diff=235763Systemd (Italiano)/FAQ (Italiano)2012-11-17T09:57:50Z<p>Ambro: Allineamento al 13.11.2012 20:16</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services (Italiano)]]<br />
[[Category:Boot process (Italiano)]]<br />
[[en:Systemd FAQ]]<br />
[[es:Systemd FAQ]]<br />
[[zh-CN:Systemd FAQ]]<br />
== FAQ ==<br />
<br />
Per una lista aggiornata dei problemi conosciuti, vedere il [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].<br />
<br />
{{FAQ<br />
|question=Perché non ricevo messaggi di log sulla console?<br />
|answer=Si deve configurare il proprio livello di log. Un tempo, {{ic|/etc/rc.sysinit}} lo faceva e configurava il livello di log di dmesg a {{ic|3}}, che era un ragionevole livello. Ora aggiungere {{ic|1=loglevel=3}} o {{ic|quiet}} ai [[kernel parameters|parametri del kernel]].}}<br />
<br />
{{FAQ<br />
|question=Come posso cambiare il numero di console funzionanti di default?<br />
|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/}} :<br />
<br />
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service<br />
# systemctl start getty@tty9.service<br />
<br />
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :<br />
<br />
# rm /etc/systemd/system/getty.target.wants/getty@{tty5,tty6}.service<br />
# systemctl stop getty@tty5.service getty@tty6.service<br />
Gli utenti possono cambiare il numero delle console anche editando {{ic|/etc/systemd/logind.conf}} e cambiando il valore di {{ic|NAutoVTs}}. Seguendo questo metodo, l'attivazione al bisogno sarà preservata, mentre con il metodo iniziale semplicemente si avranno le console funzionanti al boot.<br />
<br />
systemd non usa il file /etc/inittab.<br />
<br />
{{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.}}}}<br />
<br />
<br />
{{FAQ<br />
|question=Come posso ottenere un output più dettagliato durante l'avvio?<br />
|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.<br />
<br />
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}}.}}<br />
<br />
{{FAQ<br />
|question=Come evitare che la console sia pulita dopo l'avvio?<br />
|answer=Creare un file g{{ic|getty@tty1.service}} personalizzato copiando {{ic|/usr/lib/systemd/system/getty@.service}} in {{ic|/etc/systemd/system/getty@tty1.service}} e cambiando {{ic|TTYVTDisallocate}} in {{ic|no}}.<br />
}} e si permette l'esportazione di {{ic|LANG}} in {{ic|/etc/locale.conf}}<br />
<br />
{{FAQ<br />
|question=Quali opzioni del kernel occorrono attive nel mio kernel nel caso non usassi il kernel Arch ufficiale?<br />
|answer=I Kernels precedenti al 2.6.39 non sono supportati.<br />
<br />
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:<br />
<br />
{{bc|1='''General setup'''<br />
CONFIG_FHANDLE=y<br />
CONFIG_AUDIT=y (raccomandata)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non raccomandata, può danneggiare la compatibilità con sysvinit)<br />
CONFIG_CGROUPS=y<br />
'''-> Namespaces support'''<br />
CONFIG_NET_NS=y (per reti private)<br />
'''Networking support -> Networking options'''<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>m] (altamente raccomandata)<br />
'''Device Drivers'''<br />
'''-> Generic Driver Options'''<br />
CONFIG_UEVENT_HELPER_PATH=""<br />
CONFIG_DEVTMPFS=y<br />
CONFIG_DEVTMPFS_MOUNT=y (richiesta se non si usa un initramfs)<br />
'''-> Real Time Clock'''<br />
CONFIG_RTC_DRV_CMOS=y (altamente raccomandata)<br />
'''File systems'''<br />
CONFIG_FANOTIFY=y (richiesta per readahead)<br />
CONFIG_AUTOFS4_FS=[y<nowiki>|</nowiki>m]<br />
'''-> Pseudo filesystems'''<br />
CONFIG_TMPFS_POSIX_ACL=y (raccomandata se si vuole usare pam_systemd.so)}}}}<br />
<br />
{{FAQ<br />
|question=Quali altre unità dipendono da una unità?<br />
|answer=Per esempio, se si vuole evidenziare quali servizi e target attiva {{ic|multi-user.target}}, si usi qualcosa del genere: <br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}<br />
<br />
Invece di {{ic|Wants}} si può provare {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} per i rispettivi tipi di dipendenza e il loro contrario.}}<br />
<br />
{{FAQ<br />
|question=Il mio computer si spegne, ma l'alimentatore resta acceso.<br />
|answer=Usare<br />
<br />
$ systemctl poweroff<br />
<br />
invece di {{ic|systemctl halt}}.}}<br />
<br />
{{FAQ<br />
|question=Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?<br />
|answer=Assicurarsi di usare <br />
<br />
# systemctl enable dmraid.service<br />
}}<br />
<br />
{{FAQ<br />
|question=Come posso fare in modo che uno script sia eseguito al boot?<br />
|answer=Creare un nuovo file in {{ic|/etc/systemd/system}} (e.g. "myscript".service) e aggiungere il seguente contenuto:<br />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service] <br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Poi<br />
<br />
# systemctl enable "myscript".service<br />
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato.<br />
'''Nota:''' Nel caso si voglia avviare uno script di schell, assicurarsi di avere<br />
#!/bin/sh<br />
<br />
nella prima riga dello script. Non scrivere qualcosa come<br />
<br />
ExecStart=/bin/sh /path/to/script.sh # NON FUNZIONA<br />
<br />
perché non funziona.}}<br />
<br />
{{FAQ<br />
|question=Lo stato del .service dice "active (exited)" in verde. (per iptables)<br />
|answer=Ciò è perfettamente normale.<br />
Nel caso specifico di iptables è perché non c'è nessun demone da avviare, è controllato dal kernel. Tuttavia esiste dopo che le regole sono state caricate.<br />
Per verificare se le regole di iptables sono state caricate correttamente:<br />
{{bc|# iptables --list}}<br />
}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=Questo accade quando si usa {{ic|systemctl enable}} e si tenta di creare il link simbolico in {{ic|/etc/systemd/system/}} ed esiste già. Di solito accade quando si passa da un display manager ad un altro (per esempio da GDM a KDM, che possono essere abilitati con {{ic|gdm.service}} e {{ic|kdm.service}}, rispettivamente) e il link simbolico corrispondente {{ic|/etc/systemd/system/display-manager.service}} esiste già.<br />
Per risolvere il problema usare {{ic|systemctl -f enable}} per sovrascrivere link simbolici già esistenti.<br />
}}</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=235762Systemd (Italiano)2012-11-17T09:56:29Z<p>Ambro: Allineamento al 16.11.2012 23.46</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=235591Systemd (Italiano)2012-11-15T21:57:08Z<p>Ambro: Allineamento al 15.11.2012 11:13</p>
<hr />
<div>{{DISPLAYTITLE:systemd (Italiano)}}<br />
[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* Controllare se si sta già utilizzando systemd con il comando {{ic| cat /proc/1/comm}}, dove l'output {{ic| init}} sta per sysvinit e {{ic|systemd}} per systemd.<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla [[kernel line|riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario (opzionale).<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza [[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ qui] per maggiori informazioni.}}<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} e {{ic|man 7 archlinux}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) mostra chiaramente che si dovrebbe creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=235212Systemd (Italiano)2012-11-13T20:47:58Z<p>Ambro: fix type</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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''' [https://bugs.archlinux.org/task/31377 non] può essere usato all'avvio del sistema.<br />
<br />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza [[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ qui] per maggiori informazioni.}}<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) e timedatectl(1) suggeriscono di creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=235211Systemd (Italiano)2012-11-13T20:47:11Z<p>Ambro: Allineamento al 13.11.2012 13:02</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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''' [https://bugs.archlinux.org/task/31377 non] può essere usato all'avvio del sistema.<br />
<br />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<!-- NON FARE UN LINK ASSOLUTO, archlinux(7) e timedatectl(1) suggeriscono di creare un link simbolico relativo --><br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234783Systemd (Italiano)2012-11-10T23:56:26Z<p>Ambro: /* Configurazione nativa */</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario '''root:root'''}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234782Systemd (Italiano)2012-11-10T23:55:17Z<p>Ambro: /* Installazione */</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==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 />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234780Systemd (Italiano)2012-11-10T23:51:41Z<p>Ambro: /* Installazione */</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
{{Nota|{{pkg|systemd}} e {{pkg|systemd-sysvcompat}} sono entrambi presenti di default nei nuovi media di installazione dal [http://www.archlinux.it/forum/viewtopic.php?f=15&t=15572/ 13 Ottobre 2012].}}<br />
La seguente sezione è dedicata alle installazioni di Arch Linux che ripiegano ancora su {{pkg|sysvinit}} e {{pkg|initscripts}} e che non sono ancora migrate a {{pkg|systemd}}.<br />
<br />
# Installare {{pkg|systemd}} e aggiungere il seguente comando alla riga 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>}} (il quale equivale a ciò che si trova nella sezione {{ic|DAEMONS}}).<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 />
# Procedere rimuovendo {{pkg|initscripts}} e {{pkg|sysvinit}} dal sistema e installando {{pkg|systemd-sysvcompat}}.<br />
# Infine, rimuovere il parametro {{ic|1=init=/usr/lib/systemd/systemd}} in quanto non è più necessario.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234779Systemd (Italiano)2012-11-10T23:43:53Z<p>Ambro: Allineamento al 11.11.2012 00:14</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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 FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Considerazioni prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
{{Nota|{{pkg|systemd}} e {{pkg|systemd-sysvcompat}} sono entrambi presenti di default nei nuovi media di installazione dal [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 13 Ottobre 2012].}}<br />
The following section is aimed at Arch Linux installations which still rely on {{pkg|sysvinit}} and {{pkg|initscripts}} which have not migrated to {{pkg|systemd}}.<br />
<br />
# Install {{pkg|systemd}} and append the following to your kernel command line: {{ic|1=init=/usr/lib/systemd/systemd}}<br />
# Once completed you may enable any desired services via the use of {{ic|systemctl enable <service_name>}} (this roughly equates to what you included in the {{ic|DAEMONS}} array).<br />
# Reboot your system and verify that {{ic|systemd}} is currently active by using the following command: {{ic|$ cat /proc/1/comm}}. This should return the string {{ic|systemd}}.<br />
# Proceed to remove {{pkg|initscripts}} and {{pkg|sysvinit}} from your system and install {{pkg|systemd-sysvcompat}}.<br />
# Finally, remove the {{ic|1=init=/usr/lib/systemd/systemd}} parameter as it is no longer required.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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. Le nuove versioni stanno implementando tale funzionalità.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234469Systemd (Italiano)2012-11-08T21:12:21Z<p>Ambro: Allineamento al 08.11.2012 01:35</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234344Systemd (Italiano)2012-11-07T22:23:52Z<p>Ambro: Allineamento al 07.11.2012 18:35</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows 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 />
==== 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}}. 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi [http://en.wikipedia.org/wiki/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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234140Systemd (Italiano)2012-11-06T22:06:01Z<p>Ambro: Allineamento al 06.11.2012 11:44</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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}}. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi [http://en.wikipedia.org/wiki/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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: {{ic|suspend}} o {{ic|hibernate}}, 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}} o {{ic|systemd-hibernate.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}} o {{ic|hibernate.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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per maggiori dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|La via raccomandata per rimpiazzare {{ic|/etc/rc.local}} è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la [[#Scrivere_i_files_.service_personalizzati|sezione]] corrispondente.}}<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=234077ArchWiki:Translation Team (Italiano)2012-11-06T14:12:03Z<p>Ambro: /* Articoli secondari */</p>
<hr />
<div>[[Category:ArchWiki (Italiano)]]<br />
[[en:ArchWiki Translation Team]]<br />
[[es:ArchWiki Translation Team]]<br />
[[hr:ArchWiki Translation Team]]<br />
[[pl:ArchWiki Translation Team]]<br />
[[tr:ArchWiki_Çeviri_Ekibi]]<br />
[[zh-CN:ArchWiki Translation Team]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questa pagina è dedicata a tutti coloro che desiderano collaborare per fornire un supporto di traduzione, correzione e mantenimento delle pagine italiane di ArchWiki. Vengono inoltre fornite tutte le informazioni necessarie per un corretto uso delle traduzioni.}}<br />
{{Article summary heading|Correlati}}<br />
{{Article summary wiki|Help:Editing (Italiano)}}<br />
{{Article summary wiki|Help:Style (Italiano)}}<br />
{{Article summary wiki|Help:Reading}}<br />
{{Article summary wiki|ArchWiki:About (Italiano)}}<br />
{{Article summary heading|Fonti Utili}}<br />
{{Article summary text|Alcuni articoli utili per aiutare nella traduzione: }}<br />
{{Article summary text|1=[http://http://www.archlinux.it/forum/viewtopic.php?f=19&t=1087 Strumenti utili per i traduttori]}}<br />
{{Article summary text|[http://tp.linux.it/buona_traduzione.html Regole per una buona traduzione]}}<br />
{{Article summary end}}<br />
<br />
Un Wiki è una collezione di documenti ipertestuali che viene aggiornata dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il testo può essere modificato da tutti gli utenti registrati, con lo scopo di condividere, scambiare, immagazzinare e ottimizzare la conoscenza in modo collaborativo.<br />
<br />
Proprio con questo intento, la [http://www.archlinux.it/ comunità ufficiale italiana] di Arch Linux ha fondato l'[[ArchWiki Translation Team (Italiano)|ArchWiki Translation Team]], un gruppo aperto e collaborativo di utenti, con lo scopo di allineare la documentazione italiana con quella inglese e tenerla costantemente aggiornata, in modo da offrire il miglior servizio possibile alla propria comunità. <br />
<br />
Come in ogni progetto collaborativo c'è sempre bisogno di utenti disponibili. Se volete aiutare la comunità italiana ad avere una documentazione sempre efficace, aggiornata e più ampia possibile, considerate la possibilità di unirvi a questo progetto. Ogni riferimento è reperibile sul forum ufficiale italiano in [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 questa discussione] dove potete '''segnalare la vostra disponibilità'''.<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i revisori==<br />
<br />
===Organizzazione interna===<br />
<br />
Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati ad uno precedentemente preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi.<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano, e ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità e verranno ''taggate'' con appositi template da inserire ad inizio articolo, per segnalare che la pagina è in fase di lavorazione:<br />
;Nel caso di Aggiornamenti e Revisioni:{{ic|<nowiki> {{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:{{ic|<nowiki>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di tradurre dell'eventuale testo antecedente e dei menu "Summary".<br />
<br />
===Linee guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
# Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
# Scrivere sempre in forma indiretta. (Es: {{ic|aprire un terminale e digitare}}... è più corretto rispetto ad {{ic|apri il terminale e digita}})<br />
# Utilizzare '''sempre''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità di poter correggere immediatamente eventuali errori.<br />
# É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare:<br />
#; <nowiki>{{ic|testo}}</nowiki>: quando si è in presenza del path di un file. (Es. {{ic|<nowiki>{{ic|/etc/fstab}}</nowiki>}}, o per evidenziare un modulo, comando o una stringa di configurazione. Es: {{ic|<nowiki>Si può utilizzare {{ic|iwconfig}} per configurare la rete...</nowiki>}} . <br />
#; <nowiki>{{bc|comando}}</nowiki>: quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: {{ic|Da terminale dare il comando <nowiki>{{bc|# iwconfig}}</nowiki>}}, a volte basta dare un enter e scrivere il comando preceduto da uno spazio bianco.<br />
#; <nowiki>{{hc|intestazione|contenuto}}</nowiki>: questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, es: {{ic|<nowiki>{{hc|nome del file/comando|contenuto di un file o l'output di un comando}}</nowiki>}}.<br />
#; <nowiki>{{keypress|tasto_funzione}}</nowiki>: quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: {{ic|premere <nowiki>{{keypress|Invio}}</nowiki> per continuare}}. <br />
#;<nowiki>{{pkg|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente nei repositori ufficiali, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere '{{ic|<nowiki>Installare linux-lts con : {{bc|pacman -S linux-lts}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>[[pacman (Italiano)|Installare]] il pacchetto {{pkg|linux-lts}}</nowiki>}}, il riferimento al wiki di Pacman è necessario solo la prima volta nell'articolo, nel caso di ripetitivi indicazioni sui pacchetti si può omettere. Es: {{ic|<nowiki>è possibile installare anche il pacchetto {{pkg|linux-lts-headers}}</nowiki>}}.<br />
#;<nowiki>{{AUR|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente in AUR, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere {{ic|<nowiki>Installare linux-lts-ck con : {{bc|yaourt -S linux-lts-ck}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>Installare il pacchetto {{AUR|linux-lts-ck}}, reperibile su [[ARU (Italiano)|AUR]]</nowiki>}},l'aggiunta del riferimento al wiki italiano di AUR è necessaria la prima volta per rimandare gli utenti a conoscerne l'uso. <br> <span style="position:relative; left:-2em;">{{Nota|1=In caso di errori del template dovuto a particolari caratteri, potrebbe essere necessario aggiungere '''1=''' prima del contenuto . La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}}</span> <br />
# É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. {{ic|Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti....}}), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (es: {{ic|<nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>}})<br />
# Per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
# Per quanto riguarda le traduzioni si ricorda che '''i primi revisori siete voi stessi'''. Di conseguenza:<br />
#* Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
#* Controllate che il contesto risulti corretto sia nel contenuto che nella forma e di facile comprensione, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
# Si consiglia di '''commentare sempre''' le modifiche che si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili.<br />
<br />
{{Nota|1=Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina. Per ogni dubbio potete chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum]}}<br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
===Pagine ad alta priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[dm-crypt with LUKS (Italiano)]]<br />
| Pagina da allineare e tradurre<br />
| maveloth<br />
| in corso<br />
|-<br />
| [[Disk_Encryption (Italiano)]]<br />
| Pagina da completare la traduzione<br />
| Dario<br />
| in corso<br />
|-<br />
|}<br />
<br />
=== Pagine a bassa priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Android (Italiano)]]<br />
| <br />
| SirX<br />
| In corso<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[PostgreSQL (Italiano)]]<br />
| Traduzione incompleta<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
==Revisioni==<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero: yyyy-mm-gg (es. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all<nowiki>'</nowiki>'''adozione''' del medesimo.<br />
<br />
===Adottare un wiki===<br />
<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e l'allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni:<br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra), oppure molto semplicemente andando sul wiki da seguire premere sul link '''Segui''' situato affianco a "Cronologia".<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
:{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc).<br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
===Tabella riassuntiva dei wiki revisionati e adottati===<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in due tabelle a seconda delle priorità ([[ArchWiki_Translation_Team_(Italiano)#Articoli Principali|Articoli Princpali]] e [[ArchWiki_Translation_Team_(Italiano)#Articoli Secondari|Articoli Secondari]]), in modo da avere le principiali guide di riferimento sempre aggiornate e sotto controllo. Lo scopo è quello di adottare per prima le pagine contenute nella tabella Articoli Principali, ed in un secondo momento occuparci degli altri articoli. Il contenuto delle tabelle viene discusso sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 froum] e può variare in base alle esigenze della comunità.<br />
<br />
Le tabelle contengono cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Redirect Ita''' - Vengono immessi qui i wiki con titolo italiano che hanno un ''redirect'' al wiki tradotto.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore. Qui immettendo '''Cedibile''' si rende pubblica la volontà di lasciare l'adozione di un wiki (in tal casoeliminare anche il proprio nome dalla colonna ''Revisore'').<br />
<br />
Le colonne contengono un link ''rapido'' di consultazione che effettua un ordinamento alfabetico.<br />
<br />
==== Articoli principali ====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center" <br />
| [[Advanced Linux Sound Architecture (Italiano)]] || 2012-02-22 || 4javier || ||<br />
|-align="center"<br />
| [[AMD Catalyst (Italiano)]] || 2012-11-06 || umby213 || || <br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]] || 2012-09-04 || Kynikos || || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]] || 2012-02-07 || 4javier || || <br />
|-align="center"<br />
| [[Arch Linux (Italiano)]] || 2012-11-06 || icetux || ||<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]] || 2012-09-06 || Kynikos || || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[ATI (Italiano)]]<br />
| 2012-02-20<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]]<br />
| 2012-11-04<br />
| Veleno77 <br />
| [[Guida per Principianti]]<br />
|<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]]<br />
| 2012-10-04<br />
| icetux <br />
| [[Configurazione della Rete]]<br />
|<br />
|-align="center"<br />
| [[CUPS (Italiano)]]<br />
| 2012-09-22<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[FAQ (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
| [[Domande Frequenti]]<br />
| la versione inglese sta variando molto, appena si stabilizza ri-allineo ;) --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 11:23, 22 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fstab (Italiano)]]<br />
| 2012-10-28<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[GNOME (Italiano)]]<br />
| 2011-12-3<br />
| Cylon<br />
|<br />
| In allineamento<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
| <br />
|-align="center"<br />
| [[Help:Style (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Installation Guide (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| [[Guida all'installazione]]<br />
| ''Official Installation Guide'' è redirect a questa pagina<br />
|-align="center"<br />
| [[Intel (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[KDE (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[Laptop (Italiano)]]<br />
| 2012-10-24<br />
| Nierro<br />
| <br />
|<br />
|--align="center"<br />
| [[Locale (Italiano)]]<br />
| 2012-10-07<br />
| Veleno77<br />
| <br />
|<br />
|-align="center"<br />
| [[Main Page (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Makepkg (Italiano)]]<br />
| 2012-02-28<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Nouveau (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[NVIDIA (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]]<br />
| 2012-10-04<br />
| icetux<br />
| [[Repository Ufficiali]]<br />
|<br />
|-align="center"<br />
| [[Openbox (Italiano)]]<br />
| 2012-02-07<br />
| 4javier <br />
|<br />
|<br />
|-align="center"<br />
| [[Pacman (Italiano)]]<br />
| 2012-09-18<br />
| Kynikos<br />
|<br />
| '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]]<br />
| 2012-01-19<br />
| Ninquitassar<br />
|<br />
| <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio/Examples (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[RAID (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Start X at Login (Italiano)]]<br />
| 2011-09-20<br />
| Hilinus<br />
| [[Far partire X al boot]]<br />
|<br />
|- align="center"<br />
| [[Syslinux (Italiano)]]<br />
| 2012-08-01<br />
| Hilinus<br />
| <br />
| <br />
|-align="center"<br />
| [[Systemd (Italiano)]]<br />
| 2012-11-05<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[Systemd FAQ (Italiano)]]<br />
| 2012-11-04<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[SysVinit (Italiano)]]<br />
| 2012-11-01<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]]<br />
| 2012-09-06<br />
| icetux<br />
| [[Il Metodo Arch]]<br />
|<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Udev (Italiano)]]<br />
| 2011-12-08<br />
| ninquitassar<br />
|<br />
|<br />
|-align="center"<br />
| [[Unified Extensible Firmware Interface (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
| <br />
|-align="center"<br />
| [[USB Installation Media (Italiano)]]<br />
| 2012-10-06<br />
| umby213<br />
| [[Installare da supporto USB]]<br />
|<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]]<br />
| 2012-11-06<br />
| Veleno77<br />
| [[Utenti e Gruppi]]<br />
| <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] <br />
| 2012-02-13<br />
| Hilinus<br />
| [[Configurazione Wireless]]<br />
|<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]]<br />
| 2012-02-07<br />
| Hilinus<br />
| <br />
|<br />
|-align="center"<br />
| [[Xfce (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Xorg (Italiano)]] <br />
| 2011-12-06<br />
| ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
====Articoli secondari====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Acer Extensa 5220 (Italiano)]]<br />
|<br />
|<br />
|<br />
| ok --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ACPI modules (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Acpid (Italiano)]]<br />
| 2012-10-13<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Activating Numlock on Bootup (Italiano)]]<br />
|<br />
|<br />
| [[Attivare Numlock all'Avvio]]<br />
| Out of date<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]]<br />
| 2012-09-14<br />
| umby213<br />
| [[Permettere Spegnimento agli Utenti]]<br />
|<br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Android Notifier (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Arch Compared to Other Distributions (Italiano)]]<br />
| 2012-01-19<br />
| Toketin<br />
| [[Arch Comparato con altre Distribuzioni]]<br />
| Da controllare la fromattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[ArchBang (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Arch Based Distributions (Active)]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Archiso (Italiano)]]<br />
| 2012-02-05<br />
|<br />
|<br />
| '''da riallineare''' -- [[User:Kynikos|Kynikos]] 07:06, 24 March 2012 (EDT)<br />
|-align="center"<br />
| [[ArchWiki:About (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Asus Eee PC 900A (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Autofs (Italiano)]]<br />
| 2012-01-19<br />
| <br />
||<br />
|<br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]]<br />
| 2012-09-20<br />
| umby213<br />
| [[Login Automatico in una console virtuale]]<br />
|<br />
|-align="center"<br />
| [[Awesome3 (Italiano)]]<br />
| 2011-01-06<br />
| Delcaran <br />
|<br />
| '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]]<br />
| 2012-02-01 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bluetooth (Italiano)]]<br />
| 2012-10-14<br />
| icetux <br />
|<br />
|<br />
|-align="center"<br />
| [[BOINC (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]]<br />
| 2012-01-19 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bootchart (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date; versione inglese segnata a sua volta come Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Burg (Italiano)]]<br />
| 2011-09-21<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[CD Burning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Chromium (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Cinergy T stick (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste; riferimenti a kernel26 --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ClamAV (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Clyde (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Codecs (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]]<br />
| 2012-02-01<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Common Applications (Italiano)]]<br />
| 2011-12-16<br />
| Veleno77<br />
|<br />
|In fase di revisione, un riassunto è disponibile a [[Talk:Common Applications#Summary of related changes]]<br />
|-align="center"<br />
| [[Compiz (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Conky (Italiano)]]<br />
| 2011-09-21<br />
| Ninquitassar<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Connman (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[ConsoleKit (Italiano)]]<br />
| 2012-08-26<br />
| umby213<br />
|<br />
|<br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]]<br />
| 2012-11-03<br />
| Veleno77<br />
| [[Variazione di frequenza CPU]]<br />
|<br />
|-align="center"<br />
| [[Creating Packages (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Cwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Daemon (Italiano)]]<br />
| 2012-11-06<br />
| <br />
| [[Demoni]]<br />
|<br />
|-align="center"<br />
| [[Dell XPS M1530 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date e stub --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Deltup (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese "need expansions" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[DenyHosts (Italiano)]]<br />
|<br />
|<br />
|<br />
| le versioni sono allineate ma entrambe out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| [[Fotocamere Digitali]]<br />
|<br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Display Manager (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus <br />
| [[Avviare automaticamente un gestore login grafico all'avvio]]<br />
|<br />
|-align="center"<br />
| [[Dnsmasq (Italiano)]]<br />
| 2012-10-11<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Dropbox (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Drupal (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[E17 (Italiano)]]<br />
| 2012-09-05<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Eclipse Plugin Package Guidelines (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Evilwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Exaile (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Execute on USB insert (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext3 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext4 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[FAM (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]]<br />
| 2012-01-26<br />
| <br />
| [[Controllo ventola CPU]]<br />
|-align="center"<br />
| [[Fbsplash (Italiano)]]<br />
| 2012-01-19<br />
| Cylon<br />
|<br />
| <br />
|-align="center"<br />
| [[Feh (Italiano)]]<br />
| 2012-08-24<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[File Systems (Italiano)]]<br />
| 2012-10-20<br />
| Veleno77<br />
| [[Formattare una Periferica]], [[Format a device (Italiano)]] è un redirect<br />
|<br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
| Versione inglese rinominata in [[Arch filesystem hierarchy]] [[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firefox (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firewalls (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox (Italiano)]]<br />
| 2012-08-23<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Font Configuration (Italiano)]]<br />
| 2012-09-11<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Fonts (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[FVWM (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Games (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese diversa da quella italiana --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Gamin (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come "stub"; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]]<br />
| 2012-01-19<br />
| asa <br />
| [[Raccomandazioni Generali]] [[Suggerimenti Post Installazione]]<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]]<br />
| 2012-03-12<br />
| Kynikos<br />
| [[Come contribuire]]<br />
| '''Cedibile''', '''da riallineare''' -- [[User:Kynikos|Kynikos]] 06:51, 13 March 2012 (EDT)<br />
|-align="center"<br />
| [[Gnome 2.28 Changes (Italiano)]]<br />
| 2012-08-16<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]]<br />
| 2011-03-22<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Google Earth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione italiana più completa di quella inglese; credo che comunque sia da rivedere e aggiornare --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Grub-gfx (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; versione inglese a sua volta out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[GRUB Legacy (Italiano)]]<br />
| 2012-09-12<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[GTK+ (Italiano)]]<br />
| 2012-08-28<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[HAL (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Hal è deprecato''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Hardware Diagnostics (Italiano)]]<br />
|<br />
|<br />
| [[Diagnostica Hardware]]<br />
| Segnata come "out of date"; non esiste versione inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Help:Editing (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date<br />
|-align="center"<br />
| [[High Performance Firewall (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come: poorly written, merging in [[Router]]; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[IceWM (Italiano)]]<br />
| 2012-05-06<br />
| umby213<br />
| <br />
| Versione inglese segnata come ''poorly written''<br />
|-align="center"<br />
| [[Improve Pacman Performance (Italiano)]]<br />
| 2012-02-04<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]]<br />
| 2012-02-02<br />
| Stele<br />
|<br />
|-align="center"<br />
| [[Install from SSH (Italiano)]]<br />
| 2012-06-15<br />
| Stele<br />
|<br />
|<br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Internet key Momo Design (Italiano)]]<br />
|<br />
|<br />
|<br />
| la versione inglese è scritta in italiano '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Internet Share (Italiano)]]<br />
|<br />
|<br />
| [[Condivisione connessione internet]]<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Intel C++ (Italiano)]] <br />
| 2012-09-16<br />
| bred<br />
|<br />
|<br />
|-align="center"<br />
| [[Iptables (Italiano)]]<br />
| 2012-10-19<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[Java (Italiano)]]<br />
| 2012-10-26<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[JWM (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[KDM (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]]<br />
| 2010-12-30<br />
| <br />
|<br />
| Versione inglese "need expansions"; entrambe le pagine puntano a kernel26<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]]<br />
| 2012-08-08<br />
| Kynikos<br />
|<br />
| da riallineare -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:09, 4 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernel Panics (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernels (Italiano)]]<br />
| 2012-04-01<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Arch Build System (Italiano)]]<br />
| 2012-03-23<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Script (Italiano)]]<br />
| 2012-04-09<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Traditional (Italiano)]]<br />
| 2012-04-20<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[KVM (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[LAMP (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]]<br />
| 2012-11-05<br />
| veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[LVM (Italiano)]]<br />
| 2012-11-05<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[LXDE (Italiano)]]<br />
| 2011-01-06<br />
| xaber<br />
|<br />
| La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[MacBook (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]]<br />
| 2012-10-01<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[MATE (Italiano)]]<br />
| 2012-07-29<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mathematica (Italiano)]]<br />
|<br />
|<br />
|<br />
| Segnate come "stub" entrambe le versioni --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Media Center (Italiano)]]<br />
| <br />
| Stele<br />
|<br />
| '''É una pagina italiana e non ha il corrispettivo inglese'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]]<br />
| 2012-09-25<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]]<br />
| 2012-02-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mpd (Italiano)]]<br />
| 2011-01-08<br />
| Delcaran<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[MPlayer (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Mutt (Italiano)]]<br />
| 2012-07-06<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[MySQL (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Namcap (Italiano)]]<br />
| 2012-09-29<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Nano (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]]<br />
| 2012-01-14<br />
| Ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Netcfg (Italiano)]]<br />
| 2012-10-03<br />
| Toketin<br />
|<br />
|<br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[NetworkManager (Italiano)]]<br />
| 2012-09-15<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[NFS (Italiano)]]<br />
| 2012-01-27<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[NFSv4 (Italiano)]]<br />
| 2012-02-18<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Notify OSD (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Unity]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ntop (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]]<br />
| 2012-01-19<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[OpenOffice (Italiano)]] <br />
|<br />
|<br />
|<br />
| Scritta in inglese e Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Opera (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Osiris (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OSS (Italiano)]]<br />
| 2012-01-19<br />
| asa<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman GUI Frontends (Italiano)]]<br />
|<br />
|<br />
| [[Interfacce Grafiche per Pacman]]<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacman Tips (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacnew and Pacsave Files (Italiano)]]<br />
|<br />
|<br />
| [[File Pacnew e Pacsave]]<br />
| out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Palm Pre (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese scritta in italiano --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Partitioning (Italiano)]]<br />
| 2012-07-12<br />
| <br />
|<br />
| Out of date [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:26, 30 September 2012 (UTC)<br />
|-align="center"<br />
| [[Password Recovery (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[Pawm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[PekWM (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]]<br />
| 2011-09-23<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Plymouth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]]<br />
| 2012-10-06<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Powerpill (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Privoxy (Italiano)]]<br />
| 2011-09-08<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Readline (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Samba (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Secure Shell (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]]<br />
| 2011-10-20<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[SLiM (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Small Business Server (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Pagina italiana più aggiornata, contiene sottopagine''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]]<br />
| 2011-09-05<br />
|<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]]<br />
| 2011-02-21<br />
| asa<br />
|<br />
|<br />
|-align="center"<br />
| [[SSH Keys (Italiano)]]<br />
| 2011-12-17<br />
|<br />
|<br />
| '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sshfs (Italiano)]]<br />
| 2011-11-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sudo (Italiano)]]<br />
| 2011-12-06<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sugar (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[swap (Italiano)]]<br />
| 2012-09-17<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Synergy (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Table of Contents (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| La struttura della lista viene aggiornata automaticamente e periodicamente da [[User:Kynikos.bot|Kynikos.bot]]<br />
|-align="center"<br />
| [[TeXLive (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[The Arch Way v2.0 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Thunar (Italiano)]]<br />
| 2012-09-24<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Thunderbird (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; scritta in inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]]<br />
| 2011-10-09<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[TuPac (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Twm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]]<br />
| 2011-06-02<br />
| Ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[USB Storage Devices (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Uvesafb (Italiano)]]<br />
| 2011-10-17<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]]<br />
| 2011-09-28<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Vim (Italiano)]]<br />
| 2012-05-15<br />
|<br />
| <br />
| '''Da riallineare''' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 12 July 2012 (UTC)<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]]<br />
| 2012-01-19<br />
|<br />
| <br />
|<br />
|-align="center"<br />
| [[VirtualBox (Italiano)]]<br />
| 2011-03-21<br />
| ant84<br />
|<br />
|<br />
|-align="center"<br />
| [[VMware (Italiano)]]<br />
| 2012-02-02<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Webmin (Italiano)]]<br />
| 2011-08-10<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Wicd (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Window Maker (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Window Manager (Italiano)]]<br />
| 2012-02-02<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Wine (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Xampp (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[xf86-video-sis (Italiano)]]<br />
| 2012-10-06<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[XFS (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese segnata come "stub" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] <br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Yaourt (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
| <br />
|}<br />
<br />
==Staff tecnico==<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Coordinatore<br />
:# [[User:4javier|4javier]]<br />
:# [[User:Kynikos|Kynikos]] - [[ArchWiki:Administrators|Amministratore ArchWiki ]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
:# [[User:love89|Love89]]<br />
:# [[User:maveloth|maveloth]]<br />
:# [[User:nierro|Nierro]]<br />
:# [[User:Dariocent|Dario]]<br />
:# [[User:Ambro|Ambro]]<br />
<br />
==Ulteriori informazioni e supporto==<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum italiano].</div>Ambrohttps://wiki.archlinux.org/index.php?title=Daemons_(Italiano)&diff=234076Daemons (Italiano)2012-11-06T14:10:27Z<p>Ambro: Allineato al 06.11.2012</p>
<hr />
<div>[[Category:Boot process (Italiano)]]<br />
[[Category:Daemons and system services (Italiano)]]<br />
[[cs:Daemon]]<br />
[[de:Daemons]]<br />
[[en:Daemon]]<br />
[[pl:Daemon]]<br />
[[ro:Daemon]]<br />
[[ru:Daemon]]<br />
[[tr:Artsüreç]]<br />
[[zh-CN:Daemon]]<br />
Un [http://it.wikipedia.org/wiki/Demone_(informatica) demone] è un programma che viene eseguito in background, in attesa che si verifichino determinati eventi e offrendo servizi. Un buon esempio è un server web in attesa di fornire una pagina richiesta o un server ssh in attesa di qualcuno che esegua il login. Anche se queste sono applicazioni particolari con ampie funzionalità, ci sono demoni il cui lavoro non è così visibile come il demone che scrive messaggi in un file di log (ad esempio, syslog, metalog), o il demone che controlla l'accuratezza del tempo del sistema (ad esempio,[[Network Time Protocol daemon (Italiano)|ntpd]]).<br />
<br />
{{note|Il termine demone è talvolta usato per una classe di programmi che vengono avviati al boot, ma non hanno alcun processo che rimanga in memoria. Sono chiamati demoni semplicemente perché usano la stessa struttura di avvio e arresto (ad esempio i servizi di systemd di tipo oneshot) uasata per avviare i demoni tradizionali. Per esempio, i files per il servizio {{ic|alsa-store}} e {{ic|alsa-restore}} forniscono il supporto per una configurazione persistente ma non avviano ulteriori processi in background a richiesta del servizio o per risposta ad eventi.<br />
<br />
Dalla prospettiva di un utente la distinzione solitamente è insignificante fino a quando l'utente stesso non tenta di cercare il "demone" in una lista dei processi.<br />
}}<br />
<br />
==Systemd==<br />
<br />
===Avvio al boot===<br />
Una installazione di default di Arch Linux will lascia pochissimi servizi (o demoni) attivi al boot. E' possibile aggiungere o rimuovere servizi da avviare al boot con:<br />
<br />
# systemctl enable <name><br />
<br />
o<br />
<br />
# systemctl disable <name><br />
<br />
I servizi stessi contengono tutte le necessarie informazioni, cosicché non c'è bisogno di ordinarli manualmente.<br />
<br />
I files dei Servizi sono immagazzinati in {{ic|/{etc,usr/lib,run}/systemd/system}}. Si può visualizzare la lista dei servizi disponibili nel proprio sistema assieme al loro attuale stato, con:<br />
$ systemctl list-unit-files<br />
<br />
Per vedere una lista delle unità attive (alcune delle quali possono essere demoni, tra le altre cose), digitare:<br />
$ systemctl list-units<br />
<br />
Per vedere tutte quelle disponibili, aggiungere {{ic| --all}} alla fine del comando.<br />
<br />
===Avvio manuale===<br />
Per avviare o fermare servizi To start or stop services in fase di esecuzione, si può rimpiazzare {{ic|enable}}/{{ic|disable}} con {{ic|start}}/{{ic|stop}} nei precedenti comandi.<br />
<br />
Si può approfondire alla sezione [[Systemd_(Italiano)#Uso_base_di_systemctl| systemctl del wiki di systemd]].<br />
<br />
==Lista dei demoni==<br />
Vedere [[Daemons List]] per una lista dei demoni con il nome del servizio e il vecchio script rc.d.<br />
<br />
==Vedi anche==<br />
* [[Systemd_(Italiano)|systemd]]<br />
* Esempi per la scrittura [[Systemd/Services]]</div>Ambrohttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=234074ArchWiki:Translation Team (Italiano)2012-11-06T13:42:39Z<p>Ambro: </p>
<hr />
<div>[[Category:ArchWiki (Italiano)]]<br />
[[en:ArchWiki Translation Team]]<br />
[[es:ArchWiki Translation Team]]<br />
[[hr:ArchWiki Translation Team]]<br />
[[pl:ArchWiki Translation Team]]<br />
[[tr:ArchWiki_Çeviri_Ekibi]]<br />
[[zh-CN:ArchWiki Translation Team]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questa pagina è dedicata a tutti coloro che desiderano collaborare per fornire un supporto di traduzione, correzione e mantenimento delle pagine italiane di ArchWiki. Vengono inoltre fornite tutte le informazioni necessarie per un corretto uso delle traduzioni.}}<br />
{{Article summary heading|Correlati}}<br />
{{Article summary wiki|Help:Editing (Italiano)}}<br />
{{Article summary wiki|Help:Style (Italiano)}}<br />
{{Article summary wiki|Help:Reading}}<br />
{{Article summary wiki|ArchWiki:About (Italiano)}}<br />
{{Article summary heading|Fonti Utili}}<br />
{{Article summary text|Alcuni articoli utili per aiutare nella traduzione: }}<br />
{{Article summary text|1=[http://http://www.archlinux.it/forum/viewtopic.php?f=19&t=1087 Strumenti utili per i traduttori]}}<br />
{{Article summary text|[http://tp.linux.it/buona_traduzione.html Regole per una buona traduzione]}}<br />
{{Article summary end}}<br />
<br />
Un Wiki è una collezione di documenti ipertestuali che viene aggiornata dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il testo può essere modificato da tutti gli utenti registrati, con lo scopo di condividere, scambiare, immagazzinare e ottimizzare la conoscenza in modo collaborativo.<br />
<br />
Proprio con questo intento, la [http://www.archlinux.it/ comunità ufficiale italiana] di Arch Linux ha fondato l'[[ArchWiki Translation Team (Italiano)|ArchWiki Translation Team]], un gruppo aperto e collaborativo di utenti, con lo scopo di allineare la documentazione italiana con quella inglese e tenerla costantemente aggiornata, in modo da offrire il miglior servizio possibile alla propria comunità. <br />
<br />
Come in ogni progetto collaborativo c'è sempre bisogno di utenti disponibili. Se volete aiutare la comunità italiana ad avere una documentazione sempre efficace, aggiornata e più ampia possibile, considerate la possibilità di unirvi a questo progetto. Ogni riferimento è reperibile sul forum ufficiale italiano in [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 questa discussione] dove potete '''segnalare la vostra disponibilità'''.<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i revisori==<br />
<br />
===Organizzazione interna===<br />
<br />
Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati ad uno precedentemente preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi.<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano, e ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità e verranno ''taggate'' con appositi template da inserire ad inizio articolo, per segnalare che la pagina è in fase di lavorazione:<br />
;Nel caso di Aggiornamenti e Revisioni:{{ic|<nowiki> {{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:{{ic|<nowiki>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di tradurre dell'eventuale testo antecedente e dei menu "Summary".<br />
<br />
===Linee guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
# Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
# Scrivere sempre in forma indiretta. (Es: {{ic|aprire un terminale e digitare}}... è più corretto rispetto ad {{ic|apri il terminale e digita}})<br />
# Utilizzare '''sempre''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità di poter correggere immediatamente eventuali errori.<br />
# É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare:<br />
#; <nowiki>{{ic|testo}}</nowiki>: quando si è in presenza del path di un file. (Es. {{ic|<nowiki>{{ic|/etc/fstab}}</nowiki>}}, o per evidenziare un modulo, comando o una stringa di configurazione. Es: {{ic|<nowiki>Si può utilizzare {{ic|iwconfig}} per configurare la rete...</nowiki>}} . <br />
#; <nowiki>{{bc|comando}}</nowiki>: quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: {{ic|Da terminale dare il comando <nowiki>{{bc|# iwconfig}}</nowiki>}}, a volte basta dare un enter e scrivere il comando preceduto da uno spazio bianco.<br />
#; <nowiki>{{hc|intestazione|contenuto}}</nowiki>: questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, es: {{ic|<nowiki>{{hc|nome del file/comando|contenuto di un file o l'output di un comando}}</nowiki>}}.<br />
#; <nowiki>{{keypress|tasto_funzione}}</nowiki>: quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: {{ic|premere <nowiki>{{keypress|Invio}}</nowiki> per continuare}}. <br />
#;<nowiki>{{pkg|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente nei repositori ufficiali, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere '{{ic|<nowiki>Installare linux-lts con : {{bc|pacman -S linux-lts}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>[[pacman (Italiano)|Installare]] il pacchetto {{pkg|linux-lts}}</nowiki>}}, il riferimento al wiki di Pacman è necessario solo la prima volta nell'articolo, nel caso di ripetitivi indicazioni sui pacchetti si può omettere. Es: {{ic|<nowiki>è possibile installare anche il pacchetto {{pkg|linux-lts-headers}}</nowiki>}}.<br />
#;<nowiki>{{AUR|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente in AUR, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere {{ic|<nowiki>Installare linux-lts-ck con : {{bc|yaourt -S linux-lts-ck}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>Installare il pacchetto {{AUR|linux-lts-ck}}, reperibile su [[ARU (Italiano)|AUR]]</nowiki>}},l'aggiunta del riferimento al wiki italiano di AUR è necessaria la prima volta per rimandare gli utenti a conoscerne l'uso. <br> <span style="position:relative; left:-2em;">{{Nota|1=In caso di errori del template dovuto a particolari caratteri, potrebbe essere necessario aggiungere '''1=''' prima del contenuto . La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}}</span> <br />
# É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. {{ic|Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti....}}), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (es: {{ic|<nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>}})<br />
# Per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
# Per quanto riguarda le traduzioni si ricorda che '''i primi revisori siete voi stessi'''. Di conseguenza:<br />
#* Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
#* Controllate che il contesto risulti corretto sia nel contenuto che nella forma e di facile comprensione, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
# Si consiglia di '''commentare sempre''' le modifiche che si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili.<br />
<br />
{{Nota|1=Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina. Per ogni dubbio potete chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum]}}<br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
===Pagine ad alta priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[dm-crypt with LUKS (Italiano)]]<br />
| Pagina da allineare e tradurre<br />
| maveloth<br />
| in corso<br />
|-<br />
| [[Disk_Encryption (Italiano)]]<br />
| Pagina da completare la traduzione<br />
| Dario<br />
| in corso<br />
|-<br />
|}<br />
<br />
=== Pagine a bassa priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Android (Italiano)]]<br />
| <br />
| SirX<br />
| In corso<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[PostgreSQL (Italiano)]]<br />
| Traduzione incompleta<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
==Revisioni==<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero: yyyy-mm-gg (es. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all<nowiki>'</nowiki>'''adozione''' del medesimo.<br />
<br />
===Adottare un wiki===<br />
<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e l'allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni:<br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra), oppure molto semplicemente andando sul wiki da seguire premere sul link '''Segui''' situato affianco a "Cronologia".<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
:{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc).<br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
===Tabella riassuntiva dei wiki revisionati e adottati===<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in due tabelle a seconda delle priorità ([[ArchWiki_Translation_Team_(Italiano)#Articoli Principali|Articoli Princpali]] e [[ArchWiki_Translation_Team_(Italiano)#Articoli Secondari|Articoli Secondari]]), in modo da avere le principiali guide di riferimento sempre aggiornate e sotto controllo. Lo scopo è quello di adottare per prima le pagine contenute nella tabella Articoli Principali, ed in un secondo momento occuparci degli altri articoli. Il contenuto delle tabelle viene discusso sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 froum] e può variare in base alle esigenze della comunità.<br />
<br />
Le tabelle contengono cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Redirect Ita''' - Vengono immessi qui i wiki con titolo italiano che hanno un ''redirect'' al wiki tradotto.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore. Qui immettendo '''Cedibile''' si rende pubblica la volontà di lasciare l'adozione di un wiki (in tal casoeliminare anche il proprio nome dalla colonna ''Revisore'').<br />
<br />
Le colonne contengono un link ''rapido'' di consultazione che effettua un ordinamento alfabetico.<br />
<br />
==== Articoli principali ====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center" <br />
| [[Advanced Linux Sound Architecture (Italiano)]] || 2012-02-22 || 4javier || ||<br />
|-align="center"<br />
| [[AMD Catalyst (Italiano)]] || 2012-11-06 || umby213 || || <br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]] || 2012-09-04 || Kynikos || || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]] || 2012-02-07 || 4javier || || <br />
|-align="center"<br />
| [[Arch Linux (Italiano)]] || 2012-11-06 || icetux || ||<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]] || 2012-09-06 || Kynikos || || '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[ATI (Italiano)]]<br />
| 2012-02-20<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]]<br />
| 2012-11-04<br />
| Veleno77 <br />
| [[Guida per Principianti]]<br />
|<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]]<br />
| 2012-10-04<br />
| icetux <br />
| [[Configurazione della Rete]]<br />
|<br />
|-align="center"<br />
| [[CUPS (Italiano)]]<br />
| 2012-09-22<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[FAQ (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
| [[Domande Frequenti]]<br />
| la versione inglese sta variando molto, appena si stabilizza ri-allineo ;) --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 11:23, 22 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fstab (Italiano)]]<br />
| 2012-10-28<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[GNOME (Italiano)]]<br />
| 2011-12-3<br />
| Cylon<br />
|<br />
| In allineamento<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
| <br />
|-align="center"<br />
| [[Help:Style (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Installation Guide (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| [[Guida all'installazione]]<br />
| ''Official Installation Guide'' è redirect a questa pagina<br />
|-align="center"<br />
| [[Intel (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[KDE (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[Laptop (Italiano)]]<br />
| 2012-10-24<br />
| Nierro<br />
| <br />
|<br />
|--align="center"<br />
| [[Locale (Italiano)]]<br />
| 2012-10-07<br />
| Veleno77<br />
| <br />
|<br />
|-align="center"<br />
| [[Main Page (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Makepkg (Italiano)]]<br />
| 2012-02-28<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Nouveau (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[NVIDIA (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]]<br />
| 2012-10-04<br />
| icetux<br />
| [[Repository Ufficiali]]<br />
|<br />
|-align="center"<br />
| [[Openbox (Italiano)]]<br />
| 2012-02-07<br />
| 4javier <br />
|<br />
|<br />
|-align="center"<br />
| [[Pacman (Italiano)]]<br />
| 2012-09-18<br />
| Kynikos<br />
|<br />
| '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]]<br />
| 2012-01-19<br />
| Ninquitassar<br />
|<br />
| <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio/Examples (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[RAID (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Start X at Login (Italiano)]]<br />
| 2011-09-20<br />
| Hilinus<br />
| [[Far partire X al boot]]<br />
|<br />
|- align="center"<br />
| [[Syslinux (Italiano)]]<br />
| 2012-08-01<br />
| Hilinus<br />
| <br />
| <br />
|-align="center"<br />
| [[Systemd (Italiano)]]<br />
| 2012-11-05<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[Systemd FAQ (Italiano)]]<br />
| 2012-11-04<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[SysVinit (Italiano)]]<br />
| 2012-11-01<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]]<br />
| 2012-09-06<br />
| icetux<br />
| [[Il Metodo Arch]]<br />
|<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Udev (Italiano)]]<br />
| 2011-12-08<br />
| ninquitassar<br />
|<br />
|<br />
|-align="center"<br />
| [[Unified Extensible Firmware Interface (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
| <br />
|-align="center"<br />
| [[USB Installation Media (Italiano)]]<br />
| 2012-10-06<br />
| umby213<br />
| [[Installare da supporto USB]]<br />
|<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]]<br />
| 2012-11-06<br />
| Veleno77<br />
| [[Utenti e Gruppi]]<br />
| <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] <br />
| 2012-02-13<br />
| Hilinus<br />
| [[Configurazione Wireless]]<br />
|<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]]<br />
| 2012-02-07<br />
| Hilinus<br />
| <br />
|<br />
|-align="center"<br />
| [[Xfce (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Xorg (Italiano)]] <br />
| 2011-12-06<br />
| ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
====Articoli secondari====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Acer Extensa 5220 (Italiano)]]<br />
|<br />
|<br />
|<br />
| ok --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ACPI modules (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Acpid (Italiano)]]<br />
| 2012-10-13<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Activating Numlock on Bootup (Italiano)]]<br />
|<br />
|<br />
| [[Attivare Numlock all'Avvio]]<br />
| Out of date<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]]<br />
| 2012-09-14<br />
| umby213<br />
| [[Permettere Spegnimento agli Utenti]]<br />
|<br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Android Notifier (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Arch Compared to Other Distributions (Italiano)]]<br />
| 2012-01-19<br />
| Toketin<br />
| [[Arch Comparato con altre Distribuzioni]]<br />
| Da controllare la fromattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[ArchBang (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Arch Based Distributions (Active)]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Archiso (Italiano)]]<br />
| 2012-02-05<br />
|<br />
|<br />
| '''da riallineare''' -- [[User:Kynikos|Kynikos]] 07:06, 24 March 2012 (EDT)<br />
|-align="center"<br />
| [[ArchWiki:About (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Asus Eee PC 900A (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Autofs (Italiano)]]<br />
| 2012-01-19<br />
| <br />
||<br />
|<br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]]<br />
| 2012-09-20<br />
| umby213<br />
| [[Login Automatico in una console virtuale]]<br />
|<br />
|-align="center"<br />
| [[Awesome3 (Italiano)]]<br />
| 2011-01-06<br />
| Delcaran <br />
|<br />
| '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]]<br />
| 2012-02-01 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bluetooth (Italiano)]]<br />
| 2012-10-14<br />
| icetux <br />
|<br />
|<br />
|-align="center"<br />
| [[BOINC (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]]<br />
| 2012-01-19 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bootchart (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date; versione inglese segnata a sua volta come Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Burg (Italiano)]]<br />
| 2011-09-21<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[CD Burning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Chromium (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Cinergy T stick (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste; riferimenti a kernel26 --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ClamAV (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Clyde (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Codecs (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]]<br />
| 2012-02-01<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Common Applications (Italiano)]]<br />
| 2011-12-16<br />
| Veleno77<br />
|<br />
|In fase di revisione, un riassunto è disponibile a [[Talk:Common Applications#Summary of related changes]]<br />
|-align="center"<br />
| [[Compiz (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Conky (Italiano)]]<br />
| 2011-09-21<br />
| Ninquitassar<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Connman (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[ConsoleKit (Italiano)]]<br />
| 2012-08-26<br />
| umby213<br />
|<br />
|<br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]]<br />
| 2012-11-03<br />
| Veleno77<br />
| [[Variazione di frequenza CPU]]<br />
|<br />
|-align="center"<br />
| [[Creating Packages (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Cwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Daemon (Italiano)]]<br />
| 2012-02-13<br />
| <br />
| [[Demoni]]<br />
|<br />
|-align="center"<br />
| [[Dell XPS M1530 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date e stub --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Deltup (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese "need expansions" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[DenyHosts (Italiano)]]<br />
|<br />
|<br />
|<br />
| le versioni sono allineate ma entrambe out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| [[Fotocamere Digitali]]<br />
|<br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Display Manager (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus <br />
| [[Avviare automaticamente un gestore login grafico all'avvio]]<br />
|<br />
|-align="center"<br />
| [[Dnsmasq (Italiano)]]<br />
| 2012-10-11<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Dropbox (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Drupal (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[E17 (Italiano)]]<br />
| 2012-09-05<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Eclipse Plugin Package Guidelines (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Evilwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Exaile (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Execute on USB insert (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext3 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext4 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[FAM (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]]<br />
| 2012-01-26<br />
| <br />
| [[Controllo ventola CPU]]<br />
|-align="center"<br />
| [[Fbsplash (Italiano)]]<br />
| 2012-01-19<br />
| Cylon<br />
|<br />
| <br />
|-align="center"<br />
| [[Feh (Italiano)]]<br />
| 2012-08-24<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[File Systems (Italiano)]]<br />
| 2012-10-20<br />
| Veleno77<br />
| [[Formattare una Periferica]], [[Format a device (Italiano)]] è un redirect<br />
|<br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
| Versione inglese rinominata in [[Arch filesystem hierarchy]] [[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firefox (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firewalls (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox (Italiano)]]<br />
| 2012-08-23<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Font Configuration (Italiano)]]<br />
| 2012-09-11<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Fonts (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[FVWM (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Games (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese diversa da quella italiana --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Gamin (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come "stub"; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]]<br />
| 2012-01-19<br />
| asa <br />
| [[Raccomandazioni Generali]] [[Suggerimenti Post Installazione]]<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]]<br />
| 2012-03-12<br />
| Kynikos<br />
| [[Come contribuire]]<br />
| '''Cedibile''', '''da riallineare''' -- [[User:Kynikos|Kynikos]] 06:51, 13 March 2012 (EDT)<br />
|-align="center"<br />
| [[Gnome 2.28 Changes (Italiano)]]<br />
| 2012-08-16<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]]<br />
| 2011-03-22<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Google Earth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione italiana più completa di quella inglese; credo che comunque sia da rivedere e aggiornare --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Grub-gfx (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; versione inglese a sua volta out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[GRUB Legacy (Italiano)]]<br />
| 2012-09-12<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[GTK+ (Italiano)]]<br />
| 2012-08-28<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[HAL (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Hal è deprecato''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Hardware Diagnostics (Italiano)]]<br />
|<br />
|<br />
| [[Diagnostica Hardware]]<br />
| Segnata come "out of date"; non esiste versione inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Help:Editing (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date<br />
|-align="center"<br />
| [[High Performance Firewall (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come: poorly written, merging in [[Router]]; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[IceWM (Italiano)]]<br />
| 2012-05-06<br />
| umby213<br />
| <br />
| Versione inglese segnata come ''poorly written''<br />
|-align="center"<br />
| [[Improve Pacman Performance (Italiano)]]<br />
| 2012-02-04<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]]<br />
| 2012-02-02<br />
| Stele<br />
|<br />
|-align="center"<br />
| [[Install from SSH (Italiano)]]<br />
| 2012-06-15<br />
| Stele<br />
|<br />
|<br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Internet key Momo Design (Italiano)]]<br />
|<br />
|<br />
|<br />
| la versione inglese è scritta in italiano '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Internet Share (Italiano)]]<br />
|<br />
|<br />
| [[Condivisione connessione internet]]<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Intel C++ (Italiano)]] <br />
| 2012-09-16<br />
| bred<br />
|<br />
|<br />
|-align="center"<br />
| [[Iptables (Italiano)]]<br />
| 2012-10-19<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[Java (Italiano)]]<br />
| 2012-10-26<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[JWM (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[KDM (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]]<br />
| 2010-12-30<br />
| <br />
|<br />
| Versione inglese "need expansions"; entrambe le pagine puntano a kernel26<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]]<br />
| 2012-08-08<br />
| Kynikos<br />
|<br />
| da riallineare -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:09, 4 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernel Panics (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernels (Italiano)]]<br />
| 2012-04-01<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Arch Build System (Italiano)]]<br />
| 2012-03-23<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Script (Italiano)]]<br />
| 2012-04-09<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Traditional (Italiano)]]<br />
| 2012-04-20<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[KVM (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[LAMP (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]]<br />
| 2012-11-05<br />
| veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[LVM (Italiano)]]<br />
| 2012-11-05<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[LXDE (Italiano)]]<br />
| 2011-01-06<br />
| xaber<br />
|<br />
| La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[MacBook (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]]<br />
| 2012-10-01<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[MATE (Italiano)]]<br />
| 2012-07-29<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mathematica (Italiano)]]<br />
|<br />
|<br />
|<br />
| Segnate come "stub" entrambe le versioni --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Media Center (Italiano)]]<br />
| <br />
| Stele<br />
|<br />
| '''É una pagina italiana e non ha il corrispettivo inglese'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]]<br />
| 2012-09-25<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]]<br />
| 2012-02-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mpd (Italiano)]]<br />
| 2011-01-08<br />
| Delcaran<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[MPlayer (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Mutt (Italiano)]]<br />
| 2012-07-06<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[MySQL (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Namcap (Italiano)]]<br />
| 2012-09-29<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Nano (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]]<br />
| 2012-01-14<br />
| Ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Netcfg (Italiano)]]<br />
| 2012-10-03<br />
| Toketin<br />
|<br />
|<br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]]<br />
| 2012-11-06<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[NetworkManager (Italiano)]]<br />
| 2012-09-15<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[NFS (Italiano)]]<br />
| 2012-01-27<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[NFSv4 (Italiano)]]<br />
| 2012-02-18<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Notify OSD (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Unity]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ntop (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]]<br />
| 2012-01-19<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[OpenOffice (Italiano)]] <br />
|<br />
|<br />
|<br />
| Scritta in inglese e Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Opera (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Osiris (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OSS (Italiano)]]<br />
| 2012-01-19<br />
| asa<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman GUI Frontends (Italiano)]]<br />
|<br />
|<br />
| [[Interfacce Grafiche per Pacman]]<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacman Tips (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacnew and Pacsave Files (Italiano)]]<br />
|<br />
|<br />
| [[File Pacnew e Pacsave]]<br />
| out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Palm Pre (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese scritta in italiano --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Partitioning (Italiano)]]<br />
| 2012-07-12<br />
| <br />
|<br />
| Out of date [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:26, 30 September 2012 (UTC)<br />
|-align="center"<br />
| [[Password Recovery (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[Pawm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[PekWM (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]]<br />
| 2011-09-23<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Plymouth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]]<br />
| 2012-10-06<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Powerpill (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Privoxy (Italiano)]]<br />
| 2011-09-08<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Readline (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Samba (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Secure Shell (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]]<br />
| 2011-10-20<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[SLiM (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Small Business Server (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Pagina italiana più aggiornata, contiene sottopagine''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]]<br />
| 2011-09-05<br />
|<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]]<br />
| 2011-02-21<br />
| asa<br />
|<br />
|<br />
|-align="center"<br />
| [[SSH Keys (Italiano)]]<br />
| 2011-12-17<br />
|<br />
|<br />
| '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sshfs (Italiano)]]<br />
| 2011-11-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sudo (Italiano)]]<br />
| 2011-12-06<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sugar (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[swap (Italiano)]]<br />
| 2012-09-17<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Synergy (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Table of Contents (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| La struttura della lista viene aggiornata automaticamente e periodicamente da [[User:Kynikos.bot|Kynikos.bot]]<br />
|-align="center"<br />
| [[TeXLive (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[The Arch Way v2.0 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Thunar (Italiano)]]<br />
| 2012-09-24<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Thunderbird (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; scritta in inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]]<br />
| 2011-10-09<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[TuPac (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Twm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]]<br />
| 2011-06-02<br />
| Ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[USB Storage Devices (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Uvesafb (Italiano)]]<br />
| 2011-10-17<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]]<br />
| 2011-09-28<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Vim (Italiano)]]<br />
| 2012-05-15<br />
|<br />
| <br />
| '''Da riallineare''' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 12 July 2012 (UTC)<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]]<br />
| 2012-01-19<br />
|<br />
| <br />
|<br />
|-align="center"<br />
| [[VirtualBox (Italiano)]]<br />
| 2011-03-21<br />
| ant84<br />
|<br />
|<br />
|-align="center"<br />
| [[VMware (Italiano)]]<br />
| 2012-02-02<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Webmin (Italiano)]]<br />
| 2011-08-10<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Wicd (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Window Maker (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Window Manager (Italiano)]]<br />
| 2012-02-02<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Wine (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Xampp (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[xf86-video-sis (Italiano)]]<br />
| 2012-10-06<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[XFS (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese segnata come "stub" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] <br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Yaourt (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
| <br />
|}<br />
<br />
==Staff tecnico==<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Coordinatore<br />
:# [[User:4javier|4javier]]<br />
:# [[User:Kynikos|Kynikos]] - [[ArchWiki:Administrators|Amministratore ArchWiki ]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
:# [[User:love89|Love89]]<br />
:# [[User:maveloth|maveloth]]<br />
:# [[User:nierro|Nierro]]<br />
:# [[User:Dariocent|Dario]]<br />
:# [[User:Ambro|Ambro]]<br />
<br />
==Ulteriori informazioni e supporto==<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum italiano].</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=234030Systemd (Italiano)2012-11-06T10:46:52Z<p>Ambro: fix type</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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}}. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''non''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=233965ArchWiki:Translation Team (Italiano)2012-11-05T22:16:24Z<p>Ambro: /* Articoli principali */</p>
<hr />
<div>[[Category:ArchWiki (Italiano)]]<br />
[[en:ArchWiki Translation Team]]<br />
[[es:ArchWiki Translation Team]]<br />
[[hr:ArchWiki Translation Team]]<br />
[[pl:ArchWiki Translation Team]]<br />
[[tr:ArchWiki_Çeviri_Ekibi]]<br />
[[zh-CN:ArchWiki Translation Team]]<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questa pagina è dedicata a tutti coloro che desiderano collaborare per fornire un supporto di traduzione, correzione e mantenimento delle pagine italiane di ArchWiki. Vengono inoltre fornite tutte le informazioni necessarie per un corretto uso delle traduzioni.}}<br />
{{Article summary heading|Correlati}}<br />
{{Article summary wiki|Help:Editing (Italiano)}}<br />
{{Article summary wiki|Help:Style (Italiano)}}<br />
{{Article summary wiki|Help:Reading}}<br />
{{Article summary wiki|ArchWiki:About (Italiano)}}<br />
{{Article summary heading|Fonti Utili}}<br />
{{Article summary text|Alcuni articoli utili per aiutare nella traduzione: }}<br />
{{Article summary text|1=[http://http://www.archlinux.it/forum/viewtopic.php?f=19&t=1087 Strumenti utili per i traduttori]}}<br />
{{Article summary text|[http://tp.linux.it/buona_traduzione.html Regole per una buona traduzione]}}<br />
{{Article summary end}}<br />
<br />
Un Wiki è una collezione di documenti ipertestuali che viene aggiornata dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il testo può essere modificato da tutti gli utenti registrati, con lo scopo di condividere, scambiare, immagazzinare e ottimizzare la conoscenza in modo collaborativo.<br />
<br />
Proprio con questo intento, la [http://www.archlinux.it/ comunità ufficiale italiana] di Arch Linux ha fondato l'[[ArchWiki Translation Team (Italiano)|ArchWiki Translation Team]], un gruppo aperto e collaborativo di utenti, con lo scopo di allineare la documentazione italiana con quella inglese e tenerla costantemente aggiornata, in modo da offrire il miglior servizio possibile alla propria comunità. <br />
<br />
Come in ogni progetto collaborativo c'è sempre bisogno di utenti disponibili. Se volete aiutare la comunità italiana ad avere una documentazione sempre efficace, aggiornata e più ampia possibile, considerate la possibilità di unirvi a questo progetto. Ogni riferimento è reperibile sul forum ufficiale italiano in [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 questa discussione] dove potete '''segnalare la vostra disponibilità'''.<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i revisori==<br />
<br />
===Organizzazione interna===<br />
<br />
Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati ad uno precedentemente preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi.<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano, e ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità e verranno ''taggate'' con appositi template da inserire ad inizio articolo, per segnalare che la pagina è in fase di lavorazione:<br />
;Nel caso di Aggiornamenti e Revisioni:{{ic|<nowiki> {{out_of_date | Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:{{ic|<nowiki>{{translateme | Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese. | Talk:ArchWiki Translation Team (Italiano)#Pagine Marcate come "out of date" e "Traslateme"}}</nowiki>}}<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di tradurre dell'eventuale testo antecedente e dei menu "Summary".<br />
<br />
===Linee guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
# Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
# Scrivere sempre in forma indiretta. (Es: {{ic|aprire un terminale e digitare}}... è più corretto rispetto ad {{ic|apri il terminale e digita}})<br />
# Utilizzare '''sempre''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità di poter correggere immediatamente eventuali errori.<br />
# É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare:<br />
#; <nowiki>{{ic|testo}}</nowiki>: quando si è in presenza del path di un file. (Es. {{ic|<nowiki>{{ic|/etc/fstab}}</nowiki>}}, o per evidenziare un modulo, comando o una stringa di configurazione. Es: {{ic|<nowiki>Si può utilizzare {{ic|iwconfig}} per configurare la rete...</nowiki>}} . <br />
#; <nowiki>{{bc|comando}}</nowiki>: quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: {{ic|Da terminale dare il comando <nowiki>{{bc|# iwconfig}}</nowiki>}}, a volte basta dare un enter e scrivere il comando preceduto da uno spazio bianco.<br />
#; <nowiki>{{hc|intestazione|contenuto}}</nowiki>: questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, es: {{ic|<nowiki>{{hc|nome del file/comando|contenuto di un file o l'output di un comando}}</nowiki>}}.<br />
#; <nowiki>{{keypress|tasto_funzione}}</nowiki>: quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: {{ic|premere <nowiki>{{keypress|Invio}}</nowiki> per continuare}}. <br />
#;<nowiki>{{pkg|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente nei repositori ufficiali, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere '{{ic|<nowiki>Installare linux-lts con : {{bc|pacman -S linux-lts}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>[[pacman (Italiano)|Installare]] il pacchetto {{pkg|linux-lts}}</nowiki>}}, il riferimento al wiki di Pacman è necessario solo la prima volta nell'articolo, nel caso di ripetitivi indicazioni sui pacchetti si può omettere. Es: {{ic|<nowiki>è possibile installare anche il pacchetto {{pkg|linux-lts-headers}}</nowiki>}}.<br />
#;<nowiki>{{AUR|pacchetto}}</nowiki>: quando si ha la necessità di segnalare un pacchetto presente in AUR, da installare o nel corpo del testo. É stato stabilito che non vengano più fornite indicazioni estese su come si installano i programmi, in pratica '''è errato''' scrivere {{ic|<nowiki>Installare linux-lts-ck con : {{bc|yaourt -S linux-lts-ck}}</nowiki>}}. La '''corretta''' forma è {{ic|<nowiki>Installare il pacchetto {{AUR|linux-lts-ck}}, reperibile su [[ARU (Italiano)|AUR]]</nowiki>}},l'aggiunta del riferimento al wiki italiano di AUR è necessaria la prima volta per rimandare gli utenti a conoscerne l'uso. <br> <span style="position:relative; left:-2em;">{{Nota|1=In caso di errori del template dovuto a particolari caratteri, potrebbe essere necessario aggiungere '''1=''' prima del contenuto . La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}}</span> <br />
# É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. {{ic|Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti....}}), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (es: {{ic|<nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>}})<br />
# Per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
# Per quanto riguarda le traduzioni si ricorda che '''i primi revisori siete voi stessi'''. Di conseguenza:<br />
#* Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
#* Controllate che il contesto risulti corretto sia nel contenuto che nella forma e di facile comprensione, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
# Si consiglia di '''commentare sempre''' le modifiche che si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili.<br />
<br />
{{Nota|1=Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina. Per ogni dubbio potete chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum]}}<br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
===Pagine ad alta priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[dm-crypt with LUKS (Italiano)]]<br />
| Pagina da allineare e tradurre<br />
| maveloth<br />
| in corso<br />
|-<br />
| [[Disk_Encryption (Italiano)]]<br />
| Pagina da completare la traduzione<br />
| Dario<br />
| in corso<br />
|-<br />
|}<br />
<br />
=== Pagine a bassa priorità===<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Android (Italiano)]]<br />
| <br />
| SirX<br />
| In corso<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[PostgreSQL (Italiano)]]<br />
| Traduzione incompleta<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
==Revisioni==<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero: yyyy-mm-gg (es. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all<nowiki>'</nowiki>'''adozione''' del medesimo.<br />
<br />
===Adottare un wiki===<br />
<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e l'allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni:<br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra), oppure molto semplicemente andando sul wiki da seguire premere sul link '''Segui''' situato affianco a "Cronologia".<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
:{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc).<br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
===Tabella riassuntiva dei wiki revisionati e adottati===<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in due tabelle a seconda delle priorità ([[ArchWiki_Translation_Team_(Italiano)#Articoli Principali|Articoli Princpali]] e [[ArchWiki_Translation_Team_(Italiano)#Articoli Secondari|Articoli Secondari]]), in modo da avere le principiali guide di riferimento sempre aggiornate e sotto controllo. Lo scopo è quello di adottare per prima le pagine contenute nella tabella Articoli Principali, ed in un secondo momento occuparci degli altri articoli. Il contenuto delle tabelle viene discusso sul [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 froum] e può variare in base alle esigenze della comunità.<br />
<br />
Le tabelle contengono cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Redirect Ita''' - Vengono immessi qui i wiki con titolo italiano che hanno un ''redirect'' al wiki tradotto.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore. Qui immettendo '''Cedibile''' si rende pubblica la volontà di lasciare l'adozione di un wiki (in tal casoeliminare anche il proprio nome dalla colonna ''Revisore'').<br />
<br />
Le colonne contengono un link ''rapido'' di consultazione che effettua un ordinamento alfabetico.<br />
<br />
==== Articoli principali ====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture (Italiano)]]<br />
| 2012-02-22<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[AMD Catalyst (Italiano)]]<br />
| 2012-09-25<br />
| umby213<br />
| <br />
| da allineare<br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch Linux (Italiano)]]<br />
| 2012-04-30<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]]<br />
| 2012-09-06<br />
| Kynikos<br />
|<br />
| '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[ATI (Italiano)]]<br />
| 2012-02-20<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]]<br />
| 2012-11-04<br />
| Veleno77 <br />
| [[Guida per Principianti]]<br />
|<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]]<br />
| 2012-10-04<br />
| icetux <br />
| [[Configurazione della Rete]]<br />
|<br />
|-align="center"<br />
| [[CUPS (Italiano)]]<br />
| 2012-09-22<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[FAQ (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
| [[Domande Frequenti]]<br />
| la versione inglese sta variando molto, appena si stabilizza ri-allineo ;) --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 11:23, 22 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fstab (Italiano)]]<br />
| 2012-10-28<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[GNOME (Italiano)]]<br />
| 2011-12-3<br />
| Cylon<br />
|<br />
| In allineamento<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
| <br />
|-align="center"<br />
| [[Help:Style (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Installation Guide (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| [[Guida all'installazione]]<br />
| ''Official Installation Guide'' è redirect a questa pagina<br />
|-align="center"<br />
| [[Intel (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[KDE (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[Laptop (Italiano)]]<br />
| 2012-10-24<br />
| Nierro<br />
| <br />
|<br />
|--align="center"<br />
| [[Locale (Italiano)]]<br />
| 2012-10-07<br />
| Veleno77<br />
| <br />
|<br />
|-align="center"<br />
| [[Main Page (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Makepkg (Italiano)]]<br />
| 2012-02-28<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Nouveau (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[NVIDIA (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]]<br />
| 2012-10-04<br />
| icetux<br />
| [[Repository Ufficiali]]<br />
|<br />
|-align="center"<br />
| [[Openbox (Italiano)]]<br />
| 2012-02-07<br />
| 4javier <br />
|<br />
|<br />
|-align="center"<br />
| [[Pacman (Italiano)]]<br />
| 2012-09-18<br />
| Kynikos<br />
|<br />
| '''Cedibile''' (al momento non posso garantire più di un update al mese)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]]<br />
| 2012-01-19<br />
| Ninquitassar<br />
|<br />
| <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio/Examples (Italiano)]]<br />
| 2012-02-10<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[RAID (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[Start X at Login (Italiano)]]<br />
| 2011-09-20<br />
| Hilinus<br />
| [[Far partire X al boot]]<br />
|<br />
|- align="center"<br />
| [[Syslinux (Italiano)]]<br />
| 2012-08-01<br />
| Hilinus<br />
| <br />
| <br />
|-align="center"<br />
| [[Systemd (Italiano)]]<br />
| 2012-11-05<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[Systemd FAQ (Italiano)]]<br />
| 2012-11-04<br />
| ambro<br />
|<br />
|<br />
|-align="center"<br />
| [[SysVinit (Italiano)]]<br />
| 2012-11-01<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]]<br />
| 2012-09-06<br />
| icetux<br />
| [[Il Metodo Arch]]<br />
|<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Udev (Italiano)]]<br />
| 2011-12-08<br />
| ninquitassar<br />
|<br />
|<br />
|-align="center"<br />
| [[Unified Extensible Firmware Interface (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
| <br />
| <br />
|-align="center"<br />
| [[USB Installation Media (Italiano)]]<br />
| 2012-10-06<br />
| umby213<br />
| [[Installare da supporto USB]]<br />
|<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]]<br />
| 2012-11-04<br />
| Veleno77<br />
| [[Utenti e Gruppi]]<br />
| <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] <br />
| 2012-02-13<br />
| Hilinus<br />
| [[Configurazione Wireless]]<br />
|<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]]<br />
| 2012-02-07<br />
| Hilinus<br />
| <br />
|<br />
|-align="center"<br />
| [[Xfce (Italiano)]]<br />
| 2011-04-19<br />
| ninquitassar<br />
| <br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Xorg (Italiano)]] <br />
| 2011-12-06<br />
| ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
====Articoli secondari====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Redirect Ita<br />
! width="40%" | Note<br />
|-align="center"<br />
| [[Acer Extensa 5220 (Italiano)]]<br />
|<br />
|<br />
|<br />
| ok --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ACPI modules (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Acpid (Italiano)]]<br />
| 2012-10-13<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Activating Numlock on Bootup (Italiano)]]<br />
|<br />
|<br />
| [[Attivare Numlock all'Avvio]]<br />
| Out of date<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]]<br />
| 2012-09-14<br />
| umby213<br />
| [[Permettere Spegnimento agli Utenti]]<br />
|<br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Android Notifier (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Arch Compared to Other Distributions (Italiano)]]<br />
| 2012-01-19<br />
| Toketin<br />
| [[Arch Comparato con altre Distribuzioni]]<br />
| Da controllare la fromattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[ArchBang (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Arch Based Distributions (Active)]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Archiso (Italiano)]]<br />
| 2012-02-05<br />
|<br />
|<br />
| '''da riallineare''' -- [[User:Kynikos|Kynikos]] 07:06, 24 March 2012 (EDT)<br />
|-align="center"<br />
| [[ArchWiki:About (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Asus Eee PC 900A (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Autofs (Italiano)]]<br />
| 2012-01-19<br />
| <br />
||<br />
|<br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]]<br />
| 2012-09-20<br />
| umby213<br />
| [[Login Automatico in una console virtuale]]<br />
|<br />
|-align="center"<br />
| [[Awesome3 (Italiano)]]<br />
| 2011-01-06<br />
| Delcaran <br />
|<br />
| '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]]<br />
| 2012-02-01 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bluetooth (Italiano)]]<br />
| 2012-10-14<br />
| icetux <br />
|<br />
|<br />
|-align="center"<br />
| [[BOINC (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]]<br />
| 2012-01-19 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bootchart (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date; versione inglese segnata a sua volta come Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Burg (Italiano)]]<br />
| 2011-09-21<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[CD Burning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Chromium (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Cinergy T stick (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste; riferimenti a kernel26 --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[ClamAV (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Clyde (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Codecs (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]]<br />
| 2012-02-01<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Common Applications (Italiano)]]<br />
| 2011-12-16<br />
| Veleno77<br />
|<br />
|In fase di revisione, un riassunto è disponibile a [[Talk:Common Applications#Summary of related changes]]<br />
|-align="center"<br />
| [[Compiz (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Conky (Italiano)]]<br />
| 2011-09-21<br />
| Ninquitassar<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Connman (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[ConsoleKit (Italiano)]]<br />
| 2012-08-26<br />
| umby213<br />
|<br />
|<br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]]<br />
| 2012-11-03<br />
| Veleno77<br />
| [[Variazione di frequenza CPU]]<br />
|<br />
|-align="center"<br />
| [[Creating Packages (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Cwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Daemon (Italiano)]]<br />
| 2012-02-13<br />
| <br />
| [[Demoni]]<br />
|<br />
|-align="center"<br />
| [[Dell XPS M1530 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date e stub --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Deltup (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese "need expansions" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[DenyHosts (Italiano)]]<br />
|<br />
|<br />
|<br />
| le versioni sono allineate ma entrambe out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| [[Fotocamere Digitali]]<br />
|<br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Display Manager (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus <br />
| [[Avviare automaticamente un gestore login grafico all'avvio]]<br />
|<br />
|-align="center"<br />
| [[Dnsmasq (Italiano)]]<br />
| 2012-10-11<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]]<br />
| 2012-08-20<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Dropbox (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Drupal (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[E17 (Italiano)]]<br />
| 2012-09-05<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Eclipse Plugin Package Guidelines (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]]<br />
| 2012-09-03<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Evilwm (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
| <br />
|-align="center"<br />
| [[Exaile (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Execute on USB insert (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext3 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ext4 (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[FAM (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]]<br />
| 2012-01-26<br />
| <br />
| [[Controllo ventola CPU]]<br />
|-align="center"<br />
| [[Fbsplash (Italiano)]]<br />
| 2012-01-19<br />
| Cylon<br />
|<br />
| <br />
|-align="center"<br />
| [[Feh (Italiano)]]<br />
| 2012-08-24<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[File Systems (Italiano)]]<br />
| 2012-10-20<br />
| Veleno77<br />
| [[Formattare una Periferica]], [[Format a device (Italiano)]] è un redirect<br />
|<br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
| Versione inglese rinominata in [[Arch filesystem hierarchy]] [[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firefox (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Firewalls (Italiano)]]<br />
| 2012-11-04<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox (Italiano)]]<br />
| 2012-08-23<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Font Configuration (Italiano)]]<br />
| 2012-09-11<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Fonts (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[FVWM (Italiano)]]<br />
| 2012-10-30<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Games (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese diversa da quella italiana --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Gamin (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come "stub"; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]]<br />
| 2012-01-19<br />
| asa <br />
| [[Raccomandazioni Generali]] [[Suggerimenti Post Installazione]]<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]]<br />
| 2012-03-12<br />
| Kynikos<br />
| [[Come contribuire]]<br />
| '''Cedibile''', '''da riallineare''' -- [[User:Kynikos|Kynikos]] 06:51, 13 March 2012 (EDT)<br />
|-align="center"<br />
| [[Gnome 2.28 Changes (Italiano)]]<br />
| 2012-08-16<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]]<br />
| 2011-03-22<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Google Earth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione italiana più completa di quella inglese; credo che comunque sia da rivedere e aggiornare --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Grub-gfx (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; versione inglese a sua volta out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[GRUB Legacy (Italiano)]]<br />
| 2012-09-12<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[GTK+ (Italiano)]]<br />
| 2012-08-28<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[HAL (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Hal è deprecato''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Hardware Diagnostics (Italiano)]]<br />
|<br />
|<br />
| [[Diagnostica Hardware]]<br />
| Segnata come "out of date"; non esiste versione inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Help:Editing (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date<br />
|-align="center"<br />
| [[High Performance Firewall (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese segnata come: poorly written, merging in [[Router]]; out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[IceWM (Italiano)]]<br />
| 2012-05-06<br />
| umby213<br />
| <br />
| Versione inglese segnata come ''poorly written''<br />
|-align="center"<br />
| [[Improve Pacman Performance (Italiano)]]<br />
| 2012-02-04<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]]<br />
| 2012-02-02<br />
| Stele<br />
|<br />
|-align="center"<br />
| [[Install from SSH (Italiano)]]<br />
| 2012-06-15<br />
| Stele<br />
|<br />
|<br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Internet key Momo Design (Italiano)]]<br />
|<br />
|<br />
|<br />
| la versione inglese è scritta in italiano '''Controllare allineamento''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Internet Share (Italiano)]]<br />
|<br />
|<br />
| [[Condivisione connessione internet]]<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:39, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Intel C++ (Italiano)]] <br />
| 2012-09-16<br />
| bred<br />
|<br />
|<br />
|-align="center"<br />
| [[Iptables (Italiano)]]<br />
| 2012-10-19<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[Java (Italiano)]]<br />
| 2012-10-26<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[JWM (Italiano)]]<br />
| 2012-01-19<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[KDM (Italiano)]]<br />
| 2012-03-28<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]]<br />
| 2010-12-30<br />
| <br />
|<br />
| Versione inglese "need expansions"; entrambe le pagine puntano a kernel26<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]]<br />
| 2012-08-08<br />
| Kynikos<br />
|<br />
| da riallineare -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:09, 4 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernel Panics (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Kernels (Italiano)]]<br />
| 2012-04-01<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Arch Build System (Italiano)]]<br />
| 2012-03-23<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Script (Italiano)]]<br />
| 2012-04-09<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernels/Compilation/Traditional (Italiano)]]<br />
| 2012-04-20<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[KVM (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[LAMP (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]]<br />
| 2012-11-05<br />
| veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[LVM (Italiano)]]<br />
| 2012-11-05<br />
| maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[LXDE (Italiano)]]<br />
| 2011-01-06<br />
| xaber<br />
|<br />
| La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[MacBook (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]]<br />
| 2012-10-01<br />
| maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[MATE (Italiano)]]<br />
| 2012-07-29<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mathematica (Italiano)]]<br />
|<br />
|<br />
|<br />
| Segnate come "stub" entrambe le versioni --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Media Center (Italiano)]]<br />
| <br />
| Stele<br />
|<br />
| '''É una pagina italiana e non ha il corrispettivo inglese'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]]<br />
| 2012-09-25<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]]<br />
| 2012-02-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Mpd (Italiano)]]<br />
| 2011-01-08<br />
| Delcaran<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[MPlayer (Italiano)]]<br />
| 2012-08-20<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Mutt (Italiano)]]<br />
| 2012-07-06<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[MySQL (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Namcap (Italiano)]]<br />
| 2012-09-29<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Nano (Italiano)]]<br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]]<br />
| 2012-01-14<br />
| Ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Netcfg (Italiano)]]<br />
| 2012-10-03<br />
| Toketin<br />
|<br />
|<br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]]<br />
| 2012-10-14<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[NetworkManager (Italiano)]]<br />
| 2012-09-15<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[NFS (Italiano)]]<br />
| 2012-01-27<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[NFSv4 (Italiano)]]<br />
| 2012-02-18<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Notify OSD (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese è redirect a [[Unity]] --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Ntop (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]]<br />
| 2012-01-19<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[OpenOffice (Italiano)]] <br />
|<br />
|<br />
|<br />
| Scritta in inglese e Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Opera (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Osiris (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese non esiste --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[OSS (Italiano)]]<br />
| 2012-01-19<br />
| asa<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman GUI Frontends (Italiano)]]<br />
|<br />
|<br />
| [[Interfacce Grafiche per Pacman]]<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacman Tips (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pacnew and Pacsave Files (Italiano)]]<br />
|<br />
|<br />
| [[File Pacnew e Pacsave]]<br />
| out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Palm Pre (Italiano)]]<br />
|<br />
|<br />
|<br />
| Versione inglese scritta in italiano --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Partitioning (Italiano)]]<br />
| 2012-07-12<br />
| <br />
|<br />
| Out of date [[User:Veleno77|Veleno]] ([[User talk:Veleno77|talk]]) 18:26, 30 September 2012 (UTC)<br />
|-align="center"<br />
| [[Password Recovery (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[Pawm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[PekWM (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]]<br />
| 2011-09-23<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Plymouth (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]]<br />
| 2012-10-06<br />
| Nierro<br />
|<br />
|<br />
|-align="center"<br />
| [[Powerpill (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Privoxy (Italiano)]]<br />
| 2011-09-08<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Readline (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Samba (Italiano)]]<br />
| 2011-11-02<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Secure Shell (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]]<br />
| 2011-10-20<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[SLiM (Italiano)]]<br />
| 2012-09-30<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Small Business Server (Italiano)]]<br />
|<br />
|<br />
|<br />
| '''Pagina italiana più aggiornata, contiene sottopagine''' [[User:Veleno77|Veleno]] 18:02, 10 March 2012 (EST)<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]]<br />
| 2011-09-05<br />
|<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]]<br />
| 2011-02-21<br />
| asa<br />
|<br />
|<br />
|-align="center"<br />
| [[SSH Keys (Italiano)]]<br />
| 2011-12-17<br />
|<br />
|<br />
| '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sshfs (Italiano)]]<br />
| 2011-11-13<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sudo (Italiano)]]<br />
| 2011-12-06<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Sugar (Italiano)]]<br />
| 2012-07-16<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[swap (Italiano)]]<br />
| 2012-09-17<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Synergy (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| '''Cedibile'''<br />
|-align="center"<br />
| [[Table of Contents (Italiano)]]<br />
| 2012-09-04<br />
| Kynikos<br />
|<br />
| La struttura della lista viene aggiornata automaticamente e periodicamente da [[User:Kynikos.bot|Kynikos.bot]]<br />
|-align="center"<br />
| [[TeXLive (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[The Arch Way v2.0 (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Thunar (Italiano)]]<br />
| 2012-09-24<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Thunderbird (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of Date; scritta in inglese --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]]<br />
| 2011-10-09<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[TuPac (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]]<br />
| 2012-02-26<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Twm (Italiano)]]<br />
| 2012-11-01<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]]<br />
| 2011-06-02<br />
| Ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[USB Storage Devices (Italiano)]]<br />
|<br />
|<br />
|<br />
| Out of date<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]]<br />
| 2012-01-31<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Uvesafb (Italiano)]]<br />
| 2011-10-17<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]]<br />
| 2012-02-07<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]]<br />
| 2011-09-28<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Vim (Italiano)]]<br />
| 2012-05-15<br />
|<br />
| <br />
| '''Da riallineare''' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 12 July 2012 (UTC)<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]]<br />
| 2012-01-19<br />
|<br />
| <br />
|<br />
|-align="center"<br />
| [[VirtualBox (Italiano)]]<br />
| 2011-03-21<br />
| ant84<br />
|<br />
|<br />
|-align="center"<br />
| [[VMware (Italiano)]]<br />
| 2012-02-02<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Webmin (Italiano)]]<br />
| 2011-08-10<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Wicd (Italiano)]]<br />
| 2011-12-08<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Window Maker (Italiano)]]<br />
| 2012-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Window Manager (Italiano)]]<br />
| 2012-02-02<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[Wine (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Xampp (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[xf86-video-sis (Italiano)]]<br />
| 2012-10-06<br />
| <br />
| <br />
|<br />
|-align="center"<br />
| [[XFS (Italiano)]]<br />
|<br />
|<br />
|<br />
| out of date; versione inglese segnata come "stub" --[[User:Umby213|Umby213]] ([[User talk:Umby213|talk]]) 17:51, 24 September 2012 (UTC)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] <br />
| 2012-09-02<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Yaourt (Italiano)]]<br />
| 2012-09-19<br />
| umby213<br />
| <br />
|}<br />
<br />
==Staff tecnico==<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Coordinatore<br />
:# [[User:4javier|4javier]]<br />
:# [[User:Kynikos|Kynikos]] - [[ArchWiki:Administrators|Amministratore ArchWiki ]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
:# [[User:love89|Love89]]<br />
:# [[User:maveloth|maveloth]]<br />
:# [[User:nierro|Nierro]]<br />
:# [[User:Dariocent|Dario]]<br />
<br />
==Ulteriori informazioni e supporto==<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?f=19&t=8483 forum italiano].</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=233964Systemd (Italiano)2012-11-05T22:13:59Z<p>Ambro: fix type</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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}}. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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 (when {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''not''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
==== systemd-analyze ====<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=233963Systemd (Italiano)2012-11-05T22:11:44Z<p>Ambro: Allineamento al 05.11.2012 21:23</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<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 />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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}}. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
== Avviare un DE 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 />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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 (when {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''not''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
=== systemd-analyze ===<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=233757Systemd (Italiano)2012-11-04T23:40:17Z<p>Ambro: fix type</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<br />
<br />
=== Informazioni supplementari ===<br />
<br />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 />
<br />
== Configurazione nativa ==<br />
<br />
{{Nota|E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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}}. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<br />
<br />
== Esempi d'uso dei comandi basilari ==<br />
<br />
*{{ic|systemctl}}: utilizzato per controllare lo stato del gestore di servizi e del sistema systemd<br />
*{{ic|systemd-cgls}}: mostra ricorsivamente i contenuti della gerarchia del gruppo di controllo Linux selezionato con uno schema ad albero<br />
*{{ic|systemadm}}: Un frontend grafico per systemd che permette un profondo controllo del sistema (disponibile attraverso il pacchetto {{AUR|systemd-ui-git}} di [[AUR]]).<br />
<br />
Vedi le pagine man per ulteriori 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 />
=== 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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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 (when {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''not''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Avviare un DE 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 />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
=== systemd-analyze ===<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Attivare readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Forzare l'avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)/FAQ_(Italiano)&diff=233756Systemd (Italiano)/FAQ (Italiano)2012-11-04T23:13:06Z<p>Ambro: Allineamento al 29.10.2012 14:59</p>
<hr />
<div>[[Category:Daemons and system services (Italiano)]]<br />
[[Category:Boot process (Italiano)]]<br />
[[en:Systemd FAQ]]<br />
== FAQ ==<br />
<br />
Per una lista aggiornata dei problemi conosciuti, vedere il [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].<br />
<br />
{{FAQ<br />
|question=Perché non ricevo messaggi di log sulla console?<br />
|answer=Si deve configurare il proprio livello di log. Un tempo, {{ic|/etc/rc.sysinit}} lo faceva e configurava il livello di log di dmesg a {{ic|3}}, che era un ragionevole livello. Ora aggiungere {{ic|1=loglevel=3}} o {{ic|quiet}} ai [[kernel parameters|parametri del kernel]].}}<br />
<br />
{{FAQ<br />
|question=Come posso cambiare il numero di console funzionanti di default?<br />
|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/}} :<br />
<br />
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service<br />
# systemctl start getty@tty9.service<br />
<br />
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella {{ic|/etc/systemd/system/getty.target.wants/}} :<br />
<br />
# rm /etc/systemd/system/getty.target.wants/getty@{tty5,tty6}.service<br />
# systemctl stop getty@tty5.service getty@tty6.service<br />
Gli utenti possono cambiare il numero delle console anche editando {{ic|/etc/systemd/logind.conf}} e cambiando il valore di {{ic|NAutoVTs}}. Seguendo questo metodo, l'attivazione al bisogno sarà preservata, mentre con il metodo iniziale semplicemente si avranno le console funzionanti al boot.<br />
<br />
systemd non usa il file /etc/inittab.<br />
<br />
{{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.}}}}<br />
<br />
<br />
{{FAQ<br />
|question=Come posso ottenere un output più dettagliato durante l'avvio?<br />
|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.<br />
<br />
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}}.}}<br />
<br />
{{FAQ<br />
|question=Come evitare che la console sia pulita dopo l'avvio?<br />
|answer=Creare un file g{{ic|getty@tty1.service}} personalizzato copiando {{ic|/usr/lib/systemd/system/getty@.service}} in {{ic|/etc/systemd/system/getty@tty1.service}} e cambiando {{ic|TTYVTDisallocate}} in {{ic|no}}.<br />
}} e si permette l'esportazione di {{ic|LANG}} in {{ic|/etc/locale.conf}}<br />
<br />
{{FAQ<br />
|question=Quali opzioni del kernel occorrono attive nel mio kernel nel caso non usassi il kernel Arch ufficiale?<br />
|answer=I Kernels precedenti al 2.6.39 non sono supportati.<br />
<br />
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:<br />
<br />
{{bc|1='''General setup'''<br />
CONFIG_FHANDLE=y<br />
CONFIG_AUDIT=y (raccomandata)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non raccomandata, può danneggiare la compatibilità con sysvinit)<br />
CONFIG_CGROUPS=y<br />
'''-> Namespaces support'''<br />
CONFIG_NET_NS=y (per reti private)<br />
'''Networking support -> Networking options'''<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>m] (altamente raccomandata)<br />
'''Device Drivers'''<br />
'''-> Generic Driver Options'''<br />
CONFIG_UEVENT_HELPER_PATH=""<br />
CONFIG_DEVTMPFS=y<br />
CONFIG_DEVTMPFS_MOUNT=y (richiesta se non si usa un initramfs)<br />
'''-> Real Time Clock'''<br />
CONFIG_RTC_DRV_CMOS=y (altamente raccomandata)<br />
'''File systems'''<br />
CONFIG_FANOTIFY=y (richiesta per readahead)<br />
CONFIG_AUTOFS4_FS=[y<nowiki>|</nowiki>m]<br />
'''-> Pseudo filesystems'''<br />
CONFIG_TMPFS_POSIX_ACL=y (raccomandata se si vuole usare pam_systemd.so)}}}}<br />
<br />
{{FAQ<br />
|question=Quali altre unità dipendono da una unità?<br />
|answer=Per esempio, se si vuole evidenziare quali servizi e target attiva {{ic|multi-user.target}}, si usi qualcosa del genere: <br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}<br />
<br />
Invece di {{ic|Wants}} si può provare {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} per i rispettivi tipi di dipendenza e il loro contrario.}}<br />
<br />
{{FAQ<br />
|question=Il mio computer si spegne, ma l'alimentatore resta acceso.<br />
|answer=Usare<br />
<br />
$ systemctl poweroff<br />
<br />
invece di {{ic|systemctl halt}}.}}<br />
<br />
{{FAQ<br />
|question=Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?<br />
|answer=Assicurarsi di usare <br />
<br />
# systemctl enable dmraid.service<br />
}}<br />
<br />
{{FAQ<br />
|question=Come posso fare in modo che uno script sia eseguito al boot?<br />
|answer=Creare un nuovo file in {{ic|/etc/systemd/system}} (e.g. "myscript".service) e aggiungere il seguente contenuto:<br />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service] <br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Poi<br />
<br />
# systemctl enable "myscript".service<br />
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato.<br />
'''Nota:''' Nel caso si voglia avviare uno script di schell, assicurarsi di avere<br />
#!/bin/sh<br />
<br />
nella prima riga dello script. Non scrivere qualcosa come<br />
<br />
ExecStart=/bin/sh /path/to/script.sh # NON FUNZIONA<br />
<br />
perché non funziona.}}<br />
<br />
{{FAQ<br />
|question=Lo stato del .service dice "active (exited)" in verde. (per iptables)<br />
|answer=Ciò è perfettamente normale.<br />
Nel caso specifico di iptables è perché non c'è nessun demone da avviare, è controllato dal kernel. Tuttavia esiste dopo che le regole sono state caricate.<br />
Per verificare se le regole di iptables sono state caricate correttamente:<br />
{{bc|# iptables --list}}<br />
}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=Questo accade quando si usa {{ic|systemctl enable}} e si tenta di creare il link simbolico in {{ic|/etc/systemd/system/}} ed esiste già. Di solito accade quando si passa da un display manager ad un altro (per esempio da GDM a KDM, che possono essere abilitati con {{ic|gdm.service}} e {{ic|kdm.service}}, rispettivamente) e il link simbolico corrispondente {{ic|/etc/systemd/system/display-manager.service}} esiste già.<br />
Per risolvere il problema usare {{ic|systemctl -f enable}} per sovrascrivere link simbolici già esistenti.<br />
}}</div>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=233755Systemd (Italiano)2012-11-04T23:03:10Z<p>Ambro: Allineamento al 04.11.2012 19:18</p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. <br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<br />
<br />
=== Informazioni supplementari ===<br />
<br />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 />
<br />
== Configurazione nativa ==<br />
<br />
{{Nota|E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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 automaticamente 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 mentre {{ic|/home}} è controllata. Questo può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* Lo stesso si può applicare al ontaggio 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<br />
<br />
== Esempi d'uso dei comandi basilari ==<br />
<br />
*{{ic|systemctl}}: utilizzato per controllare lo stato del gestore di servizi e del sistema systemd<br />
*{{ic|systemd-cgls}}: mostra ricorsivamente i contenuti della gerarchia del gruppo di controllo Linux selezionato con uno schema ad albero<br />
*{{ic|systemadm}}: Un frontend grafico per systemd che permette un profondo controllo del sistema (disponibile attraverso il pacchetto {{AUR|systemd-ui-git}} di [[AUR]]).<br />
<br />
Vedi le pagine man per ulteriori 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 />
=== 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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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 (when {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''not''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Avviare un DE 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 />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
=== systemd-analyze ===<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Attivare readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Forzare l'avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambrohttps://wiki.archlinux.org/index.php?title=Systemd_(Italiano)&diff=233636Systemd (Italiano)2012-11-04T15:54:15Z<p>Ambro: </p>
<hr />
<div>[[Category: Daemons and system services (Italiano)]]<br />
[[Category: Boot process (Italiano)]]<br />
[[en:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN: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/Services}} <br />
{{Article summary wiki|Systemd_FAQ_(Italiano)}} - FAQs<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}} <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. Può funzionare come rimpiazzo totale di [[SysVinit|sysvinit]]."''<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 />
Leggi anche l' articolo su [[Wikipedia:Systemd|Wikipedia]].<br />
<br />
== Cose da considerare prima di passare a systemd ==<br />
<br />
* E' fortemente consigliato passare al nuovo sistema di configurazione degli '''initscripts''' descritto nell' [[Rc.conf|articolo relativo a rc.conf]]. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.<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 />
<br />
==Installazione==<br />
<br />
Systemd può essere installato a fianco del normale pacchetto {{pkg|initscripts}} di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo {{ic|1=init=/usr/lib/systemd/systemd}} dai [[kernel parameters|parametri del kernel]].<br />
<br />
=== Una installazione mista systemd/sysvinit/initscripts ===<br />
<br />
E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:<br />
<br />
# Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante [[#Configurazione_nativa|una configurazione nativa di systemd]], e riavviare per verificare che gli initscripts funzionino come ci si aspetta. <br />
# Installare {{Pkg|systemd}} dai [[Official Repositories|repo ufficiali]].<br />
# Aggiungere {{ic|1=init=/usr/lib/systemd/systemd}} ai [[kernel parameters|parametri del kernel]] nel bootloader.<br />
# Riavviare.<br />
<br />
Systemd avvierà i demoni in {{ic|/etc/rc.conf}} e avvierà {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} all'avvio o allo spegnimento (vedi [[#Emulazione_degli_Initscripts]] più sotto). Se il vecchio supporto per {{ic|DAEMONS}} in {{ic|rc.conf}} o lo script in {{ic|rc.local}} non è necessario, il corrispondente servizio li disabiliterà.<br />
<br />
Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da {{ic|/etc/inittab}} non partirà, in quanto systemd non usa {{ic|inittab}}. La pagina del wiki per i [[Display_Manager_(Italiano)|login manager]] spiega come aggiungerli ai servizi di systemd.<br />
<br />
{{Attenzione|In caso si abbiano demoni nella riga {{ic|DAEMONS}} che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il 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.}}<br />
<br />
{{Attenzione|Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite {{ic|DAEMONS}}. In particolare {{ic|network}} essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a [[Netcfg_(Italiano)|netcfg]] o [[NetworkManager_(Italiano)|NetworkManager]] prima di inoltrarsi in systemd. }}<br />
<br />
=== Una installazione mista systemd/initscripts ===<br />
<br />
E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere [[#Initscripts emulation]] più sotto).<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts <br />
# [[#Usare_le_unit.C3.A0|Attivare i demoni]] formalmente elencati in {{ic|/etc/rc.conf}} con {{ic|systemctl enable "daemonname"}}. Per una traduzione dei demoni da {{ic|/etc/rc.conf}} ai servizi di systemd, vedere: [[Daemons List|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 avviarli dal vecchio rc scripts.<br />
# Installare {{Pkg|systemd-sysvcompat}}. Questo va in conflitto con {{Pkg|sysvinit}}, e ne chiederà la rimozione.<br />
# Rimuovere {{ic|1=init=...}} dai parametri del bootloader in quanto {{ic|/sbin/init}} ora è un link simbolico a systemd.<br />
# Riavviare.<br />
<br />
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.<br />
<br />
=== Una installazione pura di systemd ===<br />
<br />
Infine, è possibile rimuovere interamente {{pkg|initscripts}} e {{pkg|sysvinit}} e usare solo systemd.<br />
<br />
# Seguire le istruzioni per una installazione mista systemd/initscripts<br />
# Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di {{ic|/etc/rc.conf}} e che {{ic|/etc/rc.local}} e {{ic|/etc/rc.local.shutdown}} siano entrambi vuoti. Per replicare le funzionalità di {{ic|/etc/rc.local}} in systemd, vedere [[#Emulare_.2Fetc.2Frc.local]].<br />
# Rimuovere il pacchetto {{pkg|initscripts}} dal sistema.<br />
<br />
{{Attenzione|'''Non''' rimuovere {{pkg|systemd-sysvcompat}} finché il pacchetto si trova nel gruppo {{grp|base}}.<br />
<br />
=== Informazioni supplementari ===<br />
<br />
*Con systemd l'aggiunta del proprio utente ai [[Users and Groups|gruppi]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, ...) '''non''' è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via [[Wikipedia:Access control list|POSIX ACLs]] sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di [[udisks]]. <br />
<br />
{{Nota|Systemd-logind rimpiazza[[ConsoleKit]] il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] per maggiori informazioni.}}<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 />
<br />
== Configurazione nativa ==<br />
<br />
{{Nota|E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root}}<br />
<br />
=== Hostname ===<br />
L'hostname è configurato in {{ic|/etc/hostname}}. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:<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 />
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 />
{{Nota|Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in {{ic|/etc/locale.gen}} e poi eseguendo {{ic|locale-gen}} da root. Quella configurata con {{ic|localectl}} deve essere una di quelle '''decommentate''' in {{ic|/etc/locale.gen}}.}}<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 />
Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.<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 />
=== Settare il fuso orario ===<br />
<br />
Il fuso orario è configurato creando un apposito link simbolico in {{ic|/etc/localtime}} che punti ad un file di informazioni sulla zona in {{ic|/usr/share/zoneinfo/}}. Per farlo automaticamente:<br />
<br />
# timedatectl set-timezone Europe/Rome<br />
<br />
Leggere {{ic|man 1 timedatectl}} e {{ic|man 5 localtime}} per maggiori dettagli.<br />
<br />
In alternativa creare manualmente il collegamento:<br />
<br />
# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime<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 che Windows usi UTC, piuttosto che Linux usi localtime.<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 />
==== 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 automaticamente 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 mentre {{ic|/home}} è controllata. Questo può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di {{ic|/home}} in 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 />
* Lo stesso si può applicare al ontaggio 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 {{ic|lvm.service}} (fornito dal pacchetto {{pkg|lvm2}} ):<br />
<br />
# systemctl enable lvm<br />
<br />
Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da {{ic|/etc/crypttab}}), attivare {{ic|lvm-on-crypt.service}} (anch'esso fornito dal pacchetto {{pkg|lvm2}}):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd gestisce degli eventi 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}} or {{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 />
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, 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à.}}<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 />
==== Sleep hooks ====<br />
Systemd non usa [[pm-utils]] per mettere la macchina a riposo quando usa {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}, Quindi gli hooks di [[Pm-utils_(Italiano)|Pm-utils]] incluso qualsiasi [[Pm-utils_(Italiano)#Creazione_di_un_Hook_personale|hook personalizzato]] si sia creato non funzionerà. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in {{ic|/usr/lib/systemd/system-sleep/}} e passa due argomenti a ognuno di essi:<br />
* Argument 1: o {{ic|pre}} o {{ic|post}}, a seconda che la macchina si stia addormentando o svegliando<br />
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dipende da cosa è 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 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]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Nota che è possibile usare anche {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} per agganciare le unità allo stato di sospensione invece di usare degli scripts.<br />
<br />
Esempio:<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 />
Vedere {{ic|man 7 systemd.special}} e {{ic|man 8 systemd-sleep}} per dettagli.<br />
<br />
=== I files 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|/var/run/samba}} per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
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:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più {{ic|/etc/rc.local}}.<br />
<br />
Vedi {{ic|man 5 tmpfiles.d}} per i dettagli.<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 />
== Transizione da initscripts a systemd ==<br />
<br />
=== Emulazione degli Initscripts ===<br />
<br />
L'integrazione con la classica configurazione di Arch è garantita dal pacchetto {{Pkg|initscripts}}. Quando {{Pkg|initscripts}} sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:<br />
<br />
# Analizzare la riga {{ic|DAEMONS}} di {{ic|/etc/rc.conf}} e avviare tutti i demoni elencati all'avvio<br />
# Eseguire {{ic|/etc/rc.local}} durante l'avvio<br />
# Eseguire {{ic|/etc/rc.local.shutdown}} durante lo spegnimento<br />
<br />
L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e '''eventualmente tornare indietro'''. Systemd nativo non invoca la configurazione centralizzata in {{ic|rc.conf}}, cosicché è raccomandato usare [[#Configurazione_nativa| i files di configurazione nativa di systemd]], i quali avranno la precedenza su {{ic|/etc/rc.conf}}.<br />
<br />
{{Nota|Se si disabilita {{keypress|Ctrl+Alt+Canc}} per riavviare in {{ic|/etc/inittab}}, occorrerà riconfigurarlo per systemd digitando {{ic|systemctl mask ctrl-alt-del.target}} da root.}}<br />
<br />
=== Abbandonare la riga DAEMONS ===<br />
<br />
Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file {{ic|/etc/rc.conf}} ed avviare i servizi solo tramite {{ic|systemctl}}. Per ogni {{ic|<service_name>}} nella riga {{ic|DAEMONS}} in {{ic|/etc/rc.conf}}, digitare:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Suggerimento|Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere [[Daemons List|questa tabella]].}}<br />
<br />
Se {{ic|<service_name>.service}} non esiste:<br />
<br />
* Probabilmente, systemd usa un diverso nome. Per esempio, {{ic|cronie.service}} rimpiazza il demone di init {{ic|crond}}; {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} rimpiazzano il demone di init {{ic|alsa}}. Un'altra importante differenza è il demone {{ic|network}}, il quale è rimpiazzato con un'altra serie di servizi (vedere [[Configuring Network]] per maggiori dettagli.)<br />
* in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere {{ic|rc.conf}} per avviare il servizio all'avvio.<br />
<br />
{{Suggerimento|E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Servizio di systemd corrispondente<br />
[...]<br />
}}<br />
<br />
* Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, {{ic|dbus.service}} sarà automaticamente attivato con l'installazione di {{ic|dbus-core}}. {{ic|alsa-store.service}} e {{ic|alsa-restore.service}} sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando {{ic|systemctl}} in questo modo:<br />
{{ic|systemctl status <service_name>}}<br />
<br />
=== Tavola di comparazione tra la vecchia configurazione e quella nativa ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Configurazione<br />
! scope="col"| Files di configurazione<br />
! scope="col"| Vecchia sezione [https://projects.archlinux.org/initscripts.git/tree/rc.conf?id=97f0cd6751e8d22c14d7492cdc2186cf41157ba6 rc.conf] <br />
|-<br />
| align="center"|Hostname<br />
| align="left"|{{ic|/etc/hostname}}<br />
{{ic|/etc/hosts}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|-<br />
| align="center"|Console font and keymap<br />
| align="left"|{{ic|/etc/vconsole.conf}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Locale<br />
| align="left"|{{ic|/etc/locale.conf}}<br />
{{ic|/etc/locale.gen}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Time zone<br />
| align="left"|{{ic|/etc/localtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Hardware clock<br />
| align="left"|{{ic|/etc/adjtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Kernel modules<br />
| align="left"|{{ic|/etc/modules-load.d/}}<br />
| align="center"|{{ic|HARDWARE}}<br />
|}<br />
<br />
=== Emulare /etc/rc.local ===<br />
<br />
Se si vuole mantenere la semplicità di {{ic|/etc/rc.local}} in systemd, occorre creare il seguente servizio ed abilitarlo. Aggiungere solo tante linee {{ic|1=ExecStart=}} quanti i comandi da avviare. Se si ha bisogno di funzionalità più avanzate (come ad esempio cicli {{ic|for}}), si può creare un script Bash ed eseguirlo dal servizio. Rimuovere {{ic|1=ExecStart=/bin/true}} quando si aggiunge un vero comando qui.<br />
<br />
{{hc|/etc/systemd/system/rc-local.service|<nowiki><br />
[Unit]<br />
Description=/etc/rc.local compatibility<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/true<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Esempi d'uso dei comandi basilari ==<br />
<br />
*{{ic|systemctl}}: utilizzato per controllare lo stato del gestore di servizi e del sistema systemd<br />
*{{ic|systemd-cgls}}: mostra ricorsivamente i contenuti della gerarchia del gruppo di controllo Linux selezionato con uno schema ad albero<br />
*{{ic|systemadm}}: Un frontend grafico per systemd che permette un profondo controllo del sistema (disponibile attraverso il pacchetto {{AUR|systemd-ui-git}} di [[AUR]]).<br />
<br />
Vedi le pagine man per ulteriori 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 />
=== 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 monatggio ({{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| 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.<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 />
=== Power management ===<br />
<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 />
Spegnimento completo del sistema:<br />
<br />
$ systemctl halt<br />
<br />
Sospensione del sistema:<br />
<br />
$ systemctl suspend<br />
<br />
Ibernazione del sistema:<br />
<br />
$ systemctl hibernate<br />
<br />
==Scrivere i files .service personalizzati==<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}}: 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=}} 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 />
Le unità in {{ic|/etc/systemd/system/}} hanno la precedenza su quelle in {{ic|/usr/lib/systemd/system/}}.<br />
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:<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<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 reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Suggerimento|Si può usare {{ic|systemd-delta}} per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.}}<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 {{AUR|vim-systemd}} da [[Arch User Repository|AUR]].<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 />
== 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 (when {{ic|Storage&#61;}} è configurato a {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), il journal scrive in {{ic|/var/log/journal/}}. Se la directory {{ic|/var/log/journal/}} non esiste (o per esempio se qualche programma lo cancellasse), systemd '''not''' lo creerà automaticamente, ma invece lo scriverà 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 />
Mostra tutti i messaggi di un eseguibile specifico:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Mostra tutti i messaggi di uno specifico processo:<br />
<br />
# journalctl _PID=1<br />
<br />
Mostra tutti i messaggi di una specifica unità:<br />
<br />
# journalctl -u netcfg<br />
<br />
<br />
Vedi {{ic|man journalctl}} e {{ic|systemd.journal-fields}} 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 />
<br />
== Avviare un DE 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 />
== Ottimizzazioni ==<br />
<br />
=== Analizzare il processo di boot ===<br />
<br />
=== systemd-analyze ===<br />
<br />
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.<br />
<br />
Per vedere quanto tempo ha impiegato il boot del kernel e dello userspace, semplicemente si usi:<br />
<br />
$ systemd-analyze<br />
<br />
{{Suggerimento|Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a {{ic|timestamp}} al parametro {{ic|HOOKS}} in {{ic|/etc/[[mkinitcpio]].conf}} e, con root, ricostruire l'initramfs con {{ic|mkinitcpio -p linux}} }}<br />
<br />
Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:<br />
<br />
$ systemd-analyze blame<br />
<br />
Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
====Usare bootchart====<br />
<br />
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:<br />
<br />
# systemctl enable bootchart<br />
<br />
Leggere la [https://github.com/mmeeks/bootchart documentazione di bootchart] per ulteriori dettagli sull'uso di questa versione di bootchart.<br />
<br />
=== Attivare readahead ===<br />
<br />
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:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.<br />
<br />
=== Forzare l'avvio anticipato dei servizi ===<br />
<br />
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 [[UPower]]) 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:<br />
<br />
# systemctl enable upower<br />
<br />
Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.<br />
<br />
=== Diminuire l'output ===<br />
<br />
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.<br />
<br />
=== Tasti di scelta rapida della Shell ===<br />
<br />
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.<br />
<br />
{{bc|<br />
<br />
# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<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 />
== 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/Booting-up-Tools-and-tips-for-systemd-1570630.html Avviamento: Strumenti e consigli per systemd, uno strumento di avvio di Linux.]<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>Ambro