# systemd (Italiano)/FAQ (Italiano)

From ArchWiki
< Systemd (Italiano)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Nota: Dalla versione 30 di systemd, solo una console sarà lanciata di default. Se si accede ad un'altra console una nuova istanza sarà lanciata (è lo stile socket-activation). Si può forzare l'avvio di console addizionali usando il metodo sopra.

### 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 g`getty@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?

This article or section is out of date.

Reason: see Systemd_FAQ#What_kernel_options_are_required_for_systemd.3F (Discuss in Talk:Systemd (Italiano)/FAQ (Italiano)#)

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.

Category:

- Init (Italiano)

Hidden category:

- Pages or sections flagged with Template:Out of date