Systemd

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Systemd and the translation is 54% complete.
Outdated translations are marked like this.

systemd è un init moderno su stile SysV e un sostituto a rc per i sistemi Linux. Viene supportato da Gentoo come init system alternativo.

Cambiare sistema d'init non è un'operazione banale ed ha importanti implicazioni sulla configurazione di sistema, ed alle volte su quali programmi possono venir installati. Generalmente un sistema d'init viene scelto all'installazione (alla scelta di scaricare una tarball stage3 systemd od openrc), ed è cambiato solamente se necessario. In vero stile Gentoo, in aggiunta a systemd ed OpenRC, multipli sistemi d'init sono supportati.

Se systemd viene richiamato involontariamente come dipendenza, si faccia riferimento a Gentoo senza systemd.

Installazione

Importante
Quando si aggiorna da <=sys-apps/systemd-203 controllare la sezione aggiornamento.

Il nucleo su cui tutte le distribuzioni si basano è il kernel Linux. Esso fa da intermediario tra i programmi dell'utente ed il sistema fisico (hardware). Gentoo offre ai suoi utenti numerosi possibili sorgenti per il kernel. Una lista completa con descrizioni è disponibile alla pagina panoramica sui Kernel.

Per i sistemi basati su amd64, Gentoo consiglia il pacchetto sys-kernel/gentoo-sources.

Scegliere un sorgente kernel appropriato ed installarlo usando emerge:

root #emerge --ask sys-kernel/gentoo-sources

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 Impostazione rapida usando 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  --->
	[*] Control Group support --->
		[*]   Support for eBPF programs attached to cgroup
	[ ] Enable deprecated sysfs features to support old userspace tools
	[*] Configure standard kernel features (expert users)  --->
		[*] open by fhandle syscalls
		[*] Enable eventpoll support
		[*] Enable signalfd() system call
		[*] Enable timerfd() system call
	[*] Enable bpf() 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 raccomandate
General setup  --->
	[*] Configure standard kernel features (expert users)  --->
		[*] 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".

KERNEL BFQ scheduler
IO Schedulers  --->
	<*> BFQ I/O scheduler
        [*]   BFQ hierarchical scheduling support

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

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 sys-kernel/genkernel

or

root #emerge --ask sys-kernel/dracut

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

FILE /etc/dracut.conf.d/usrmount.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 --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

USE flags

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

acl Add support for Access Control Lists
apparmor Enable support for the AppArmor application security system
audit Enable support for sys-process/audit
boot Enable EFI boot manager and stub loader
cgroup-hybrid Default to hybrid (legacy) cgroup hierarchy instead of unified (modern).
cryptsetup Enable cryptsetup tools (includes unit generator for crypttab)
curl Enable support for uploading journals
dns-over-tls Enable DNS-over-TLS support
elfutils Enable coredump stacktraces in the journal
fido2 Enable FIDO2 support
gcrypt Enable use of dev-libs/libgcrypt for various features
gnutls Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl)
homed Enable portable home directories
http Enable embedded HTTP server in journald
idn Enable support for Internationalized Domain Names
importd Enable import daemon
iptables Use libiptc from net-firewall/iptables for NAT support in systemd-networkd; this is used only if the running kernel does not support nftables
kernel-install Enable kernel-install
kmod Enable kernel module loading via sys-apps/kmod
lz4 Enable lz4 compression for the journal
lzma Support for LZMA compression algorithm
openssl Enable use of dev-libs/openssl for various features
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
pcre Add support for Perl Compatible Regular Expressions
pkcs11 Enable PKCS#11 support for cryptsetup and homed
policykit Enable PolicyKit (polkit) authentication support
pwquality Enable password quality checking in homed
qrcode Enable qrcode output support in journal
resolvconf Install resolvconf symlink for systemd-resolve
seccomp Enable seccomp (secure computing mode) to perform system call filtering at runtime to increase security of programs
secureboot Automatically sign efi executables using user specified key
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
split-usr Enable behavior to support maintaining /bin, /lib*, /sbin and /usr/sbin separately from /usr/bin and /usr/lib*
sysv-utils Install sysvinit compatibility symlinks and manpages for init, telinit, halt, poweroff, reboot, runlevel, and shutdown
test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
tpm Enable TPM support
ukify Enable systemd-ukify
vanilla Disable Gentoo-specific behavior and compatibility quirks
xkb Depend on x11-libs/libxkbcommon to allow logind to control the X11 keymap
zstd Enable support for ZSTD compression

