Systemd

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Systemd and the translation is 100% complete.

Other languages:
English • ‎español • ‎italiano • ‎日本語 • ‎한국어 • ‎português do Brasil • ‎русский • ‎中文(中国大陆)‎

Warning: Display title "systemd/it" overrides earlier display title "Systemd".

Resources

systemd è un sostituto moderno per init SysV-style e per rc (run command)[1] per sistemi Linux. In Gentoo è supportato come sistema di init alternativo.

Installazione

Note
Quando aggiorni da <=sys-apps/systemd-203 controlla la sezione aggiornamento.

Kernel

systemd fa uso di molte caratteristiche moderne di Linux. Alla data attuale il limite inferiore per la versione del kernel è la ebuild 2.6.39. Nelle versioni recenti di sys-kernel/gentoo-sources c'è un sistema semplice per selezionare le opzioni obbligatorie e facoltative per systemd (vedi Kernel/Configurazione per ulteriori dettagli):

KERNEL Configurazione rapida utilizzando gentoo-sources
Gentoo Linux --->
        Support for init systems, system and service managers --->
                [*] systemd

Per configurare manualmente le opzioni del kernel (che è l'unica soluzione laddove non si utilizzi sys-kernel/gentoo-sources), sono richieste o consigliate le seguenti opzioni di configurazione del kernel:

KERNEL Opzioni obbligatorie
General setup  --->
	[*] open by fhandle syscalls
	[*] Control Group support --->
	[ ] Enable deprecated sysfs features to support old userspace tools
	[*] Configure standard kernel features (expert users)  --->
		[*] Enable eventpoll support
		[*] Enable signalfd() system call
		[*] Enable timerfd() system call
[*] Networking support --->
Device Drivers  --->
	Generic Driver Options  --->
		[*] Maintain a devtmpfs filesystem to mount at /dev
File systems  --->
	[*] Inotify support for userspace
	Pseudo filesystems  --->
		[*] /proc file system support
		[*] sysfs file system support
KERNEL Opzioni consigliate
General setup  --->
        [*] Checkpoint/restore support
	[*] Namespaces support  --->
		[*] Network namespace
[*] Enable the block layer  --->
	[*] Block layer SG support v4
Processor type and features  --->
	[*] Enable seccomp to safely compute untrusted bytecode
Networking support --->
	Networking options --->
		<*> The IPv6 protocol
Device Drivers  --->
	Generic Driver Options  --->
		()  path to uevent helper
		[ ] Fallback user-helper invocation for firmware loading
Firmware Drivers  --->
	[*] Export DMI identification via sysfs to userspace
File systems --->
	<*> Kernel automounter version 4 support (also supports v3)
	Pseudo filesystems --->
		[*] Tmpfs virtual memory file system support (former shm fs)
		[*]   Tmpfs POSIX Access Control Lists
		[*]   Tmpfs extended attributes

In un sistema UEFI si abilitino anche le seguenti:

KERNEL Supporto a UEFI
[*] Enable the block layer  --->
	Partition Types  --->
		[*] Advanced partition selection
		[*]   EFI GUID Partition support
Processor type and features  --->
	[*] EFI runtime service support
Firmware Drivers  --->
        EFI (Extensible Firmware Interface) Support -->
	        <*> EFI Variable Support via sysfs

Se il sistema sta utilizzando lo scheduler BFQ, gli autori di BFQ consigliano di abilitare "BFQ hierarchical scheduling support" sotto "Enable the block layer -> IO Schedulers".

Per una lista aggiornata, vedi la sezione "REQUISITI" nel file del progetto originale README

/etc/mtab

Il progetto supporta solo il file /etc/mtab come link simbolico a /proc/self/mounts. Non creare questo link causerà problemi descritti nei bugreport mount (bug #434090) e df (bug #477240). In passato alcuni programmi scrivevano informazioni (come le opzioni di mount) in /etc/mtab e quindi si presupponeva che fosse un file normale. Oggi si presuppone che tutti i programmi evitino questo problema. Tuttavia, prima di modificare il file per convertirlo in un link simbolico, controlla il bugreport bug #477498 per essere certo che il sistema non sia affetto da alcuna delle regressioni descritte.

Per creare il link simbolico, eseguire:

root #ln -sf /proc/self/mounts /etc/mtab

Assicurati che /usr sia presente al boot

In una configurazione con /usr separata, utilizza un initramfs per montare /usr prima di avviare systemd. Al momento questo significa utilizzare sys-kernel/dracut o sys-kernel/genkernel-next fintanto che il supporto per /usr non sia disponibile in sys-kernel/genkernel. Trova il tempo per effettuare la migrazione:

root #emerge --ask --unmerge sys-kernel/genkernel
root #emerge --ask sys-kernel/dracut
root #emerge --ask sys-kernel/genkernel-next

Quando si utilizza dracut, si deve abilitare il modulo usrmount se non viene automaticamente abilitato per poter montare /usr automaticamente.

FILE /etc/dracut/dracut.conf
# Dracut modules to add to the default
add_dracutmodules+="usrmount"

Se si utilizza genkernel-next, prima di ricompilare il kernel, accertarsi di settare la variabile UDEV nel file di configurazione di genkernel a yes. In questo modo /usr verrà inserito nell'initramfs:

FILE /etc/genkernel.conf
# Utilizza udev al posto di  mdev come gestore di dispositivi predefinito per l'immagine  initramfs.
# Se vengono utilizzati systemd e lvm, questa opzione _deve_ essere selezionata.
UDEV="yes"
root #genkernel --install all

Si veda La guida a Initramfs per ulteriori alternative.

Utilizzare LVM e initramfs

Se si utilizza sys-fs/lvm2 e il sistema viene avviato utilizzando un'immagine initramfs; l'immagine initramfs deve essere creata utilizzando sys-kernel/genkernel-next eseguendo il comando:

root #genkernel --udev --lvm <target>

<target> è initramfs o uno degli altri targe di genkernel che implica la creazione di un'immagine initramfs. Per ulteriori informazioni, si veda l'output del comando genkernel --help:

user $genkernel --help

Se è utilizzato LVM, deve essere avviato anche il demone lvmetad, altrimenti systemd non sarà in grado di montare i volumi LVM. lvmetad può essere abilitato tramite /etc/lvm/lvm.conf:

FILE /etc/lvm/lvm.confModifiche necessarie a lvm.conf
# Imposta use_lvmetad a '1' per systemd
use_lvmetad = 1
Note
Invece di modificate /etc/lvm/lvm.conf lo stesso risultato può essere raggiunto attraverso una unità lvmetad.socket che attiva un servizio lvmetad.service, ma l'attuale versione di sys-fs/lvm2 non consente ancora questa opzione.

USE flags

USE flags for sys-apps/systemd System and service manager for Linux

acl Add support for Access Control Lists global
apparmor Enable AppArmor support local
audit Enable support for sys-process/audit local
build !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] global
cryptsetup Enable cryptsetup tools (includes unit generator for crypttab) local
curl Enable support for uploading journals; required to build systemd-import/systemd-pull local
elfutils Enable coredump stacktraces in the journal local
gcrypt Enable sealing of journal files using gcrypt; required to build systemd-import/systemd-pull local
gnuefi Enable EFI boot manager and stub loader (built using sys-boot/gnu-efi) local
http Enable embedded HTTP server in journald local
idn Enable support for Internationalized Domain Names global
importd Enable import daemon local
kmod Enable kernel module loading via sys-apps/kmod local
libidn2 If IDN support is enabled, use net-dns/libidn2 instead of net-dns/libidn local
lz4 Enable lz4 compression for the journal local
lzma Support for LZMA (de)compression algorithm global
nat Enable support for network address translation in networkd local
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip global
policykit Enable PolicyKit authentication support global
qrcode Enable qrcode output support in journal local
seccomp Enable seccomp (secure computing mode) to perform system call filtering at runtime to increase security of programs global
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur global
ssl Add support for Secure Socket Layer connections global
sysv-utils Install sysvinit compatibility symlinks and manpages for init, telinit, halt, poweroff, reboot, runlevel, and shutdown local
test Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore global
vanilla Disable Gentoo-specific behavior and compatibility quirks local
xkb Validate XKB keymap in logind local

Installazione

Abilitare la USE flag systemd a livello globale (in make.conf). La USE flag consolekit dovrebbe essere disabilitata per evitare conflitti con il servizio systemd-logind. In alternativa è possibile passare ad un subprofilo con systemd per utilizzare USE flags predefinite più sicure, nel qual caso non è necessario modificare make.conf:

root #eselect profile list

Da ultimo, si proceda all'aggiornamento del sistema con il nuovo profilo:

root #emerge -avDN @world

Se dovessero sorgere problemi di dipendenze (ad esempio sys-fs/udev che blocca sys-apps/systemd), la causa potrebbe essere la presenza nel file world di sys-fs/udev. Si può tentare di risolvere il problema, deselezionandolo:

Il pacchetto sys-apps/systemd contiene udev. Una volta installato, sys-fs/udev potrà essere rimosso in quanto systemd soddisfa la richiesta per virtual/udev.

root #emerge --deselect sys-fs/udev

Bootloader

Per poter avviare systemd, si deve modificare l'init utilizzato dall'eseguibile del kernel (o dall'immagine initramfs).

Warning
I servizi che sono stati abilitati dal precedente gestore di servizi non verranno automaticamente avviati. Ciò è dovuto al fatto che il sistema sta passando ad un nuovo gestore di servizi. Per abilitare funzionalità quali le funzioni di rete o il login manager, questi servizi devono essere nuovamente abilitati. Maggiori informazioni in merito all'abilitazione dei servizi sono disponibili nella successiva sezione di questo articolo dedicata ai servizi.
Note
Nel caso in cui il processo di migrazione porti il sistema in una condizione di errore è possibile riavviare utilizzando il gestore di servizi predefinito (OpenRC) annullando la modifica dell'init. Ciò consente un metodo sicuro e un modo per procedere con quanto indicato nella sezione dedicata alla risoluzione dei problemi, contenuta alla fine dell'articolo.

Le seguenti sottosezioni documentano come modificare l'init in uno dei boot managers o nel kernel.

GRUB Legacy (0.x)

L'argomento init=/usr/lib/systemd/systemd deve essere aggiunto alla linea di comando del kernel . Un esempio estratto da grub.conf è il seguente:

FILE /boot/grub/grub.confExample GRUB config for systemd
title=Gentoo with systemd
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 init=/usr/lib/systemd/systemd

Se il sistema deve essere utilizzato con OpenRC, si utilizzi real_init invece di init.

GRUB 2

Se si utilizza grub-mkconfig, si aggiunga l'opzione init nella GRUB_CMDLINE_LINUX:

Note
Non necessario se si utilizza un'immagine initramfs generata da dracut poichè systemd incluso nell'immagine initramfs già avvia systemd.
FILE /etc/default/grubConfigurare GRUB 2 per systemd
# Si aggiunga il parametro alla linea di comando del kernel
GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd"

Se il file di configurazione di GRUB 2 è modificato a mano (solo per esperti), si aggiunga il parametro init= al comando linux o al comando linux16.

FILE /boot/grub/grub.cfgExample GRUB2 configuration fragment
linux /vmlinuz-3.10.9 root=UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 init=/usr/lib/systemd/systemd

Se si utilizza una initrd generata con genkernel-next's initrd, si utilizzi real_init invece di init.

Note
Questo utilizzo del deprecato real_init non dovrebbe essere necessario per le versioni stabili di genkernel-next.

Configurazione direttamente nel kernel

La configurazione di init può anche essere inserita direttamente nella configurazione del kernel. Si veda Processor type and features -> Built-in kernel command line. Questa tecnica funziona sia per grub, sia per grub2.

Configurazione

systemd supporta alcuni file di configurazione del sistema per impostare i dettagli del sistema di base.

Note
Mentre alcuni parametri di configurazione possono essere aggiornati modificando gli opportuni file di configurazione, la maggior parte delle impostazioni vengono gestite utilizzando delle utility che richiedono che systemd sia in esecuzione. In questo caso, si deve riavviare il computer con systemd ed utilizzare le utility hostnamectl, localectl, e timedatectl ove richiesto.

ID Macchina

Si crei un ID macchina per consentire al journaling di funzionare. Ciò può essere fatto con il seguente comando:

root #systemd-machine-id-setup

Hostname

Per impostare il nome host, si crea/modifica /etc/hostname e semplicemente diventa disponibile il nome host impostato.

Quando il sistema viene avviato con systemd, è possibile utilizzare uno strumento chiamato hostnamectl per modificare /etc/hostname e /etc/machine-info. Per modificare il nome host, si esegua:

root #hostnamectl set-hostname <NOME HOST>

Si veda man hostnamectl per ulteriori opzioni


Localizzazione

Solitamente, le localizzazioni dovrebbero venire correttamente migrate da OpenRc al momento di installazione di systemd. Quando necessario, la localizzazione dovrebbe essere impostata mediante /etc/locale.con come indicato nelle istruzioni del manuale Gentoo

FILE /etc/locale.confConfigurazione localizzazione del sistema
LANG="en_US.utf8"

Dopo che il sistema è stato avviato con systemd, verrà utilizzato localectl per imposta la localizzazione e le mappe per la tastiera della console e di X11. Per modificare la localizzazione del sistema, eseguire il seguente comando:

root #localectl set-locale LANG=<LOCALE>

Per modificare la keymap della console virtuale:

root #localectl set-keymap <KEYMAP>

E da ultimo, per impostare la configurazione di X11:

root #localectl set-x11-keymap <LAYOUT>

Ove necessario, possono essere specificate sia la variante sia le opzioni:

root #localectl set-x11-keymap <LAYOUT> <MODEL> <VARIANT> <OPTIONS>

Ora e data

Ora e data possono essere impostate utilizzando timedatectl. Ciò consente agli utenti di impostare la sincronizzazione senza doversi appoggiare a net-misc/ntp o ad altri programmi diversi dall'implementazione diretta di systemd.

Per imparare ad utilizzare timedatectl si esegua il comando:

root #timedatectl --help

Caricamento automatico dei moduli

Il caricamento automatico dei moduli viene configurato tramite un file, o una directory di files. I file di configurazione sono localizzati in /etc/modules-load.d. All'avvio viene caricato ogni file contenete una lista di moduli. Il formato dei file è una lista di moduli separati da un carattere di newline e può avere qualunque nome purché termini con .conf. l modulo che deve essere caricato può essere separato da un programma, sevizio o un qualunque modo risponda alle proprie preferenze personali. Nel seguente listato, un esempio per virtualbox.con

FILE /etc/modules-load.d/virtualbox.confFile di esempio per i moduli di virtualbox
vboxdrv
vboxnetflt
vboxnetadp
vboxpci

Rete

systemd-networkd

systemd-networkd è utile per semplici configurazioni di reti cablate. Per impostazione predefinita è disabilitato.

Per configurare systemd-networkd, si crei un file

  • .network in /etc/systemd/network. Si veda systemd.network(5) per informazioni. Una semplice configurazione DHCP è fornita nel seguente esempio:
FILE /etc/systemd/network/50-dhcp.network
[Match]
Name=en*
 
[Network]
DHCP=yes
root #systemctl enable systemd-networkd.service
root #systemctl start systemd-networkd.service

Si noti che systemd-networkd non aggiorna resolv.conf per impostazione predefinita. Per consentire a systemd di gestire le impostazioni DNS, si sostituisca resolv.conf con un link simbolico e si avvi systemd-resolved.

root #ln -snf /run/systemd/resolve/resolv.conf /etc/resolv.conf
root #systemctl enable systemd-resolved.service
root #systemctl start systemd-resolved.service

NetworkManager

Frequentemente viene utilizzato NetworkManager per configurare le impostazioni di rete. A tal fine, si esegua semplicemente il seguente comando se si utilizza un ambiente desktop con supporto a X11:

root #nm-connection-editor

Se non è questo il calo e le reti devono essere configurate tramite una console, si legga il documento nmcli, oppure si avvii un processo di configurazione guidato tramite nmtui:

root #nmtui

nmtui è un'interfacca curses che guiderà l'utente nel processo di configurazione tramite linea di comando.

Gestione dei file di log

systemd ha un suo modo per la gestione dei file di log e non necessita di appoggiardi ad alcun sistema esterno di log (tipo app-admin/syslog-ng o app-admin/rsyslog).I messaggi possono essere letti tramite journalctl. systemd può anche essere configurato per utilizzare uno strumento esterno per la gestione dei log. Si veda man journald.conf per imparare a configurare journald secondo le proprie esigenze personali.

Alcune opzioni comuni per journalctl:

Command line options for journalctl Result
journalctl without options Show all log entries, starting with earliest.
-b, --boot Show all log entries from this boot.
-r, --reverse Newest entries first.
-f, --follow Show the last few entries and display new log entries as they're being produced.
-p, --priority= Specify (minimum) priority to display messages, with a choice from: "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7).
--since=, --until= Restrict entries by time. Accepts the format "YYYY-MM-DD hh:mm:ss" or the strings "yesterday", "today" and "tomorrow".
-n, --lines= Restrict to a number of entries.
-k, --dmesg Restrict to kernel messages.
-u, --unit= Restrict to a certain Systemd unit.

Per maggiori informazioni e le ulteriori opzioni, si veda man journalctl.

/tmp adesso è posizionata in tmpfs

A meno che non sia esplicitamente indicato in /etc/fstab un altro filesystem da montare in /tmp, systemd monterà /tmp come tmpfs. Ciò significa che la directory verrà svuotata ad ogni avvio e le sue dimensioni saranno limitate al 50% della memoria RAM di sistema. Per capire perché questo è il comportamento voluto e come modificarlo, si veda API File Systems.

Configurare la verbosità del processo di avvio

Quando si passa a systemd, gli utenti notano differenze nella verbosità del processo di avvio:

  • L'opzione di avvio quiet non solo influenza l'output del kernel, ma anche quella dello stesso systemd. Per questa ragione, quando si sta installando sistemd, è necessario eliminare tale opzione per leggere in maniera più facile eventuali errori rilevati nella fase di avvio. Dopo sarà possibile ritornare ad un avvio più silenzioso (e veloce).
  • Anche se è impostat l'opzione di avvio quiet, systemd può comunque essere configurato per mostrare i suoi messaggi di stato, mediante l'opzione di avvio systemd.show_status=1.
  • Quando non si utilizza l'opzione di avvio quiet, alcuni messaggi possono sovrascrivere le console. Ciò è provocato dalla configurazione del kernel (si veda man 5 proc e si cerchi /proc/sys/kernel/printk). Per modificare questo comportamento trasmetta il parametro di avvio loglevel=5 al kernel (e si aggiorni il valore a secondo delle proprie preferenze, ad esempio fissandolo ad un valore inferiore, ad esempio: 1).

Servizi

Ad un certo punto il sistema dovrà essere riavviato per poter avere systemd in esecuzione (in modalità sistema). CI si assicuri di aver letto tutto questo documento erp essere sicuri che systemd sia configurato nella maniera il più completa possibile prima di riavviare. Si noti che journalctl funziona anche con systemd non avviato. Si completi la configurazione dei servizi (abilitando e avviando i servizi) dopo essersi loggati sul sistema con systemd avviato.

I servizi di OpenRC

Benché l'intenzione originaria di systemd fosse quella di supportare tutti i vecchi script init.d, tale supporto non si adatta bene ad un sistema di avvio dei servizi basato su delle dipendenze come OpenRC, e, per tale motivo, in Gentoo questo supporto è completamente disabilitato. OpenRC fornisce controlli ulteriori per assicurare che gli script init.d non vengano eseguiti quanto non è stato utilizzato OpenRC per avviare il sistema (altrimenti i risultati non sarebbero predicibili).

Elencare i servizi disponibili

Tutti le unità relative a servizi possono essere elencate utilizzando l'argomento list-units di systemctl

root #systemctl list-units
UNIT                               LOAD   ACTIVE SUB       DESCRIPTION
boot.automount                     loaded active waiting   EFI System Partition Automount
proc-sys-fs-binfmt_misc.automount  loaded active waiting   Arbitrary Executable File Formats File System Automount Point
...

Sono di interesse le seguenti estensioni dei file:

Suffix Description
.service files semplici per i servizi (es. quelli che avviano direttamente un demone),
.socket socket listeners (molto simile a inetd),
.path filesystes che fanno avviare dei servizi (avvio di un servizio quando un file cambia etc.).

In alternativa, si può utilizzare lo strumento systemctl per elencare tutti i servizi, (inclusi quelli impliciti):

root #systemctl --all --full

E, da ultimo, è possibile controllare i servizi il cui avvio è fallito:

root #systemctl --failed

Abilitare, disabilitare, avviare e fermare i servizi

Il sistema normale per abilitare all'avvio un servizio è utilizzare il seguente comando

root #systemctl enable foo.service

Allo stesso modo possono essere disabilitati i servizi:

root #systemctl disable foo.service

Questi comandi abilitato i servizi utilizzando il loro nome predefinito nel target predefinito (entrambe specificati nella sezione "Install" del file del servizio). In alcuni casi i servizi non forniscono tali informazioni o gli utenti preferiscono avere un differente nome/target,

Si osservi che questi comandi abilitano o disabilitano un servizio in modo che lo stesso venga avviato o non avviato al successivo avvio del sistema; per avviare un servizio immediatamente si utilizzi:

root #systemctl start foo.service

Allo stesso modo, i servizi possono essere fermati:

root #systemctl stop foo.service

Installazione di file di unità personalizzati

In /etc/systemd/system possono esser posizionati dei file unità personalizzati; questi verranno riconosciuti dopo aver eseguito systemctl daemon-reload:

root #systemctl daemon-reload

/usr/lib/systemd/system è riservata per l'installazione di file di servizi effettuata dal gestore di pacchetti.

Personalizzare i file unità

Quando sono necessarie solo modifiche minime ad una unità, non c'è alcun bisogno di creare una copia totale del file unità originale in /etc/systemd/system. E' possibile sovrascrivere le impostazioni predefinite di un file unità installato dal gestore di pacchetti, mediante la creazione di files in una directory

  • .d, contenuta in /etc/systemd/system/, che abbia lo stesso nome dell'unità originaria (ad esempio: apache2.d).
FILE /etc/systemd/system/apache2.d/mem-limit.confEsempio di aggiunta/sovrascrittura delle impostazioni di un servizio
[Service]
MemoryLimit=1G

E' necessario ricaricare systemd, per informarlo delle modifiche:

root #systemctl daemon-reload

A questo punto il servizio deve essere riavviato, affinché le modifiche abbiano effetto:

root #systemctl restart apache2

Verificare che le impostazioni modificate siano state applicate al servizio:

root #systemctl show --property=MemoryLimit apache2
MemoryLimit=1074000000

Abilitare un servizio con un nome personalizzato

Se il nome fornito dalla direttiva "Alias" nella sezioni "[Install]" dell'unità non è quello voluto e non si desidera una modifica permanente del valore tramite una personalizzazione, si può creare manualmente un link simbolico in /etc/systemd/system/*.wants/. Il nome della directory

  • .wants può specificare sia un target sia un altro servizio che dipenderà dal nuovo.

Ad esempio, perinstallare mysqld.service come db.service in multi-user.target:

root #ln -s /usr/lib/systemd/system/mysqld.service /etc/systemd/system/multi-user.target.wants/db.service

Per disabilitare il servizio, si rimuova il collegamento simbolico:

root #rm /etc/systemd/system/multi-user.target.wants/db.service

Servizi nativi

Alcuni pacchetti Gentoo già installano file di unità per systemd. Per questi servizi, è semplice abilitarli. Un breve riassunto dei pacchetti che installano file di unità è disponibile all'indirizzo systemd eclass users list.

La seguente tabella elenca i servizi systemd che corrispondono ai servizi OpenRC:

Migration chart
Pacchetto Gentoo Servizio OpenRC unità systemd Note
sys-apps/openrc bootmisc systemd-tmpfiles-setup.service sempre abilitato, utilizza tmpfiles.d
consolefont systemd-vconsole-setup.service sempre abilitato, utilizza vconsole.conf
devfs
dmesg
fsck fsck*.service inserito implicitamente da mounts
functions.sh Vedi nota bug #373219
hostname (builtin) /etc/hostname
hwclock Vedi nota sempre abilitato come parte di systemd (è un componente di systemd e non una unità)
keymaps systemd-vconsole-setup.service sempre abilitato, utilizza vconsole.conf
killprocs
local
localmount local-fs.target le effettive unità vengono create implicitamente da /etc/fstab
modules systemd-modules-load.service sempre abilitato, utilizza /etc/modules-load.d/*.conf
mount-ro
mtab
netmount remote-fs.target
numlock
procfs (builtin)
root remount-rootfs.service
savecache n/a OpenRC internals
staticroute
swap swap.target le effettive unità vengono create implicitamente da /etc/fstab
swclock
sysctl systemd-sysctl.service sysctl.conf e sysctl.d/
sysfs (builtin)
termencoding systemd-vconsole-setup.service sempre abilitato, utilizza vconsole.conf
urandom systemd-random-seed-load.service
systemd-random-seed-save.service
app-admin/rsyslog rsyslog rsyslog.service
app-admin/syslog-ng syslog-ng syslog-ng.service
media-sound/alsa-utils alsasound alsa-store.service (abilitato per impostazione predefinita)
alsa-restore.socket (abilitato per impostazione predefinita)
net-misc/dhcpcd dhcpcd dhcpcd.service
net-misc/netifrc net.* net@.service wrapper systemd per gli script net.* (reso disponibile da net-misc/netifrc)
netctl@.service net-misc/netctl originariamente è uno strumento di Arch Linux.
NetworkManager.service con <networkmanager-0.9.8.4 : si abiliti NetworkManager-dispatcher.service per far funzionare gli script dispatcher.d .
Si abiliti NetworkManager-wait-online.service per controllare che il sistema disponga di una connessione ad internet funzionante.
Si disabilitino tutti gli altri gestori (come wicd, dhcpcd) e wpa_supplicant.
dhcpcd.service Reso disponibile da net-misc/dhcpcd
systemd.networkd.service Parte di systemd
net-misc/openntpd ntpd ntpd.service
net-misc/openssh sshd sshd.service esegue sshd come un demone
sshd.socket esegue sshd in modalità inetd-like (per ogni connessione in entrata)
net-wireless/wpa_supplicant wpa-supplicant wpa_supplicant.service demone controllato da D-Bus (es. per NetworkManager)
wpa_supplicant@.service wpa_supplicant specifico per singola interfaccia (utilizzato come wpa_supplicant@wlan0.service)
net-print/cups cupsd cups.service tipico servizio avviato al boot
cups.socket attivazione da socket e percorso (cups viene avviato on-demand)
cups.path
net-wireless/bluez bluetooth bluetooth.service
sys-apps/dbus dbus dbus.service
dbus.socket
sys-apps/irqbalance irqbalance irqbalance.service supporta solo la modalità daemon
sys-apps/microcode-ctl microcode_ctl Si configuri microcode come un module per consentire il caricamento dello stesso microcode. Andare in "Processor type and features" -> "CPU microcode loading support" e ricordarsi di aggiungere le opzioni corrette a seconda che il systema disponga di un processore intel o amd.
sys-fs/udev udev udev.service
udev-mount (builtin) /dev è montato come tmpfs
udev-postmount udev-trigger.service
udev-settle.service
sys-power/acpid acpid acpid.service Molte delle sue funzionalità vengono fornite dallo stesso systemd, si consideri, quindi, la possibilità di disabilitare il servizio
x11-apps/xdm (xdm) xdm.service OpenRC utilizza i semplici xdm init.d installati da x11-base/xorg-server. Con systemd devono essere abilitate le corrispondenti unità per ciascun DM (gdm.service, kdm.service...).
net-firewall/iptables iptables iptables-store.service
iptables-restore.service

Servizi Timer

Sin dalla versione 197 systemd supporta i timer, rendendo cron inutile in un sistema con systemd. Sin dalla versione 212 vengono supportati i servizi persistenti, sostituendo, quindi anacron. I timer persistenti vengono avviati alla successiva occasione se il sistema è spento al momento in cui gli stessi sono programmati.

Il seguente è un esempio su come creare un semplice timer che giri in contesto utente. Quest verrà eseguito anche se l'utente non è loggato. Ogni servizio temporizzato necessita di un timer e di un file di servizio che viene avviato dal timer nel seguente modo:

FILE ~/.local/share/systemd/user/backup-work.timerEsempio di un timer che si avvia in ogni giorno lavorativo
[Unit]
Description=lavoro quotdiano di backup
RefuseManualStart=no
RefuseManualStop=no
 
[Timer]
Persistent=false
OnCalendar=Mon-Fri *-*-* 11:30:00
Unit=backup-work.service
 
[Install]
WantedBy=default.target
FILE ~/.local/share/systemd/user/backup-work.serviceEsempio di un servizio che avvia un backup
[Unit]
Description=lavoro quotidiano di backup
RefuseManualStart=no
RefuseManualStop=yes
 
[Service]
Type=oneshot
ExecStart=/home/<user>/scripts/backup-work.sh

Per primo, far eseguire una nuova scansione dei file dei servizi a systemd:

user $systemctl --user daemon-reload

E' possibile avviare il backup manualmente eseguendo il seguente comando:

user $systemctl --user start backup-work.service

Avviare e fermare il timer, nel seguente modo:

user $systemctl --user start backup-work.timer
user $systemctl --user stop backup-work.timer

In ultimo, per avviare il timer ad ogni avvio del sistema, eseguire:

user $systemctl --user enable backup-work.timer

Per controllare l'ultimo risultato del servizio in esecuzione:

user $systemctl --user list-timers

Invio di email in caso di fallimenti

E' possibile inviare una mail nel caso in cui un servizio temporizzato venga avviato e fallisca l'esecuzione, in modo da informare l'utente o l'amministratore. Ciò è reso possibile dalla direttiva "OnFailure" che specifica cosa dovrebbe avvenire se l'avvio del servizio fallisce. Un fallimento viene individuato se lo script con cui il servizio viene invocato restituisce u valore diverso da zero.

A tal fine, si modifichi lo script come segue:

FILE ~/.local/share/systemd/user/backup-work.serviceEsempio di un servizio che avvia un backup
[Unit]
Description=lavoro quotidiano di backup
RefuseManualStart=no
RefuseManualStop=yes
OnFailure=failure-email@%i.service
 
[Service]
Type=oneshot
ExecStart=/home/<user>/scripts/backup-work.sh

In questo caso, è necessario avere il servizio failure-email@.service installato; il servizio è disponibile in kylemanna's systemd-utils repository.

Sostituire cron

I suddetti file per timer e servizi possono anche essere aggiunti in /usr/lib/systemd/system per renderli disponibili a tutti gli utenti del sistema. In questo caso la sezione Install dovrebbe contenere WantedBy=multi-user.target per consentire l'avvio del servizio all'avvio del sistema.

In ogni caso, cron esegue comunque gli script in /etc/cron.daily e in altre posizioni. Molti pacchetti posizionano in quelle cartelle gli script che si attendono vengano eseguiti quotidianamente. Questo comportamento può essere emulato con systemd, installando sys-process/systemd-cron. A questo punto si attivi il nuovo sostituto di cron con il seguente comando:

root #systemctl enable cron.target
root #systemctl start cron.target

Risoluzione dei problemi

/dev/kmsg buffer overrun, alcuni messaggi persi

Problema
All'avvio il sistema mostra un ciclo infinito di /dev/kmsg buffer overrun, some messages lost. La schermata di login non appare mai sulla console in quanto il sistema non arriva mai a quel punto del processo di avvio.
Soluzione
Nella maggior parte dei casi questo problema si verifica quanto è abilitata nel kernel l'opzione CONFIG_POWER_SUPPLY_DEBUG. Attualmente la soluzione è quella di disabilitare questa opzione nel kernel, ricompilare, installare e aviare il nuovo kernel. La soluzione può anche essere trovata all'indirizzo this thread sul forum di Gentoo. Secondo un utente del forum, questo problema è stato riscontrato utilizzando I2C EEPROM su un sistema embedded [2]. La soluzione in questo caso è di disabilitare l'opzione del kernel CONFIG_I2C_DEBUG_CORE.

Sessioni Grafiche aperte in posizioni random

Per impostazione predefinita systemd avvia un processo getty solo quando lo stesso deve essere utilizzato. Questo causa ad alcuni gestori di display (come GDM) di utilizzare le restanti TTY per avviare sessioni grafiche a richiesta, il che può risultare in console e sessioni grafiche posizionate in maniera random, a secondo dell'ordine in cui sono state utilizzate.

Per costringere il sistema ad un comportamento più "classico" (ad esempio, le console posizionate da tty1 a tty6 e le sessioni grafiche che utilizzano le restanti TTYs) si può chiedere che getty venga eseguito su quelle TTY:

root #systemctl enable getty@tty{2,3,4,5,6}.service

LVM

Quando si passa da OpenRC a systemd e si utilizza LVM per montare i volumi di sistema, si deve attivare il servizio LVM:

root #systemctl enable lvm2-monitor.service

Benché potrebbe non essere necessario per l'attivazione del volume root (nel caso in cui LVM sia integrato nella immagine initramfs), non funzionerà per gli altri volumi LVM, a meno che non venga attivato il servizio LVM.

systemd-bootchart

Ci si assicuri che siano abilitati CONFIG_DEBUG_KERNEL, CONFIG_SCHED_DEBUG e CONFIG_SCHEDSTATS.

KERNEL Enable systemd-bootchart support
File systems  --->
	Pseudo filesystems --->
	[*] /proc file system support
Kernel hacking  --->
	[*] Kernel debugging
	[*] Collect scheduler debugging info
	[*] Collect scheduler statistics

Successivamente, si abiliti systemd-bootchart.service:

root #systemctl enable systemd-bootchart

Il risultato delle modifiche produrrà un report bootchart in formato SVG posizionato in /run/log/ dopo ogni avvio. Il file può essere visualizzato tramite un moderno browser web.

In altertiva a systemd-bootchart l'avvio dei servizi può essere visualizzato con:

root #systemd-analyze plot > plot.svg

sorgenti syslog-ng per systemd

Non c'è "alcuna necessità" di aggiungere unix-dgram('/dev/log'); al file di configurazione /etc/syslog-ng/syslog-ng.conf. Ciò causerà un errore in syslog-ng (almeno nella versione syslog-ng-3.7.2). Aggiornare la riga source src { ...; }; menzionata, in syslog-ng article nel seguente modo:

FILE /etc/syslog-ng/syslog-ng.conf
# default config for openrc
#source src { system(); internal(); };
 
# systemd
source src { systemd-journal(); internal(); };

configurazione sys-fs/cryptsetup

systemd sembra non rispettare /etc/conf.d/dmcrypt (si veda bug #429966) e quindi deve essere configurato tramite il file /etc/crypttab:

FILE /etc/crypttabFile di configurazione per i dispositivi a blocchi criptati
crypt-home UUID=c25dd0f3-ecdd-420e-99a8-0ff2eaf3f391 -

Assicurati di abilitare la USE flag cryptsetup per sys-apps/systemd. Installerà /usr/lib/systemd/system-generators/systemd-cryptsetup-generator che creerà automaticamente un servizio (cryptsetup@crypt-home.service nel precedente esempio) per ogni riga al boot.

Controllo delle unità il cui avvio è fallito

Si controllino le unità il cui avvio è fallito con:

root #systemctl --failed

Abilitazione modalità di Debug

Per ottenere maggiori informazioni si inserisca la seguente stringa in /etc/systemd/system.conf:

FILE /etc/systemd/system.conf
LogLevel=debug

oppure può essere abilitata la console di debug che apre un terminale su tty9. Questo aiuta ad effettuare il debug dei servizi durante il processo di avvio.

root #systemctl enable debug-shell.service

usare e4rat

Ricordarsi di modificare /etc/e4rat.conf impostando 'init' a /usr/lib/systemd/systemd, altrimenti e4rat continuerà ad avviare OpenRC.

aumento di sicurezza con GRSecurity

Se è abilitata grsecurity, systemd-networkd potrebbe registrare nei log il seguente errore:

CODE systemd-networkd error
could not find udev device: Permission denied

La condizione di errore è generata dal fatto che systemd-networkd sta lavorando con un utente non-root user e grsecurity rifiuta l'accesso all'intera struttura /sys per quell'utente. Per disabilitare questa opzione, si disabiliti l'opzione del kernel CONFIG_GRKERNSEC_SYSFS_RESTRICT.

Anche logind potrebbe avere dei problemi di permessi con CONFIG_GRKERNSEC_PROC attiva, si veda bug #472098.

shutdown -rF non forza fsck

Il servizio systemd-fsck è responsabile per l'esecuzione di fsck quando necessaria. Non tiene conto dell'opzione -rF di shutdown, ma onora i seguenti parametri di boot del kernel.

Parametri di avvio Opzioni supportate Descrizione
fsck.mode auto
force
skip
Controlla la modalità operativa. La modalità predefinita è auto,e assicura che i controlli sul filesystem vengano effettuati quando il controllore del filesystem li ritiene necessari. force comporta incondizionatamente un controllo completo del filesystem. skip salta ogni controllo sul filesystem.
fsck.repair preen
yes
no
Controlla la modalità operativa. La modalità predefinita è preen, che automaticamente ripara i problemi che possono essere fissati in sicurezza. yes risponderà "Sì" ad ogni domanda fatta da fsck e no risponderà no a tutte le domande.

Si veda anche

Risorse esterne

Riferimenti