< Systemd
m (→Riferimenti: Correzione del link) |
|||
(31 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
{{autolang}} | {{autolang}} | ||
systemd è un sistema ed un manager di servizi per Linux, compatibile con SysV e LSB init scripts. systemd fornisce potenti capacità di parallelizzazionne, usa attivazioni socket e D-Bus per avviare i servizi, offre inizializzazioni di demoni su richiesta, tiene traccia dei processi usando ''Linux cgroups'', supporta lo snapshotting ed il ripristino dello stato del sistema, mantiene il mount e l'automount ed implementa un servizio logico di controllo. Può lavorare come rimpiazzo per ''sysvinit''. Per maggiori informazioni sono disponibili i video http://linuxconfau.blip.tv/file/4696791/ o http://www.youtube.com/watch?v=TyMLi8QF6sw | |||
systemd è un sistema ed un manager di servizi per Linux, compatibile con SysV e LSB init scripts. systemd fornisce potenti capacità di parallelizzazionne, usa attivazioni socket e D-Bus per avviare i servizi, offre inizializzazioni di demoni su richiesta, tiene traccia dei processi usando ''Linux cgroups'', supporta lo snapshotting ed il ripristino dello stato del sistema, mantiene il mount e l'automount ed implementa un servizio logico di controllo. Può lavorare | |||
{{admon/note|Per gli amministratori di sistema| | {{admon/note|Per gli amministratori di sistema| | ||
Line 17: | Line 15: | ||
# <code>service</code>: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati. | # <code>service</code>: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati. | ||
# <code>socket</code>: questa unità contiene un socket nel file-system o su Internet. systemd attualmente supporta i socket AF_INET, AF_INET6, AF_UNIX di tipo ''stream'', ''datagram'' e ''sequential packet''. Può inoltre supportare i classici FIFO come ''transport''. Ogni unità socket ha un servizio corrispondente, che viene inizializzato se la prima connessione avviene sul socket o FIFO (ad esempio ''nscd.socket | # <code>socket</code>: questa unità contiene un socket nel file-system o su Internet. systemd attualmente supporta i socket AF_INET, AF_INET6, AF_UNIX di tipo ''stream'', ''datagram'' e ''sequential packet''. Può inoltre supportare i classici FIFO come ''transport''. Ogni unità socket ha un servizio corrispondente, che viene inizializzato se la prima connessione avviene sul socket o FIFO (ad esempio ''nscd.socket'' inizializza ''nscd.service'' su una connessione in ingresso). | ||
# <code>device</code>: questa unità incapsula un dispositivo nell'albero dei dispositivi Linux. Se uno di loro viene contrassegnato attraverso una regola ''udev'' (udev rules), sarà esposto come unità dispositivo in systemd. Le proprietà impostate con udev possono essere usate come configurazione per impostare le dipendenze per le ''device units''. | # <code>device</code>: questa unità incapsula un dispositivo nell'albero dei dispositivi Linux. Se uno di loro viene contrassegnato attraverso una regola ''udev'' (udev rules), sarà esposto come unità dispositivo in systemd. Le proprietà impostate con udev possono essere usate come configurazione per impostare le dipendenze per le ''device units''. | ||
# <code>mount</code>: questa unità incapsula un punto di montaggio (mount point) nel filesystem. | # <code>mount</code>: questa unità incapsula un punto di montaggio (mount point) nel filesystem. | ||
Line 72: | Line 70: | ||
* <code>systemctl</code>: usato per esaminare e controllare lo stato di systemd e del service manager | * <code>systemctl</code>: usato per esaminare e controllare lo stato di systemd e del service manager | ||
* <code>systemd-cgls</code>: ricorsivamente mostra il contenuto della gerarchia del '' | * <code>systemd-cgls</code>: ricorsivamente mostra il contenuto della gerarchia del ''control group'' selezionato nell'albero | ||
* <code>systemadm</code>: una interfaccia grafica per systemd e per il service manager. Fa parte del pacchetto systemd-gtk. Si tratta di una versione giovane ancora in lavorazione. Non usarla se non si è sviluppatori. | * <code>systemadm</code>: una interfaccia grafica per systemd e per il service manager. Fa parte del pacchetto systemd-gtk. Si tratta di una versione giovane ancora in lavorazione. Non usarla se non si è sviluppatori. | ||
Line 97: | Line 95: | ||
== Quale strumento gestisce systemd ? == | == Quale strumento gestisce systemd ? == | ||
systemctl è lo strumento principale da usare. Combina le fuzionalità dei servizi e di chkconfig per abilitarli/ | systemctl è lo strumento principale da usare. Combina le fuzionalità dei servizi e di chkconfig per abilitarli/disabilitarli permanentemente o solo per la connessione corrente. | ||
<pre> systemctl </pre> | <pre> systemctl </pre> | ||
Line 133: | Line 131: | ||
<pre> systemctl is-enabled foo.service; echo $? </pre> | <pre> systemctl is-enabled foo.service; echo $? </pre> | ||
0 indica che è abilitato. 1 indica che è disabilitato | 0 indica che è abilitato. 1 indica che è disabilitato. In Fedora 17, in aggiunta al codice di ritorno, "enabled" o "disabled" saranno stampati in output. | ||
Far riferimento a ''man systemctl'' per maggiori dettagli. | Far riferimento a ''man systemctl'' per maggiori dettagli. | ||
Line 139: | Line 137: | ||
== Come si cambiano i run-level ? == | == Come si cambiano i run-level ? == | ||
systemd ha il concetto di target che è un rimpiazzo più flessibile | systemd ha il concetto di target che è un rimpiazzo più flessibile rispetto ai runlevel in sysvinit. | ||
Run-level3 è emulato dal multi-user.target. Run-level5 è emulato dal graphical.target. runlevel3.target è un link simbolico al multi-user.target e runlevel5.target è un link simbolico al graphical.target. | Run-level3 è emulato dal multi-user.target. Run-level5 è emulato dal graphical.target. runlevel3.target è un link simbolico al multi-user.target e runlevel5.target è un link simbolico al graphical.target. | ||
Line 151: | Line 149: | ||
<pre> systemctl isolate graphical.target (oppure) systemctl isolate runlevel5.target </pre> | <pre> systemctl isolate graphical.target (oppure) systemctl isolate runlevel5.target </pre> | ||
== | == Come si cambia il run-level predefinto ? == | ||
systemd | systemd usa i symlink per puntare al runlevel predefinito. Bisogna cancellare il collegamento simbolico esistente prima di crearne uno nuovo | ||
<pre> rm /etc/systemd/system/default.target </pre> | <pre> rm /etc/systemd/system/default.target </pre> | ||
Cambio al runlevel 3 come predefinito | |||
<pre> ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target </pre> | <pre> ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target </pre> | ||
Cambio al runlevel 5 come predefinito | |||
<pre> ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target </pre> | <pre> ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target </pre> | ||
systemd | systemd non usa il file /etc/inittab. | ||
== | == Come si controlla il run-level corrente ? == | ||
runlevel | Il comando runlevel funziona ancora con systemd. E' possibile continuare ad usarlo comunque, emulandolo attraverso i 'targets' anche contemporaneamente. | ||
<pre> systemctl list-units --type=target </pre> | <pre> systemctl list-units --type=target </pre> | ||
== | == Come spegnere la macchina ? == | ||
E' possibile usare | |||
<pre> | <pre> | ||
poweroff | poweroff | ||
</pre> | </pre> | ||
Altre possibilità sono: <code>halt -p</code>, <code>init 0</code>, <code>shutdown -P now</code> | |||
Da notare che <code>halt</code> è usato per far funzionare lo stesso <code>poweroff</code> nelle versioni precedenti di Fedora, ma systemd li distingue, così <code>halt</code> senza parametri ora fa esattamente quello che dice - semplicemente ferma il sistema senza spegnere. | |||
== | == Il comando service funziona con systemd ? == | ||
Sì. E' stato modificato per richiamare systemctl automaticamente quando tratta i file systemd service. Così entrambi questi comandi fanno la stessa cosa | |||
<pre> service NetworkManager stop </pre> | <pre> service NetworkManager stop </pre> | ||
( | (oppure) | ||
<pre> systemctl stop NetworkManager.service </pre> | <pre> systemctl stop NetworkManager.service </pre> | ||
== | == Il comando chkconfig funziona con systemd ? == | ||
Sì, per attivare/spegnere i servizi, c'é compatibilità per entrambi i metodi. chkconfig è stato modificato per richiamare systemctl quando si tratta di file systemd service. Inoltre systemctl richiama automaticamente chkconfig quando tratta i tradizionali file sysv init. | |||
Così i seguenti comandi fanno la stessa cosa | |||
<pre> chkconfig NetworkManager off </pre> | <pre> chkconfig NetworkManager off </pre> | ||
( | (oppure) | ||
<pre> systemctl disable NetworkManager.service </pre> | <pre> systemctl disable NetworkManager.service </pre> | ||
chkconfig --list | chkconfig --list non lista i servizi systemd, ma solo quelli Sys V. Il suo output fornisce ulteriori informazioni. | ||
== | == system-config-services funziona con systemd? == | ||
La versione di system-config-services a partire da Fedora 15 può funzianare per i file systemd service. Se si hanno problemi, creare un bug report. | |||
== | == Come si cambia il numero di getty predefiniti avviati ? == | ||
Per aggiungere un altro getty: | |||
Posizionare semplicemente un altro symlink per instanziare un getty nella directory getty.target.wants/ : | |||
<pre> | <pre> | ||
Line 224: | Line 223: | ||
</pre> | </pre> | ||
Per rimuovere un getty: | |||
Rimuovere il symlink nella directory getty.target.wants/ : | |||
<pre> | <pre> | ||
Line 234: | Line 233: | ||
</pre> | </pre> | ||
systemd | systemd non usa il file /etc/inittab. | ||
== | == Come impostare un login automatico su un virtual console terminal? == | ||
Prima creare un nuovo servizio simile a getty@.service: | |||
<pre> | <pre> | ||
Line 247: | Line 246: | ||
</pre> | </pre> | ||
editare ExecStart, Restart e Alias values, come questo: | |||
<pre> | <pre> | ||
Line 257: | Line 256: | ||
</pre> | </pre> | ||
riavviare finalmente il demone ed avviare il servizio: | |||
<pre> | <pre> | ||
systemctl daemon-reload | systemctl daemon-reload | ||
Line 263: | Line 263: | ||
</pre> | </pre> | ||
Da notare che se si esce dalla sessione tty8, è possibile usarlo fino al riavvio successivo o fino all'avvìo manuale da systemctl, a meno che non si impone Restart come ‘always’; è raccomandato comunque evitarlo per motivi di sicurezza. | |||
== | == Come personalizzare un file unit o aggiungerne uno ? == | ||
I file ''unit'' in /etc/systemd/system hanno precedenza sugli unit in /lib/systemd/system. Copiarli dal secondo al primo e personalizzarli a piacimento. | |||
Se una linea inizia con <code>.include</code> seguita da un nome di file, lo stesso file verrà analizzato. Assicurarsi che abbia un'appropriata sezione headers prima di qualsiasi direttiva. | |||
Si dovrebbe usare <code>.include</code> invece di copiare l'intero unit file da /lib/systemd/system a /etc/systemd/system se possibile. Tutto ciò consentirà di aggiornare correttamente le direttive invariate durante i futuri aggiornamenti dei pacchetti. | |||
Prestare attenzione quando si usa <code>.include</code> insieme a direttive che possono essere definite più volte (come <code>EnvironmentFile=</code>); poiché si possono solo aggiungerne delle nuove, senza rimuovere quelle già definite. Meglio copiare l'intero file da /lib/systemd/system a /etc/systemd/system in questo caso. | |||
Se volessimo ad esempio usare un server lighttpd e volessimo abbassare il suo valore niceness. Si deve aggiungere <code>Nice=-5</code> al file lighttpd.service. é possibile farlo o copiando l'intero file /lib/systemd/system/lighttpd.service in /etc/systemd/system/lighttpd.service o creando il seguente file in /etc/systemd/system/lighttpd.service: | |||
<pre> | <pre> | ||
Line 283: | Line 283: | ||
</pre> | </pre> | ||
Non dimenticarsi di riavviare il demone utilizzando <code>systemctl daemon-reload</code> dopo la modifica del file. | |||
{{admon/note| | {{admon/note|Quando si modifica un file unit che ha un symlink che punta a questa unit come fa ''display-manager.service -> prefdm.service'', lo stesso symlink dove essere copiato al posto dell'attuale unit come il display-manager.service dev'essere copiato nella directory /etc/systemd/system oppure una nuova unit creata con .includes che porta questo nome.}} | ||
== | == Come gestire il debug di systemd ? == | ||
Far riferimento a [[How_to_debug_Systemd_problems]] | |||
= Readahead = | = Readahead = | ||
systemd | systemd ha una implementazione readahead incorporata non abilitata negli upgrades. Dovrebbe migliorare la velocità di avvio, ma può variare a seconda dell'hardware. Per abilitarla: | ||
<pre> | <pre> | ||
Line 301: | Line 301: | ||
</pre> | </pre> | ||
= Avvertenze sulla partizione separata /usr = | |||
Far riferimento a http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README per i dettagli. | |||
= Man | = Pagine Man = | ||
systemd | systemd è dotato di un'ampia documentazione comprese le pagine man. La versione web è | ||
http://0pointer.de/public/systemd-man/ | http://0pointer.de/public/systemd-man/ | ||
= | = Riferimenti = | ||
* http://0pointer.de/blog/projects/ - Lennart | * http://0pointer.de/blog/projects/ - Il blog di Lennart ha un sacco di informazioni su systemd. Lennart è lo sviluppatore principale | ||
* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions | * http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions | ||
* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks | * http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks | ||
* [[Features/systemd | Features Fedora 15:systemd]] | * [[Features/systemd | Features Fedora 15: systemd]] | ||
* [http://www.freedesktop.org/wiki/Software/systemd | * [http://www.freedesktop.org/wiki/Software/systemd Homepage del progetto] | ||
* [http://fosdem.org/2011/interview/lennart-poettering | * [http://fosdem.org/2011/interview/lennart-poettering.html Intervista con lo sviluppatore] | ||
* [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups] | * [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups] | ||
[[Category:Italiano]] | [[Category:Italiano]] | ||
[[Category:Da revisionare]] |
Revision as of 05:58, 22 October 2012
systemd è un sistema ed un manager di servizi per Linux, compatibile con SysV e LSB init scripts. systemd fornisce potenti capacità di parallelizzazionne, usa attivazioni socket e D-Bus per avviare i servizi, offre inizializzazioni di demoni su richiesta, tiene traccia dei processi usando Linux cgroups, supporta lo snapshotting ed il ripristino dello stato del sistema, mantiene il mount e l'automount ed implementa un servizio logico di controllo. Può lavorare come rimpiazzo per sysvinit. Per maggiori informazioni sono disponibili i video http://linuxconfau.blip.tv/file/4696791/ o http://www.youtube.com/watch?v=TyMLi8QF6sw
Cos'é systemd?
http://0pointer.de/blog/projects/why.html
Introduzione
systemd inizializza e supervisiona l'intero sistema ed è basato sul concetto di units composto da nome/tipo stessi del file di configurazione da maneggiare (ad esempio, una unit avahi.service ha un file di configurazione con lo stesso nome ed è una unità incapsulata nel demone Avahi). Ci sono sette differenti tipi di units:
service
: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati.socket
: questa unità contiene un socket nel file-system o su Internet. systemd attualmente supporta i socket AF_INET, AF_INET6, AF_UNIX di tipo stream, datagram e sequential packet. Può inoltre supportare i classici FIFO come transport. Ogni unità socket ha un servizio corrispondente, che viene inizializzato se la prima connessione avviene sul socket o FIFO (ad esempio nscd.socket inizializza nscd.service su una connessione in ingresso).device
: questa unità incapsula un dispositivo nell'albero dei dispositivi Linux. Se uno di loro viene contrassegnato attraverso una regola udev (udev rules), sarà esposto come unità dispositivo in systemd. Le proprietà impostate con udev possono essere usate come configurazione per impostare le dipendenze per le device units.mount
: questa unità incapsula un punto di montaggio (mount point) nel filesystem.automount
: questo tipo di unità incapsula un punto di automontaggio nel filesystem. Ogni unità automount corrisponde ad una unità mount, che viene avviata (montata) non appena la directory automount è accessibile.target
: questo tipo di unità per il logical grouping: invece di fare qualcosa autonomamente, semplicemente fa riferimento ad altre unità che possono essere controllate in gruppo. (ad esempio multi-user.target, che è un target che svolge praticamente il ruolo di run-level 5 nel classico sistema SysV; o bluetooth.target richiesto appena un dispositivo bluetooth è disponibile e che semplicemente avvìa di conseguenza i servizi relativi altrimenti non necessari: bluetoothd e obexd e simili).snapshot
: simile alle unità target, attualmente non fanno nulla se nonché essere un riferimento per altre unità.
Documentazione systemd
systemd dispone di una documentazione completa. Far riferimento a http://0pointer.de/blog/projects/systemd-docs.html
Caratteristiche systemd
systemd fornisce quanto segue:
- aggressive capacità di parallelizzazione usando il socket: Per velocizzare l'intero avvìo e per inizializzare più processi in parallelo, systemd crea la lista dei socket prima di inizializzare il demone, solo dopo passa il socket. Tutti i socket per tutti i demoni sono creati in una sola volta nel sistema init, successivamente vengono avviati. Se un servizio necessita di un altro servizio che non è pienamente inizializzato, allora rimarrà in coda bloccando il client in quella singola richiesta. Ma solo quel client e solo su quella richiesta. Inoltre, dipendenze tra servizi non dovranno più essere configurate per permettere la parallelizzazione: avviando tutti i socket contemporaneamente, il servizio dipendente da un altro sicuramente sarà connesso ai suoi socket.
- attivazione di D-Bus per avviare i servizi: usando l'attivazione bus, un servizio può essere avviato la prima volta all'accesso. La Bus activation inoltre assicura la sincronizzazione minima necessaria per avviare i provider ed i consumer dei servizi D-Bus: avviando nello stesso momento due servizi, se uno è più veloce dell'altro allora D-Bus ne accoda la richiesta.
- offre l'avvìo on-demand dei demoni
- mantiene traccia dei processi usando i cgroups Linux: Ogni processo eseguito ha il proprio cgroup che è molto facile da configurare anche dalle utilities libcgroups ad esempio.
- supporta lo snapshotting e il ripristino dello stato del sistema: Gli Snapshots possono essere usati per salvare/ripristinare lo stato di tutti i servizi e delle unità di init. Principalmente ci sono due casi tipici: permettere all'utente di usare temporaneamente uno specifico stato come l' "Emergency Shell", terminando i servizi correnti e fornisce una facile via per tornare allo stato precedente con tutti i servizi previsti, fermando tutti quelli avviati temporaneamente.
- mantiene i punti di montaggio e di automontaggio: Systemd monitora tutti i punti di montaggio e può essere usato per modificarli. /etc/fstab può essere usato come configurazione addizionale. Usando l'opzione
comment=
di fstab, è possibile persino marcare le voci in/etc/fstab
per lasciare a systemd il controllo dei punti di montaggio..
- implementa una logica di controllo del servizio basata sulle dipendenze: Systemd supporta diversi tipi di dipendenze tra servizi (o unità), usando le opzioni After/Before, Requires e Wants nei file di configurazione per fissare l'ordine d'attivazione delle unità. Requires e Wants esprimono una richiesta di dipendenza positiva, sia obbligatoria che facoltativa. C'é Conflicts che esprime una richiesta di dipendenza negativa ed altre meno usate. Come controllo transazionale, se una unità è richiesta per avviare o terminare, systemd la aggiungerà insieme a tutte le sue dipendenze ad una transazione temporanea, verificandone la consistenza (o l'ordine attraverso After/Before di tutte le unità cycle-free). Se non lo è, systemd proverà a sistemarla ed a rimuovere le operazioni non essenziali dalla transizione che potrebbero rimuovere il loop.
e:
- Per ogni processo generato, systemd controlla: L'ambiente, i limiti delle risorse, directory working e root, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, group id supplementari, directory leggibili/scrivibili/inaccessibili, mount flags condivise/private/secondarie, capabilities/bounding set, secure bits, CPU scheduler reset of fork, /tmp name-space privati, controllo cgroup per vari sottosistemi. Inoltre, è possibile connettere facilmente
stdin/stdout/stderr
dei servizi asyslog
,/dev/kmsg
, arbitrary TTYs. Se connesso ad un TTY per input, systemd farà in modo che un processo ottenga un accesso esclusivo, opzionalmente attendendo o forzando.
- I file di configurazione nativi usano la sintassi dei ben conosciuti file
.desktop
: E' una sintassi semplice per la quale il parser esiste già in molti software frameworks. Inoltre, questo permette di fare affidamento su strumenti già esistenti per i18n per la descrizione dei servizi e simili, senza la necessità per gli amministratori di imparare una nuova sintassi.
(... e più avanzate)
- Compatibilità con SysV init scripts: Si avvantaggia di LSB e degli headers Red Hat chkconfig se disponibili; altrimenti usa le informazioni disponibili, come le priorità di avv'o in /etc/rc.d. Questi script init vengono semplicemente considerati una fonte di configurazione differente, facilitano il percorso d'aggiornamento ai servizi systemd.
- file di configurazione /etc/fstab: solo un'altra fonte di configurazione. Usando l'opzione comment= di fstab, è possibile marcare le voci in /etc/fstab per far controllare a systemd i punti di automontaggio.
- Supporta un semplice meccanismo di templating/instance: Per esempio, invece di avviare sei file di configurazione per sei gettys, si ha solo un file getty@.service che crea un'instanza a getty@tty2.service e simili. L'interfaccia può essere ereditata dalle dipendenze, ad esempio è facile codificare che un servizio dhcpcd@eth0.service tira dentro avahi-autoipd@eth0.service, mentre lascia la stringa eth0 segnata (wild-carded).
- Compatibilità, in una certa misura, con
/dev/initctl
. Questa compatibilità è infatti implementata con il servizio FIFO-activated, che semplicemente traduce queste richieste ereditate in richieste D-Bus. Effettivamente significa che i vecchi shutdown, poweroff e comandi simili da Upstart e sysvinit continuano a funzionare con systemd.
- Compatibilità con
utmp
ewtmp
.
Per maggiori dettagli c'é questa lista sul blog dello sviluppatore.
Strumenti
systemctl
: usato per esaminare e controllare lo stato di systemd e del service managersystemd-cgls
: ricorsivamente mostra il contenuto della gerarchia del control group selezionato nell'alberosystemadm
: una interfaccia grafica per systemd e per il service manager. Fa parte del pacchetto systemd-gtk. Si tratta di una versione giovane ancora in lavorazione. Non usarla se non si è sviluppatori.
Leggere le pagine man per maggiori dettagli.
Boot Kernel Command Line
All'avvìo systemd attiva (come predefinito), l'unità target default.target il cui compito è quello di attivare i servizi ed altre unità a seconda delle dipendenze richieste.
Per gestire l'unità da attivare, systemd analizza gli argomenti della propria linea di comando kernel attraverso l'opzione systemd.unit=
. Quest'ultima può essere usata per avvii temporanei differenti. I classici run-level sono rimpiazzati come di seguito:
systemd.unit=rescue.target
è uno speciale target per impostare un sistema base e la rescue shell (similli al run-level 1); systemd.unit=emergency.target
è molto simile al init=/bin/sh
ma con l'opzione d'avvìo per l'intero sistema; systemd.unit=multi-user.target
per impostare un sistema multi utente non grafico; systemd.unit=graphical.target
per impostare il login grafico.
Dettagli a riguardo si trovano alla pagina man systemd.special
.
Qual'é lo stato di systemd in Fedora?
In Fedora 14 si trattava di un'anteprima. In Fedora 15 è diventata una caratteristica predefinita al posto di Upstart.
Tutti i file System V init sono stati convertiti in servizi systemd o equivalenti ?
Molti dei sevizi principali (/lib/systemd/system li ha e ne può essere controllato lo stato su http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) sono stati convertiti. La transizione è pianificata per Fedora 16. Per i dettagli: http://fedoraproject.org/wiki/Features/SysVtoSystemd. systemd è pienamente compatibile con i vecchi init script.
Quale strumento gestisce systemd ?
systemctl è lo strumento principale da usare. Combina le fuzionalità dei servizi e di chkconfig per abilitarli/disabilitarli permanentemente o solo per la connessione corrente.
systemctl
Far riferimento a man systemctl per maggiori dettagli. systemd-cgls lista i processi avviati con un formato ad albero. Può mostrare ricorsivamente il contenuto di ogni control group. Far riferimento a man systemd-cgls per maggiori dettagli.
Come avviare/fermare o abilitare/disabilitare i servizi ?
Attiva un servizio immediatamente:
systemctl start foo.service
Disattiva un servizio immediatamente:
systemctl stop foo.service
Riavvia un servizio:
systemctl restart foo.service
Mostra lo stato di un servizio o se è avviato o meno:
systemctl status foo.service
Abilita un servizio per essere inizializzato all'avvìo:
systemctl enable foo.service
Disabilita un servizio per non essere inizializzato all'avvìo:
systemctl disable foo.service
Controlla se un servizio è già abilitato o meno:
systemctl is-enabled foo.service; echo $?
0 indica che è abilitato. 1 indica che è disabilitato. In Fedora 17, in aggiunta al codice di ritorno, "enabled" o "disabled" saranno stampati in output.
Far riferimento a man systemctl per maggiori dettagli.
Come si cambiano i run-level ?
systemd ha il concetto di target che è un rimpiazzo più flessibile rispetto ai runlevel in sysvinit.
Run-level3 è emulato dal multi-user.target. Run-level5 è emulato dal graphical.target. runlevel3.target è un link simbolico al multi-user.target e runlevel5.target è un link simbolico al graphical.target.
Si cambia al 'runlevel 3' con
systemctl isolate multi-user.target (oppure) systemctl isolate runlevel3.target
Si cambia al 'runlevel 5' con
systemctl isolate graphical.target (oppure) systemctl isolate runlevel5.target
Come si cambia il run-level predefinto ?
systemd usa i symlink per puntare al runlevel predefinito. Bisogna cancellare il collegamento simbolico esistente prima di crearne uno nuovo
rm /etc/systemd/system/default.target
Cambio al runlevel 3 come predefinito
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Cambio al runlevel 5 come predefinito
ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
systemd non usa il file /etc/inittab.
Come si controlla il run-level corrente ?
Il comando runlevel funziona ancora con systemd. E' possibile continuare ad usarlo comunque, emulandolo attraverso i 'targets' anche contemporaneamente.
systemctl list-units --type=target
Come spegnere la macchina ?
E' possibile usare
poweroff
Altre possibilità sono: halt -p
, init 0
, shutdown -P now
Da notare che halt
è usato per far funzionare lo stesso poweroff
nelle versioni precedenti di Fedora, ma systemd li distingue, così halt
senza parametri ora fa esattamente quello che dice - semplicemente ferma il sistema senza spegnere.
Il comando service funziona con systemd ?
Sì. E' stato modificato per richiamare systemctl automaticamente quando tratta i file systemd service. Così entrambi questi comandi fanno la stessa cosa
service NetworkManager stop
(oppure)
systemctl stop NetworkManager.service
Il comando chkconfig funziona con systemd ?
Sì, per attivare/spegnere i servizi, c'é compatibilità per entrambi i metodi. chkconfig è stato modificato per richiamare systemctl quando si tratta di file systemd service. Inoltre systemctl richiama automaticamente chkconfig quando tratta i tradizionali file sysv init.
Così i seguenti comandi fanno la stessa cosa
chkconfig NetworkManager off
(oppure)
systemctl disable NetworkManager.service
chkconfig --list non lista i servizi systemd, ma solo quelli Sys V. Il suo output fornisce ulteriori informazioni.
system-config-services funziona con systemd?
La versione di system-config-services a partire da Fedora 15 può funzianare per i file systemd service. Se si hanno problemi, creare un bug report.
Come si cambia il numero di getty predefiniti avviati ?
Per aggiungere un altro getty:
Posizionare semplicemente un altro symlink per instanziare un getty nella directory getty.target.wants/ :
ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service systemctl daemon-reload systemctl start getty@tty9.service
Per rimuovere un getty:
Rimuovere il symlink nella directory getty.target.wants/ :
rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service systemctl daemon-reload systemctl stop getty@tty5.service getty@tty6.service
systemd non usa il file /etc/inittab.
Come impostare un login automatico su un virtual console terminal?
Prima creare un nuovo servizio simile a getty@.service:
# cp /lib/systemd/system/getty@.service \ /etc/systemd/system/autologin@.service # ln -s /etc/systemd/system/autologin@.service \ /etc/systemd/system/getty.target.wants/getty@tty8.service
editare ExecStart, Restart e Alias values, come questo:
... ExecStart=-/sbin/mingetty --autologin USERNAME %I Restart=no ... Alias=getty.target.wants/getty@tty8.service
riavviare finalmente il demone ed avviare il servizio:
systemctl daemon-reload systemctl start getty@tty8.service
Da notare che se si esce dalla sessione tty8, è possibile usarlo fino al riavvio successivo o fino all'avvìo manuale da systemctl, a meno che non si impone Restart come ‘always’; è raccomandato comunque evitarlo per motivi di sicurezza.
Come personalizzare un file unit o aggiungerne uno ?
I file unit in /etc/systemd/system hanno precedenza sugli unit in /lib/systemd/system. Copiarli dal secondo al primo e personalizzarli a piacimento.
Se una linea inizia con .include
seguita da un nome di file, lo stesso file verrà analizzato. Assicurarsi che abbia un'appropriata sezione headers prima di qualsiasi direttiva.
Si dovrebbe usare .include
invece di copiare l'intero unit file da /lib/systemd/system a /etc/systemd/system se possibile. Tutto ciò consentirà di aggiornare correttamente le direttive invariate durante i futuri aggiornamenti dei pacchetti.
Prestare attenzione quando si usa .include
insieme a direttive che possono essere definite più volte (come EnvironmentFile=
); poiché si possono solo aggiungerne delle nuove, senza rimuovere quelle già definite. Meglio copiare l'intero file da /lib/systemd/system a /etc/systemd/system in questo caso.
Se volessimo ad esempio usare un server lighttpd e volessimo abbassare il suo valore niceness. Si deve aggiungere Nice=-5
al file lighttpd.service. é possibile farlo o copiando l'intero file /lib/systemd/system/lighttpd.service in /etc/systemd/system/lighttpd.service o creando il seguente file in /etc/systemd/system/lighttpd.service:
.include /lib/systemd/system/lighttpd.service [Service] Nice=-5
Non dimenticarsi di riavviare il demone utilizzando systemctl daemon-reload
dopo la modifica del file.
Come gestire il debug di systemd ?
Far riferimento a How_to_debug_Systemd_problems
Readahead
systemd ha una implementazione readahead incorporata non abilitata negli upgrades. Dovrebbe migliorare la velocità di avvio, ma può variare a seconda dell'hardware. Per abilitarla:
systemctl enable systemd-readahead-collect.service systemctl enable systemd-readahead-replay.service
Avvertenze sulla partizione separata /usr
Far riferimento a http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README per i dettagli.
Pagine Man
systemd è dotato di un'ampia documentazione comprese le pagine man. La versione web è
http://0pointer.de/public/systemd-man/
Riferimenti
- http://0pointer.de/blog/projects/ - Il blog di Lennart ha un sacco di informazioni su systemd. Lennart è lo sviluppatore principale
- http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
- http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
- Features Fedora 15: systemd
- Homepage del progetto
- Intervista con lo sviluppatore
- cgroups