Profilo

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
Nota
Once this command is complete, it is important follow the Configuration steps.

Problemi di dipendenze

Quando si sostituisce OpenRC con systemd, alcuni problemi di dipendenze potrebbero sorgere.

Se sys-apps/sysvinit blocca sys-apps/systemd, provare a disabilitare la netifrc USE flag per sys-apps/openrc. Rebuilda OpenRC temporaneamente per rompere la dipendenza con net-misc/netifrc seguito da un'operazione di depclean:

root #emerge --oneshot sys-apps/openrc
root #emerge --ask --depclean

If sys-apps/sysvinit is still blocking sys-apps/systemd, make sure it and sys-apps/openrc are not contained in the world file:

root #emerge --deselect sys-apps/openrc sys-apps/sysvinit

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:

root #emerge --deselect sys-fs/udev

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.

Se il sistema fornisce sys-fs/eudev, virtual/udev o virtual/libudev potrebbe prevenire l'installazione di systemd. Per risolvere il problema, dopo aver settato le USE flag, reinstallare i virtuali:

root #emerge --oneshot virtual/udev virtual/libudev

Bootloader

Importante
Questo non è più necessario con sys-apps/systemd quando la USE flag sysv-utils è abilitata. Questa impostazione predefinita è attiva dalla versione 239 in Gentoo

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

Attenzione
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.
Nota
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=/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:

Nota
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=/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.cfgEsempio di configurazione do GRUB2
linux /vmlinuz-3.10.9 root=UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 init=/lib/systemd/systemd

YABOOT

Yaboot è un bootloader per i sistemi basati su PowerPC con Linux, in particolare i sistemi New World ROM Macintosh.

L'argomento init=/lib/systemd/systemd deve essere aggiunto subito dopo la linea di comando del kernel. Un esempio da yaboot.conf:

FILE /etc/yaboot.confEsempio di configurazione di yaboot per systemd
image=/vmlinux 
   append="init=/lib/systemd/systemd" 
   label=Linux 
   read-only 
   initrd=/initramfs 
   initrd-size=8192

Usare il comando ybin ogni volta che viene modificato yaboot.conf per rendere le modifiche effettive.

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.

Aggiornamenti

systemd ha l'abilità di aggiornarsi sul momento in una macchina in funziona (nessun riavvio richiesto). Dopo che un aggiornamento di systemd è stato emerso, usare il seguente comando:

root #systemctl daemon-reexec

Configurazione

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

After installing systemd, run the following:

root #systemd-machine-id-setup
root #systemd-firstboot --prompt
root #systemctl preset-all
Attenzione
If systemd-firstboot is not ran, it will automatically run on next boot. However, it interrupts the normal boot process, preventing access to the system from users who don't have access to the interactive console - like accessing a server via SSH.
Nota
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
Nota
Il comando systemd-machine-id-setup ha anche impatto sul servizio systemd-networkd. Se non viene usato questo comando, potrebbero capitare strani problemi come l'interfaccia di rete che non si abilita o l'indirizzo di rete potrebbe non essere applicato correttamente.

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>


Dopo aver eseguito qualsiasi dei comandi precedenti, aggiornare il sistema così che le modifiche abbiano effetto:

root #env-update && source /etc/profile
root #env-update && source /etc/profile

Ora e data

Ora, data e fuso orario possono essere impostati 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

Automatic mounting of partitions at boot

