From Fedora Project Wiki
No edit summary
 
(59 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{autolang}}
{{autolang}}


{{admon/warning|Traduzione della pagina in corso }}
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 cme rimpiazzo per ''sysvinit''. Per maggiori informazioni sono disponibili i video http://linuxconfau.blip.tv/file/4696791/ o http://www.youtube.com/watch?v=TyMLi8QF6sw


{{admon/note|Per gli amministratori di sistema|  
{{admon/note|Per gli amministratori di sistema|  
Line 13: Line 12:
== Introduzione ==
== Introduzione ==


systemd starts up and supervises the entire system and is based around the notion of ''units'' composed of a name and a type and matching a configuration file with the same name and type (e.g. a unit avahi.service has a configuration file with the same name and is a unit encapsulating the Avahi daemon). There are seven different types of units:
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:


# <code>service</code>: these are the most obvious kind of unit: daemons that can be started, stopped, restarted, reloaded.  
# <code>service</code>: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati.  
# <code>socket</code>: this unit encapsulates a socket in the file-system or on the Internet. systemd currently support AF_INET, AF_INET6, AF_UNIX sockets of the types stream, datagram, and sequential packet. It can also support classic FIFOs as transport. Each socket unit has a matching service unit, that is started if the first connection comes in on the socket or FIFO (e.g. nscd.socket starts nscd.service on an incoming connection).
# <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>: this unit encapsulates a device in the Linux device tree. If a device is marked for this via udev rules, it will be exposed as a device unit in systemd. Properties set with udev can be used as configuration source to set dependencies for 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>: this unit encapsulates a mount point in the file system hierarchy.
# <code>mount</code>: questa unità incapsula un punto di montaggio (mount point) nel filesystem.
# <code>automount</code>: this unit type encapsulates an automount point in the file system hierarchy. Each automount unit has a matching mount unit, which is started (i.e. mounted) as soon as the automount directory is accessed.
# <code>automount</code>: 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.
# <code>target</code>: this unit type is used for logical grouping of units: instead of actually doing anything by itself it simply references other units, which thereby can be controlled together. (e.g. multi-user.target, which is a target that basically plays the role of run-level 5 on classic SysV system; or bluetooth.target which is requested as soon as a bluetooth dongle becomes available and which simply pulls in bluetooth related services that otherwise would not need to be started: bluetoothd and obexd and suchlike).
# <code>target</code>: 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).
# <code>snapshot</code>: similar to target units snapshots do not actually do anything themselves and their only purpose is to reference other units.
# <code>snapshot</code>: simile alle unità target, attualmente non fanno nulla se nonché essere un riferimento per altre unità.


== systemd documentation ==
== Documentazione systemd ==


systemd has very comprehensive documentation. Refer to
systemd dispone di una documentazione completa. Far riferimento a http://0pointer.de/blog/projects/systemd-docs.html


http://0pointer.de/blog/projects/systemd-docs.html
== Caratteristiche systemd ==


'''systemd''' fornisce quanto segue:


== systemd features ==
* 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.


'''systemd''' provides the following:
* 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.


* aggressive parallelization capabilities using socket: To speed up the entire boot and start more processes in parallel, systemd creates the listening sockets before actually starting the daemon, and then just passes the socket to it. All sockets for all daemons are created in one step in the init system, and then in a second step run all daemons at once. If a service needs another, and it is not fully started up, what will happen is that the connection is queued in the providing service and the client will potentially block on that single request. But only that one client will block and only on that one request. Also, dependencies between services no longer have to be configured to allow proper parallelized start-up: starting all sockets at once and a service needing another, it surely can connect to its socket.
* offre l'avvìo on-demand dei demoni 


* D-Bus activation for starting services: Using bus activation, a service can be started the first time it is accessed. Bus activation also gives the minimal per-request synchronisation needed for starting up the providers and the consumers of D-Bus services at the same time: starting a service at the same time as another, if one is quicker, than via the bus activation logic the D-Bus queues the request until the other manages to establish its service name.
* mantiene traccia dei processi usando i [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups] Linux: Ogni processo eseguito ha il proprio cgroup che è molto facile da configurare anche dalle utilities ''libcgroups'' ad esempio.
* offers on-demand starting of daemons


* keeps track of processes using Linux [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Every executed process gets its own cgroup and it is very easy to configure systemd to place services in cgroups that have been configured externally, for example via the libcgroups utilities.
* 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.
 
* supports snapshotting and restoring of the system state: Snapshots can be used to save/rollback the state of all services and units of the init system. Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
    
    
* maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the <code>comment=</code> fstab option you can even mark <code>/etc/fstab</code> entries to become systemd controlled automount points..  
* 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 <code>comment=</code> di fstab, è possibile persino marcare le voci in <code>/etc/fstab</code> per lasciare a systemd il controllo dei punti di montaggio..  
   
   
* implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using ''After''/''Before'', ''Requires'' and ''Wants'' options in the unit configuration files to fix the ordering how units are activated. ''Requires'' and ''Wants'', express a positive requirement dependency, either mandatory, or optional. There is ''Conflicts'' which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.
* 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.


and:
e:


* For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect <code>stdin/stdout/stderr</code> of services to <code>syslog</code>, <code>/dev/kmsg</code>, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
* 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 <code>stdin/stdout/stderr</code> dei servizi a <code>syslog</code>, <code>/dev/kmsg</code>, arbitrary TTYs. Se connesso ad un TTY per input, systemd farà in modo che un processo ottenga  un accesso esclusivo, opzionalmente attendendo o forzando.


* The native configuration files use a syntax that closely follows the well-known <code>.desktop</code> files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
* I file di configurazione nativi usano la sintassi dei ben conosciuti file <code>.desktop</code>: 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.


{{admon/note|systemadm |
{{admon/note|systemadm |
There's a minimal UI, <code>systemadm</code> that allows to start/stop/introspect services. It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala. Do not use it for now unless you are a developer}}
C'é un UI minimale, <code>systemadm</code>, che permette di avviare/fermare/esaminare i servizi. E' parte del pacchetto systemd-gtk. E' ancora in lavorazione e non è funzionale, ma utile come strumento di debugging. E' scritto in Vala. Non usarlo per adesso se non si è sviluppatori}}


(... and more advanced)
(... e più avanzate)


* Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.  
* 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.  


* /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
* 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.


* Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
* 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).


* Compatibility, to a certain extent, with <code>/dev/initctl</code>. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
* Compatibilità, in una certa misura, con <code>/dev/initctl</code>. 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.


* Compatibility with <code>utmp</code> and <code>wtmp</code> (To an extent that is far more than healthy, given how crufty <code>utmp</code> and <code>wtmp</code> today are).
* Compatibilità con <code>utmp</code> e <code>wtmp</code>.


For all details view [http://0pointer.de/blog/projects/systemd.html A short list of other features] on the developer blog.
Per maggiori dettagli c'é [http://0pointer.de/blog/projects/systemd.html questa lista] sul blog dello sviluppatore.


== Tools ==  
== Strumenti ==  


* <code>systemctl</code>: used to introspect and control the state of the systemd system and service manager
* <code>systemctl</code>: usato per esaminare e controllare lo stato di systemd e del service manager
* <code>systemd-cgls</code>: recursively shows the contents of the selected Linux control group hierarchy in a tree
* <code>systemd-cgls</code>: ricorsivamente mostra il contenuto della gerarchia del ''control group'' selezionato nell'albero
* <code>systemadm</code>: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd. Part of the systemd-gtk page. This is a early version and needs more work. Do not use it for now unless you are a developer.   
* <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.   


View the man pages for more details.
Leggere le pagine man per maggiori dettagli.


== Boot Kernel Command Line ==
== Boot Kernel Command Line ==


On boot '''systemd''' activates (by default), the target unit ''default.target'' whose job is to activate services and other units by pulling them in via dependencies.
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.  
 
To override the unit to activate, '''systemd''' parses its own kernel command line arguments via the <code>systemd.unit=</code> command line option. This may be used to temporarily boot into a different boot unit. The classical run-levels are replaced as following:


<code>systemd.unit=rescue.target</code> is a special target unit for setting up the base system and a rescue shell (similar to run level 1); <code>systemd.unit=emergency.target</code>, is very similar to passing <code>init=/bin/sh</code> but with the option to boot the full system from there; <code>systemd.unit=multi-user.target</code> for setting up a non-graphical multi-user system; <code>systemd.unit=graphical.target</code> for setting up a graphical login screen.
Per gestire l'unità da attivare, '''systemd''' analizza gli argomenti della propria linea di comando kernel attraverso l'opzione <code>systemd.unit=</code>. Quest'ultima può essere usata per avvii temporanei differenti. I classici run-level sono rimpiazzati come di seguito:


For details about these special systemd boot units, view the man <code>systemd.special</code> page.
<code>systemd.unit=rescue.target</code> è uno speciale target per impostare un sistema base e la rescue shell (similli al run-level 1); <code>systemd.unit=emergency.target</code> è molto simile al <code>init=/bin/sh</code> ma con l'opzione d'avvìo per l'intero sistema; <code>systemd.unit=multi-user.target</code> per impostare un sistema multi utente non grafico; <code>systemd.unit=graphical.target</code> per impostare il login grafico.


== What is the status of systemd in Fedora? ==
Dettagli a riguardo si trovano alla pagina man <code>systemd.special</code>.


Fedora 14 featured it is a technology preview.  It is the default in Fedora 15 and has replaced Upstart. 
== Qual'é lo stato di systemd in Fedora? ==


== Has all legacy System V init files been converted to systemd service files or equivalent? ==
In Fedora 14 si trattava di un'anteprima. In Fedora 15 è diventata una caratteristica predefinita al posto di Upstart.


Many of the core services (/lib/systemd/system has them and you can check status at http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) have been converted but not all of them yet.  The transition is planned for Fedora 16.  Details at http://fedoraproject.org/wiki/Features/SysVtoSystemd.  systemd is fully compatible with the legacy init scripts
== Tutti i file System V init sono stati convertiti in servizi systemd o equivalenti ? ==


== What is the tool to manage services with systemd? ==
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.


systemctl is the primary tool to use.  It combines the functionality of both service and chkconfig into a single tool that you can use for instance to enable/disable services permanently or only for the current session. 
== Quale strumento gestisce systemd ? ==


list all running services etc:
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>   


Refer to man systemctl for more details. systemd-cgls lists the running process in a tree format. It can recursively show the content of any given control group. Refer to man systemd-cgls for more details.  
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.


== How do I start/stop or enable/disable services?  ==
== Come avviare/fermare o abilitare/disabilitare i servizi ?  ==


Activates a service immediately:
Attiva un servizio immediatamente:


<pre>  systemctl start foo.service </pre>     
<pre>  systemctl start foo.service </pre>     


Deactivates a service immediately:  
Disattiva un servizio immediatamente:  


<pre>  systemctl stop foo.service </pre>   
<pre>  systemctl stop foo.service </pre>   


Restarts a service:
Riavvia un servizio:


<pre> systemctl restart foo.service </pre>  
<pre> systemctl restart foo.service </pre>  


Shows status of a service including whether it is running or not:
Mostra lo stato di un servizio o se è avviato o meno:


<pre> systemctl status foo.service </pre>   
<pre> systemctl status foo.service </pre>   


Enables a service to be started on bootup:
Abilita un servizio per essere inizializzato all'avvìo:


<pre> systemctl enable foo.service </pre>  
<pre> systemctl enable foo.service </pre>  


Disables a service to not start during bootup:
Disabilita un servizio per non essere inizializzato all'avvìo:


<pre> systemctl disable foo.service </pre>  
<pre> systemctl disable foo.service </pre>  


Check whether a service is already enabled or not:
Controlla se un servizio è già abilitato o meno:


<pre> systemctl is-enabled foo.service; echo $? </pre>
<pre> systemctl is-enabled foo.service; echo $? </pre>


0 indicates that it is enabled.  1 indicates that it is disabled
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.   


Refer to man systemctl for more details.
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.  


== How do I change the runlevel? ==
Si cambia al 'runlevel 3' con 


systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.
<pre> systemctl isolate multi-user.target (oppure) systemctl isolate runlevel3.target </pre>


Run level 3 is emulated by multi-user.target. Run level 5 is emulated by graphical.target.  runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target.
Si cambia al 'runlevel 5' con


You can switch to 'runlevel 3' by running
<pre> systemctl isolate graphical.target (oppure) systemctl isolate runlevel5.target </pre>


<pre> systemctl isolate multi-user.target (or) systemctl isolate runlevel3.target </pre>
== Come si cambia il run-level predefinto ? ==


You can switch to 'runlevel 5' by running
I symlink possono essere ancora usati anche se ormai resi obsoleti, data l'introduzione di un comando integrato per impostare il target predefinito.


<pre> systemctl isolate graphical.target (or) systemctl isolate runlevel5.target </pre>
<pre> systemctl enable graphical.target --force</pre>


== How do I change the default runlevel? ==
Symlink: 


systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first before creating a new one
systemd può anche usare 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>


Switch to runlevel 3 by default
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>


Switch to runlevel 5 by default
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 does not use /etc/inittab file.
systemd non usa il file /etc/inittab.


== How do I know the current run level? ==
== Come si controlla il run-level corrente ? ==


runlevel command still works with systemd. You can continue using that however runlevels is a legacy concept in systemd and is emulated via 'targets' and multiple targets can be active at the same time. So the equivalent in systemd terms is
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>


== How to power off the machine ? ==
== Come spegnere la macchina ? ==
You can use
 
E' possibile usare
 
<pre>
<pre>
poweroff
poweroff
</pre>
</pre>


Some more possibilities are: <code>halt -p</code>, <code>init 0</code>, <code>shutdown -P now</code>
Altre possibilità sono: <code>halt -p</code>, <code>init 0</code>, <code>shutdown -P now</code>


Note that <code>halt</code> used to work the same as <code>poweroff</code> in previous Fedora releases, but systemd distinguishes between the two, so <code>halt</code> without parameters now does exactly what it says - it merely stops the system without turning it off.
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.


== Does service command work with systemd? ==
== Il comando service funziona con systemd ? ==


Yes. It has been modified to call systemctl automatically when dealing with systemd service files. So either of the following commands does the same thing
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>


(or)
(oppure)


<pre> systemctl stop NetworkManager.service </pre>
<pre> systemctl stop NetworkManager.service </pre>


== Does chkconfig command work with systemd? ==
== Il comando chkconfig funziona con systemd ? ==


Yes, for turning on/off services, compatibility has been provided both ways. chkconfig has been modified to call systemctl when dealing with systemd service files. Also systemctl automatically calls chkconfig when dealing with a traditional sysv init file.   
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.   


So either of the following commands does the same thing
Così i seguenti comandi fanno la stessa cosa


<pre> chkconfig NetworkManager off </pre>
<pre> chkconfig NetworkManager off </pre>


(or)
(oppure)


<pre> systemctl disable NetworkManager.service </pre>
<pre> systemctl disable NetworkManager.service </pre>


chkconfig --list doesn't list systemd services, only Sys V services. The output of chkconfig takes note of this, along with supplying
chkconfig --list non lista i servizi systemd, ma solo quelli Sys V. Il suo output fornisce ulteriori informazioni.
additional information.


== Does system-config-services work with systemd? ==
== system-config-services funziona con systemd? ==


The Fedora 15 version of system-config-services can cope with systemd service files. If you have problems, file a bug report.  
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.


== How do I change the number of gettys running by default? ==
== Come si cambia il numero di getty predefiniti avviati ? ==


To add another getty:
Per aggiungere un altro getty:


Simply place another symlink for instantiating another getty in the getty.target.wants/ directory:
Posizionare semplicemente un altro symlink per instanziare un getty nella directory getty.target.wants/ :


<pre>
<pre>
Line 228: Line 229:
</pre>
</pre>


To remove a getty:
Per rimuovere un getty:


Simply remove the getty symlinks you want to get rid of in the getty.target.wants/ directory:
Rimuovere il symlink nella directory getty.target.wants/ :


<pre>
<pre>
Line 238: Line 239:
</pre>
</pre>


systemd does not use /etc/inittab file.
systemd non usa il file /etc/inittab.


== How do I set automatic login on a virtual console terminal? ==
== Come impostare un login automatico su un virtual console terminal? ==


First create a new service similar to getty@.service:
Prima creare un nuovo servizio simile a getty@.service:


<pre>
<pre>
Line 251: Line 252:
</pre>
</pre>


then edit ExecStart, Restart and Alias values, like this:
editare ExecStart, Restart e Alias values, come questo:


<pre>
<pre>
Line 261: Line 262:
</pre>
</pre>


and finally reload daemon and start the service:
riavviare finalmente il demone ed avviare il servizio:
 
<pre>
<pre>
systemctl daemon-reload
systemctl daemon-reload
Line 267: Line 269:
</pre>
</pre>


Note that if you exit tty8 session, you wont be able to use it until next reboot or manual start by systemctl, except if you leave Restart as ‘always’, but I highly recommend to avoid this according to security reasons.
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.


== How do I customize a unit file/ add a custom unit file? ==
== Come personalizzare un file unit o aggiungerne uno ? ==


The unit files in /etc/systemd/system have a higher precedence over unit files in /lib/systemd/system. Copy them from the latter to the former and customize it as per your requirements.   
I file ''unit'' in /etc/systemd/system hanno precedenza sugli unit in /lib/systemd/system. Copiarli dal secondo al primo e personalizzarli a piacimento.   


If a line starts with <code>.include</code> followed by a file name, the specified file will be parsed at this point. Make sure that the file that is included has the appropiate section headers before any directives.
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.


You should use <code>.include</code> statement instead of copying the whole unit file from /lib/systemd/system to /etc/systemd/system if possible. This will enable to update the unchanged directives correctly during future package updates.  
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.


Be careful when using <code>.include</code> together with directives that can be defined multiple times (like <code>EnvironmentFile=</code>), since we can only add new directives, but we can't remove already defined ones. We have to copy the whole file from /lib/systemd/system to /etc/systemd/system in this case.
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.


Let's say we use a lighttpd server and we want to lower its niceness value. All we need to do is to add <code>Nice=-5</code> to the lighttpd.service file. We can do this by either copying the whole file from /lib/systemd/system/lighttpd.service to /etc/systemd/system/lighttpd.service or creating the following file in /etc/systemd/system/lighttpd.service:
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 287: Line 289:
</pre>
</pre>


Don't forget to reload systemd daemon using <code>systemctl daemon-reload</code> after editing a unit file.
Non dimenticarsi di riavviare il demone utilizzando <code>systemctl daemon-reload</code> dopo la modifica del file.




{{admon/note|When modifying an unit that has an symlink pointing to that unit for example like the display-manager.service -> prefdm.service does, the symlink should be copied instead of the actual unit as in display-manager.service should be copied to the /etc/systemd/system directory or a new unit created with .includes that bears that name .}}
{{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.}}


== How do I debug systemd issues? ==
== Come gestire il debug di systemd ? ==


Refer to [[How_to_debug_Systemd_problems]]
Far riferimento a [[How_to_debug_Systemd_problems]]


= Readahead =
= Readahead =


systemd has a built-in readahead implementation is not enabled on upgrades. It should improve bootup speed but your mileage may vary depending on your hardware. To enable it:
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 305: Line 307:
</pre>
</pre>


= Avvertenze sulla partizione separata /usr =


= Warnings on separate /usr partition =
Far riferimento a http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README per i dettagli.
 
Refer to http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README for details.  


= Man pages =
= Pagine Man =


systemd comes with extensive documentation including several man pages. The web version is at
systemd è dotato di un'ampia documentazione comprese le pagine man. La versione web è http://www.freedesktop.org/software/systemd/man/


http://0pointer.de/public/systemd-man/
= Riferimenti =


= References =
* http://0pointer.de/blog/projects/  -  Il blog di Lennart ha un sacco di informazioni su systemd. Lennart è lo sviluppatore principale
 
* http://0pointer.de/blog/projects/  -  Lennart's blog has lots of information about systemd. Lennart is the primary systemd developer
* 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 Project homepage]  
* [http://www.freedesktop.org/wiki/Software/systemd Homepage del progetto]  
* [http://fosdem.org/2011/interview/lennart-poettering Interview with the developer]
* [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:Da revisionare]]

Latest revision as of 10:11, 6 October 2013

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

Per gli amministratori di sistema
Gli amministratori di sistema possono visitare questa pagina per sapere come usare systemctl che sostituisce il vecchio flusso di lavoro in SysVinit. Da notare che i comandi service e chkconfig continueranno a funzionare come previsto anche in systemd.

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:

  1. service: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati.
  2. 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).
  3. 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.
  4. mount: questa unità incapsula un punto di montaggio (mount point) nel filesystem.
  5. 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.
  6. 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).
  7. 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 a syslog, /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.
systemadm
C'é un UI minimale, systemadm, che permette di avviare/fermare/esaminare i servizi. E' parte del pacchetto systemd-gtk. E' ancora in lavorazione e non è funzionale, ma utile come strumento di debugging. E' scritto in Vala. Non usarlo per adesso se non si è sviluppatori

(... 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 e wtmp.

Per maggiori dettagli c'é questa lista sul blog dello sviluppatore.

Strumenti

  • systemctl: usato per esaminare e controllare lo stato di systemd e del service manager
  • systemd-cgls: ricorsivamente mostra il contenuto della gerarchia del control group selezionato nell'albero
  • systemadm: 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 ?

I symlink possono essere ancora usati anche se ormai resi obsoleti, data l'introduzione di un comando integrato per impostare il target predefinito. 

 systemctl enable graphical.target --force

Symlink:

systemd può anche usare 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.


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

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://www.freedesktop.org/software/systemd/man/

Riferimenti

Retrieved from "https://fedoraproject.org/w/index.php?title=Systemd/it&oldid=355675"