Systemd/it

From FedoraProject

< Systemd(Difference between revisions)
Jump to: navigation, search
(References)
(Caratteristiche systemd)
Line 44: Line 44:
 
* 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..  
 
* 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, opzinalmente 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 |

Revision as of 19:57, 2 April 2012

Warning (medium size).png
La traduzione della pagina è in corso. Contiene informazioni incomplete e non in lingua italiana.

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

Note.png
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.

Contents

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 starts 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, opzinalmente 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.
Note.png
systemadm
There's a minimal UI, systemadm 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

(... and more advanced)

  • 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.
  • /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.
  • 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.
  • Compatibility, to a certain extent, with /dev/initctl. 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.
  • Compatibility with utmp and wtmp (To an extent that is far more than healthy, given how crufty utmp and wtmp today are).

For all details view A short list of other features on the developer blog.

Tools

  • systemctl: used to introspect and control the state of the systemd system and service manager
  • systemd-cgls: recursively shows the contents of the selected Linux control group hierarchy in a tree
  • systemadm: 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.

View the man pages for more details.

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.

To override the unit to activate, systemd parses its own kernel command line arguments via the systemd.unit= command line option. This may be used to temporarily boot into a different boot unit. The classical run-levels are replaced as following:

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1); systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there; systemd.unit=multi-user.target for setting up a non-graphical multi-user system; systemd.unit=graphical.target for setting up a graphical login screen.

For details about these special systemd boot units, view the man systemd.special page.

What is the status of systemd in Fedora?

Fedora 14 featured it is a technology preview. It is the default in Fedora 15 and has replaced Upstart.

Has all legacy System V init files been converted to systemd service files or equivalent?

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

What is the tool to manage services with systemd?

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.

list all running services etc:

 systemctl 

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.

How do I start/stop or enable/disable services?

Activates a service immediately:

  systemctl start foo.service 

Deactivates a service immediately:

  systemctl stop foo.service 

Restarts a service:

 systemctl restart foo.service 

Shows status of a service including whether it is running or not:

 systemctl status foo.service 

Enables a service to be started on bootup:

 systemctl enable foo.service 

Disables a service to not start during bootup:

 systemctl disable foo.service 

Check whether a service is already enabled or not:

 systemctl is-enabled foo.service; echo $? 

0 indicates that it is enabled. 1 indicates that it is disabled

Refer to man systemctl for more details.

How do I change the runlevel?

systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.

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.

You can switch to 'runlevel 3' by running

 systemctl isolate multi-user.target (or) systemctl isolate runlevel3.target 

You can switch to 'runlevel 5' by running

 systemctl isolate graphical.target (or) systemctl isolate runlevel5.target 

How do I change the default runlevel?

systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first before creating a new one

 rm /etc/systemd/system/default.target 

Switch to runlevel 3 by default

 ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target 

Switch to runlevel 5 by default

 ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target 

systemd does not use /etc/inittab file.

How do I know the current run level?

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

 systemctl list-units --type=target 

How to power off the machine ?

You can use

poweroff

Some more possibilities are: halt -p, init 0, shutdown -P now

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

Does service command work with 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

 service NetworkManager stop 

(or)

 systemctl stop NetworkManager.service 

Does chkconfig command work with 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.

So either of the following commands does the same thing

 chkconfig NetworkManager off 

(or)

 systemctl disable NetworkManager.service 

chkconfig --list doesn't list systemd services, only Sys V services. The output of chkconfig takes note of this, along with supplying additional information.

Does system-config-services work with systemd?

The Fedora 15 version of system-config-services can cope with systemd service files. If you have problems, file a bug report.

How do I change the number of gettys running by default?

To add another getty:

Simply place another symlink for instantiating another getty in the getty.target.wants/ directory:

ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
systemctl daemon-reload
systemctl start getty@tty9.service

To remove a getty:

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

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 does not use /etc/inittab file.

How do I set automatic login on a virtual console terminal?

First create a new service similar to 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

then edit ExecStart, Restart and Alias values, like this:

...
ExecStart=-/sbin/mingetty --autologin USERNAME %I
Restart=no
...
Alias=getty.target.wants/getty@tty8.service

and finally reload daemon and start the service:

systemctl daemon-reload
systemctl start getty@tty8.service

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.

How do I customize a unit file/ add a custom unit file?

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.

If a line starts with .include 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.

You should use .include 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.

Be careful when using .include together with directives that can be defined multiple times (like EnvironmentFile=), 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.

Let's say we use a lighttpd server and we want to lower its niceness value. All we need to do is to add Nice=-5 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:

.include /lib/systemd/system/lighttpd.service 
[Service]
Nice=-5

Don't forget to reload systemd daemon using systemctl daemon-reload after editing a unit file.


Note.png
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 .

How do I debug systemd issues?

Refer to How_to_debug_Systemd_problems

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:

systemctl enable systemd-readahead-collect.service
systemctl enable systemd-readahead-replay.service


Warnings on separate /usr partition

Refer to http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README for details.

Man pages

systemd comes with extensive documentation including several man pages. The web version is at

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

References