Systemd is capable of automatically mounting various partitions to standardized location via systemd-gpt-auto-generator. This makes it possible to boot and automatically mount essential partitions without an fstab and without a root= paramter on the kernel command line. To use this capability, first systemd must be included in the initramfs, this is the case by default for initramfs images generated with Dracut on systems with systemd installed. And second, each partition must have the correct Partition Type GUID. A list of the most important GUIDs can be found in the systemd-gpt-auto-generator manual, the full list can be found on wikipedia.

To list the current Partition Type GUID of your partitions:

root #lsblk -o NAME,LABEL,PARTLABEL,PARTTYPE,PARTTYPENAME,MOUNTPOINT

systemd-gpt-auto-generator can auto-mount partitions at the following locations, note that the correct GUID depends on the systems CPU architecture:

  • / SD_GPT_ROOT_....
  • /boot/ SD_GPT_ESP if no /efi/ and no XBOOTLDR partition, otherwise SD_GPT_XBOOTLDR
  • /efi/ SD_GPT_ESP if /efi/ is present on the root, if not then ESP is at /boot/
  • /home/ SD_GPT_HOME
  • /srv/ SD_GPT_SRV
  • /usr/ SD_GPT_USR_....
  • /var/ SD_GPT_VAR
  • /var/tmp/ SD_GPT_TMP
  • Swap SD_GPT_SWAP

Below is an example of the most basic partition layout consisting of one EFI System Partition and one x86-64 root partition.

root #lsblk -o NAME,LABEL,PARTLABEL,PARTTYPE,PARTTYPENAME,MOUNTPOINT
NAME        LABEL    PARTLABEL            PARTTYPE                             PARTTYPENAME                 MOUNTPOINT
nvme1n1
├─nvme1n1p1 ESP      EFI System Partition c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System                   /boot
└─nvme1n1p2 Gentoo   Gentoo               4f68bce3-e8cd-4db1-96e7-fbcaf984b709 Linux root (x86-64)          /

The PARTTYPE for an EFI System Partition is c12a7328-f81f-11d2-ba4b-00a0c93ec93b, it will be mounted at either /efi/ or /boot/ depending on which of these mount points is available and on if there is also an Extended Boot Loader Partition (PARTTYPE=bc13c2ff-59e6-4262-a352-b275fd6f7172) present on this disk. The PARTTYPE for an x86-64 root parition is 4f68bce3-e8cd-4db1-96e7-fbcaf984b709.

If the Partition Type GUID is not correct it can be changed without data loss using a partitioning tool such as fdisk. Note that the system must be offline to change the patition types! A system rescue image, or secondary operating system, must be used to complete the following steps.

Open the disk with the to be changed partition types in fdisk, in this exameple /dev/nvme1n1 is used:

root #fdisk /dev/nvme1n1
 
Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
 
 
Command (m for help):

List the current partition layout with the p command:

Command (m for help): p
 
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B25D5B33-4A10-F940-826C-3CB24ADC7D86
 
Device           Start        End    Sectors  Size Type
/dev/nvme1n1p1    2048    1052671    1050624  513M EFI System
/dev/nvme1n1p2 1052672 3907028991 3905976320  1.8T Linux root (x86-64)

Change the Partition Type GUID of any partition with the t command, followed by the number of the partition to be changed, and finally the alias for the desired partition type:

Command (m for help): t
Partition number (1,2, default 2): 2
Partition type or alias (type L to list all): L
Partition type or alias (type L to list all): 23
 
Changed type of partition 'Linux root (x86-64)' to 'Linux root (x86-64)'.

Repeat the above steps for any additional partitions of which the Partition Type GUID should be changed. Once completed, save the changes with the w command:

Command (m for help): w
Nota
systemd-gpt-auto-generator will only auto-mount partitions that reside on the same disk as the EFI System Partition that the system is being booted from.
Suggerimento
Some tools may become confused if there is no root= parameter on the kernel command line at all. To placate such tools add root=/dev/gpt-auto-root to the kernel command line. This trick is also usefull if a swapfile on the root partition is used instead of a swap partition for hibernation, i.e. one may specify the resume target on the kernel command line as resume=/dev/gpt-auto-root resume_offset=xxxxxxxxx.

