systemd (Italiano)/FAQ (Italiano)
FAQ
Per una lista aggiornata dei problemi conosciuti, vedere il TODO.
Perché non ricevo messaggi di log sulla console?
Si deve configurare il proprio livello di log. Un tempo, /etc/rc.sysinit lo faceva e configurava il livello di log di dmesg a 3, che era un ragionevole livello. Ora aggiungere loglevel=3 o quiet ai parametri del kernel.
Come posso cambiare il numero di console funzionanti di default?
Per aggiungere un'altra console, semplicemente creare un altro collegamento per ottenere un'altra console nella cartella /etc/systemd/system/getty.target.wants/ :
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service # systemctl start getty@tty9.service
Per rimuovere una console, semplicemente rimuovere il collegamento alla console nella cartella /etc/systemd/system/getty.target.wants/ :
# rm /etc/systemd/system/getty.target.wants/getty@{tty5,tty6}.service
# systemctl stop getty@tty5.service getty@tty6.service
Gli utenti possono cambiare il numero delle console anche editando /etc/systemd/logind.conf e cambiando il valore di NAutoVTs. Seguendo questo metodo, l'attivazione al bisogno sarà preservata, mentre con il metodo iniziale semplicemente si avranno le console funzionanti al boot.
systemd non usa il file /etc/inittab.
Come posso ottenere un output più dettagliato durante l'avvio?
Se non si ottiene nessun output dalla console dopo i messaggi di caricamento dell'initram, significa che il parametro quiet è presente nella linea di comando del kernel. E' meglio rimuoverlo, almeno per i primi avvii con systemd, per vedere se tutto è ok. Poi, si potrà vedere una lista di [ OK ] in verde o [ FAILED ] in rosso.
Tutti i messaggi sono registrati nel log di sistema e se si vuole scoprire lo stato del proprio sistema usare $ systemctl (non sono necessari privilegi di root) oppure guardare il log di avvio con journalctl.
Come evitare che la console sia pulita dopo l'avvio?
Creare un file ggetty@tty1.service personalizzato copiando /usr/lib/systemd/system/getty@.service in /etc/systemd/system/getty@tty1.service e cambiando TTYVTDisallocate in no. e si permette l'esportazione di LANG in /etc/locale.conf
Quali opzioni del kernel occorrono attive nel mio kernel nel caso non usassi il kernel Arch ufficiale?
I Kernels precedenti al 2.6.39 non sono supportati.
Questa è una lista parziale delle opzioni richieste/raccomandate, ce ne possono essere ulteriori:
General setup
CONFIG_FHANDLE=y
CONFIG_AUDIT=y (raccomandata)
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (non raccomandata, può danneggiare la compatibilità con sysvinit)
CONFIG_CGROUPS=y
-> Namespaces support
CONFIG_NET_NS=y (per reti private)
Networking support -> Networking options
CONFIG_IPV6=[y|m] (altamente raccomandata)
Device Drivers
-> Generic Driver Options
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y (richiesta se non si usa un initramfs)
-> Real Time Clock
CONFIG_RTC_DRV_CMOS=y (altamente raccomandata)
File systems
CONFIG_FANOTIFY=y (richiesta per readahead)
CONFIG_AUTOFS4_FS=[y|m]
-> Pseudo filesystems
CONFIG_TMPFS_POSIX_ACL=y (raccomandata se si vuole usare pam_systemd.so)
Quali altre unità dipendono da una unità?
Per esempio, se si vuole evidenziare quali servizi e target attiva multi-user.target, si usi qualcosa del genere:
$ systemctl show -p "Wants" multi-user.target
Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service org.cups.cupsd.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service
Invece di Wants si può provare WantedBy, Requires, RequiredBy, Conflicts, ConflictedBy, Before, After per i rispettivi tipi di dipendenza e il loro contrario.
Il mio computer si spegne, ma l'alimentatore resta acceso.
Usare
$ systemctl poweroff
invece di systemctl halt.
Dopo la migrazione a systemd, perché non riesco a montare fakeRAID?
Assicurarsi di usare
# systemctl enable dmraid.service
Come posso fare in modo che uno script sia eseguito al boot?
Creare un nuovo file in /etc/systemd/system (e.g. "myscript".service) e aggiungere il seguente contenuto:
[Unit] Description=My script
[Service] ExecStart=/usr/bin/my-script
[Install] WantedBy=multi-user.target
Poi
# systemctl enable "myscript".service
Questo esempio presuppone che si voglia avviare lo script quando il target multi-user sarà lanciato. Nota: Nel caso si voglia avviare uno script di schell, assicurarsi di avere
#!/bin/sh
nella prima riga dello script. Non scrivere qualcosa come
ExecStart=/bin/sh /path/to/script.sh # NON FUNZIONA
perché non funziona.
Lo stato del .service dice "active (exited)" in verde. (per iptables)
Ciò è perfettamente normale. Nel caso specifico di iptables è perché non c'è nessun demone da avviare, è controllato dal kernel. Tuttavia esiste dopo che le regole sono state caricate. Per verificare se le regole di iptables sono state caricate correttamente:
# iptables --list
Failed to issue method call: File exists error
Questo accade quando si usa systemctl enable e si tenta di creare il link simbolico in /etc/systemd/system/ ed esiste già. Di solito accade quando si passa da un display manager ad un altro (per esempio da GDM a KDM, che possono essere abilitati con gdm.service e kdm.service, rispettivamente) e il link simbolico corrispondente /etc/systemd/system/display-manager.service esiste già.
Per risolvere il problema usare systemctl -f enable per sovrascrivere link simbolici già esistenti.