Rete

systemd is compatible with various network management tools.

systemd-networkd

See the systemd/systemd-networkd article for details on setting up a wired network on systemd systems.

systemd-resolved

See the systemd/systemd-resolved article for details on setting up address name resolution (DNS) on systemd systems.

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 grafico:

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.

For more details see the dedicated article.

Gestione dei file di log

systemd ha un suo modo per la gestione dei file di log e non necessita di appoggiarsi ad alcun sistema esterno di log (come ad esempio app-admin/syslog-ng o app-admin/rsyslog).

Se desiderato, il servizio di logging può essere configurato per per passare messaggi di log a utilità di logging come sysklog os syslog-ng. Vedere man journald.conf per imparare come configurare il servizio systemd-journald per soddisfare le esigenze situazionali.

Il servizio di logging integrato di systemd scrive i messaggi di registro in un formato binario sicuro. I log vengono letti utilizzando il comando journalctl, che è un eseguibile separato dal servizio di log systemd-journald.

Importante
Quando si utilizza systemd-journald.service di systemd per il logging, che è in genere l'impostazione predefinita per i sistemi che eseguono systemd, gli utenti standard che eseguono il comando journalctl non saranno in grado di visualizzare i registri di sistema. Per visualizzare i log di sistema come account non root, gli utenti devono appartenere a uno dei seguenti tre gruppi di utenti per visualizzare i log di sistema: systemd-journal', adm o 'wheel. Il metodo più semplice per consentire a un utente standard di visualizzare i registri è utilizzare il gruppo systemd-journal. Aggiungi un utente eseguendo il comando seguente dove larry è il nome utente desiderato:

root #gpasswd --add larry systemd-journal
System log ora possono essere letti usando il comando journalctl --system dagli utente/i aggiunti nel comando precedente.

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 the current boot.
-r, --reverse Show the newest log entries first (reverse chronological order).
-f, --follow Show the last few entries and display new log entries as they're being produced. This is similar to running tail -f in text logging utilities.
-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.
--system View system service and kernel logs. By default, this is only possible as the root user. See man journalctl for how to grant standard users the ability to read the system journal.

| journalctl without options || Show all log entries, starting with earliest. |-

| -b, --boot || Show all log entries from the current boot. |-

| -r, --reverse || Show the newest log entries first (reverse chronological order). |-

| -f, --follow || Show the last few entries and display new log entries as they're being produced. This is similar to running tail -f in text logging utilities. |-

| -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). |-

| -S, --since=, -U, --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. |-

| --system || View system service and kernel logs. By default, this is only possible as the root user. See man journalctl for how to grant standard users the ability to read the system journal. |-

|}

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 del kernel 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 è impostata l'opzione del kernel 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 del kernel 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).

Usage

Converting traditional home directories to systemd homed

See the systemd-homed subarticle.

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.

Servizi preimpostati

La maggior parte dei servizi è disabilitato quando systemd è installato per la prima volta. Viene fornito un file "preimpostato" che può essere utilizzato per abilitare un insieme ragionevole di servizi predefiniti.

root #systemctl preset-all

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 Filesystems che fanno avviare dei servizi (avvio di un servizio quando un file cambia etc.).

| .service | Plain service files (e.g. ones just running a daemon directly). |-

| .socket | Socket listeners (much like inetd). |-

| .path | Filesystem triggers for services (running services when files change, 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 utilizzare:

root #systemctl start foo.service

Allo stesso modo, i servizi possono essere fermati:

root #systemctl stop foo.service

Services implementing ExecReload= can be commanded to reload their configuration without restarting itself:

root #systemctl reload 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

/lib/systemd/system è riservato ai file di servizio installati 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).

Both the drop-in directory and config file can be created using the systemctl edit utility or manually.

The editing utility can be invoked as:

root #systemctl edit apache2.service
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
Nota
{{{1}}}

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 /lib/systemd/system/mysqld.service /etc/systemd/system/multi-user.target.wants/db.service

Per disabilitare il servizio, si rimuova il collegamento simbolico:

root #unlink /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:

Service 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

! scope="col" | Gentoo package ! scope="col" | OpenRC service ! scope="col" | systemd unit ! scope="col" | Notes |-

! scope="row" rowspan="28" | sys-apps/openrc | bootmisc || systemd-tmpfiles-setup.service || always enabled, uses tmpfiles.d |-

| consolefont || systemd-vconsole-setup.service || always enabled, uses vconsole.conf |-

| devfs || || |-

| dmesg || || |-

| fsck || fsck*.service || pulled in implicitly by mounts |-

| functions.sh || See note || bug #373219 |-

| hostname || (builtin) || /etc/hostname |-

| hwclock || See note || always enabled as part of systemd (i.e. it is baked in and it is not a unit) |-

| keymaps || systemd-vconsole-setup.service || always enabled, uses vconsole.conf |-

| killprocs || || |-

| local || || |-

| localmount || local-fs.target || actual units are created implicitly from /etc/fstab |-

| modules || systemd-modules-load.service || always enabled, uses /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 || actual units are created implicitly from /etc/fstab |-

| swclock || || |-

| sysctl || systemd-sysctl.service || sysctl.conf and sysctl.d/ |-

| sysfs || (builtin) || |-

| termencoding || systemd-vconsole-setup.service || always enabled, uses vconsole.conf |-

| scope="row" rowspan="2" | urandom | systemd-random-seed-load.service || |-

| systemd-random-seed-save.service || |-

! scope="row" | app-admin/rsyslog | rsyslog || rsyslog.service || |-

! scope="row" | app-admin/syslog-ng | syslog-ng || syslog-ng.service || |-

! scope="row" rowspan="2" | media-sound/alsa-utils | scope="row" rowspan="2" | alsasound | alsa-store.service || (enabled by default) |-

| alsa-restore.socket || (enabled by default) |-

! scope="row" | net-misc/dhcpcd | dhcpcd || dhcpcd.service || |-

! scope="row" rowspan="5" | net-misc/netifrc | scope="row" rowspan="5" | net.* | net@.service || systemd wrapper for net.* scripts (comes with net-misc/netifrc) |-

| netctl@.service || net-misc/netctl is originally an Arch Linux tool. |-

| NetworkManager.service || For <networkmanager-0.9.8.4 : enable NetworkManager-dispatcher.service for dispatcher.d scripts to work.
Enable NetworkManager-wait-online.service to detect that the system has a working internet connection.
Disable all other managers (e.g., wicd, dhcpcd) and wpa_supplicant. |-

| dhcpcd.service || Provided by net-misc/dhcpcd |-

| systemd.networkd.service || Part of systemd |-

! scope="row" | net-misc/openntpd | ntpd || ntpd.service || |-

! scope="row" rowspan="2" | net-misc/openssh | scope="row" rowspan="2" | sshd | sshd.service || runs sshd as a daemon |-

| sshd.socket || runs sshd on a inetd-like basis (for each incoming connection) |-

! scope="row" rowspan="2" | net-wireless/wpa_supplicant | scope="row" rowspan="2" | wpa-supplicant | wpa_supplicant.service || D-Bus controlled daemon (e.g. for NetworkManager) |-

| wpa_supplicant@.service || interface-specific wpa_supplicant (used like wpa_supplicant@wlan0.service) |-

! scope="row" rowspan="3" | net-print/cups | scope="row" rowspan="3" | cupsd | cups.service || classic on-boot start up service |-

| cups.socket | scope="row" rowspan="2" | socket and path activation (cups only started on-demand) |-

| cups.path |-

! scope="row" | net-wireless/bluez | bluetooth || bluetooth.service || |-

! scope="row" rowspan="2" | sys-apps/dbus | scope="row" rowspan="2" | dbus | dbus.service || |-

| dbus.socket || |-

! scope="row" | sys-apps/irqbalance | irqbalance || irqbalance.service || supports daemon mode only |-

! scope="row" | sys-apps/microcode-ctl | microcode_ctl || || Configure microcode as a module to let it load the microcode itself. Go to "Processor type and features" -> "CPU microcode loading support" and remember to add the right option based on the system having an Intel or AMD processor. |-

! scope="row" rowspan="4" | sys-fs/udev | udev || udev.service || |-

| udev-mount || (builtin) || /dev is mounted as tmpfs |-

| udev-postmount || udev-trigger.service || |-

| || udev-settle.service || |-

! scope="row" | sys-power/acpid | acpid || acpid.service || Most of its functionality is done by systemd itself, so consider disabling this |-

! scope="row" | x11-apps/xdm | (xdm) || xdm.service || OpenRC uses common xdm init.d installed by x11-base/xorg-server. With systemd the corresponding unit file for each DM (gdm.service, kdm.service...) needs to be enabled. |-

! scope="row" rowspan="2" | net-firewall/iptables | scope="row" rowspan="2" | iptables | iptables-store.service || |-

| iptables-restore.service || |-

|}

Servizi per l'utente

È possibile gestire i servizi come un'istanza systemd per utente. Ciò consente agli utenti di impostare i propri servizi o timer.

Le unità utente possono essere ubicate in più posizioni. Gli utenti possono posizionarli su $XDG_CONFIG_HOME/systemd/user/. I pacchetti installati li mettono in /usr/lib/systemd/user/.

I servizi utente utilizzano l'opzione --user systemctl. Ad esempio per avviare un servizio utente mpd:

user $systemctl --user start mpd

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

These unit files can be created either manually or using the systemctl edit utility:

user $systemctl edit --force --full --user backup-work.timer

When creating the unit files manually, the files are to be placed in the ~/.config/systemd/user directory. It may need to be created for the relevant user:

user $mkdir -p ~/.config/systemd/user

To have a timer run while the user is not logged in, be sure to enable lingering sessions:

user $loginctl enable-linger <username>

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 /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

Slow shutdowns or reboot times due to running services

Problem
Occasionally a systemd system or user service will cause the system to greatly delay poweroff/shutdown or reboot operation due to systemd default wait times for the operation blocking service to time out.
Solution
To greatly speed up this operation, the default timeout values can be reduced at the expense of the service (potentially) not cleanly finishing a task. In order to be effective, both of the following configuration changes must be put into effect to shorten the default timeout system and user services.
FILE /etc/systemd/system.conf.d/system.confReduce default timeout to 10s for hanging system services
[Manager]
DefaultTimeoutStopSec=10s
FILE ~/.config/systemd/user.confReduce default timeout to 10s for hanging user services
[Manager]
DefaultTimeoutStopSec=10s

/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 [1]. 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à /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 /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.

! scope="col" width="15%" | Boot parameter ! scope="col" width="15%" | Supported options ! Description |-

| fsck.mode | auto
force
skip | Controls the mode of operation. The default is auto, and ensures that file system checks are done when the file system checker deems them necessary. force unconditionally results in full file system checks. skip skips any file system checks. |-

| fsck.repair | preen
yes
no | Controls the mode of operation. The default is preen, and will automatically repair problems that can be safely fixed. yes will answer yes to all questions by fsck and no will answer no to all questions. |-

|}

Binari di systemd opzionali

Many optional systemd binaries can be built by setting certain use flags. An incomplete mapping of USE flag to binary is below.

USE flag Additional binary built
curl /lib/systemd/systemd-journal-upload
http /lib/systemd/systemd-journal-gatewayd
/lib/systemd/systemd-journal-remote

Si veda anche

Risorse esterne

Riferimenti