In Imparare ad amare systemd , il primo articolo di questa serie, ho esaminato le funzioni e l'architettura di systemd e la controversia sul suo ruolo come sostituto del vecchio programma di inizializzazione SystemV e degli script di avvio. In questo secondo articolo inizierò ad esplorare i file e gli strumenti che gestiscono la sequenza di avvio di Linux. Spiegherò la sequenza di avvio di systemd, come modificare la destinazione di avvio predefinita (runlevel in termini di SystemV) e come passare manualmente a una destinazione diversa senza eseguire un riavvio.
Esaminerò anche due importanti strumenti di sistema. Il primo è il systemctl command, che è il mezzo principale per interagire e inviare comandi a systemd. Il secondo è journalctl , che fornisce l'accesso ai diari di sistema che contengono enormi quantità di dati della cronologia di sistema come kernel e messaggi di servizio (sia informativi che messaggi di errore).
Assicurati di utilizzare un sistema non di produzione per il test e la sperimentazione in questo articolo e in quelli futuri. Il tuo sistema di test deve avere un desktop GUI (come Xfce, LXDE, Gnome, KDE o un altro) installato.
Ho scritto nel mio precedente articolo che avevo in programma di creare un'unità systemd e aggiungerla alla sequenza di avvio in questo articolo. Poiché questo articolo è diventato più lungo del previsto, lo terrò per il prossimo articolo di questa serie.
Esplorazione dell'avvio di Linux con systemd
Altro sugli amministratori di sistema
- Abilita blog Sysadmin
- The Automated Enterprise:una guida alla gestione dell'IT con l'automazione
- eBook:Ansible Automation per SysAdmins
- Racconti dal campo:una guida per l'amministratore di sistema all'automazione IT
- eBook:una guida a Kubernetes per SRE e amministratori di sistema
- Ultimi articoli sull'amministratore di sistema
Prima di poter osservare la sequenza di avvio, è necessario eseguire un paio di operazioni per rendere aperte e visibili le sequenze di avvio e di avvio. Normalmente, la maggior parte delle distribuzioni utilizza un'animazione di avvio o una schermata iniziale per nascondere i messaggi dettagliati che altrimenti verrebbero visualizzati durante l'avvio e l'arresto di un host Linux. Questa è chiamata schermata di avvio di Plymouth nelle distribuzioni basate su Red Hat. Questi messaggi nascosti possono fornire una grande quantità di informazioni sull'avvio e l'arresto a un amministratore di sistema che cerca informazioni per risolvere un bug o semplicemente per conoscere la sequenza di avvio. Puoi modificarlo utilizzando la configurazione di GRUB (Grand Unified Boot Loader).
Il file di configurazione principale di GRUB è /boot/grub2/grub.cfg , ma, poiché questo file può essere sovrascritto quando viene aggiornata la versione del kernel, non si desidera modificarlo. Modifica invece /etc/default/grub file, che viene utilizzato per modificare le impostazioni predefinite di grub.cfg .
Inizia osservando la versione corrente e non modificata di /etc/default/grub file:
[root@testvm1 ~]# cd /etc/default ; cat grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
[root@testvm1 default]#
Il capitolo 6 della documentazione di GRUB contiene un elenco di tutte le possibili voci in /etc/default/grub file, ma mi concentro su quanto segue:
- Cambio GRUB_TIMEOUT , il numero di secondi per il conto alla rovescia del menu di GRUB, da cinque a 10, per concedere un po' più di tempo per rispondere al menu di GRUB prima che il conto alla rovescia raggiunga lo zero.
- Elimino gli ultimi due parametri su GRUB_CMDLINE_LINUX , che elenca i parametri della riga di comando che vengono passati al kernel all'avvio. Uno di questi parametri, rhgb sta per Red Hat Graphical Boot e mostra la piccola animazione dell'icona Fedora durante l'inizializzazione del kernel invece di mostrare i messaggi di avvio. L'altro, il tranquillo parametro, impedisce la visualizzazione dei messaggi di avvio che documentano lo stato di avanzamento dell'avvio e gli eventuali errori che si verificano. Elimino entrambi rhgb e silenzioso perché gli amministratori di sistema devono vedere questi messaggi. Se qualcosa va storto durante l'avvio, i messaggi visualizzati sullo schermo possono indicare la causa del problema.
Dopo aver apportato queste modifiche, il tuo file GRUB sarà simile a:
[root@testvm1 default]# cat grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr"
GRUB_DISABLE_RECOVERY="false"
[root@testvm1 default]#
Il grub2-mkconfig programma genera il grub.cfg file di configurazione utilizzando i contenuti di /etc/default/grub per modificare alcune delle impostazioni predefinite di GRUB. Il grub2-mkconfig il programma invia il suo output a STDOUT . Ha un -o opzione che ti consente di specificare un file a cui inviare il flusso di dati, ma è altrettanto facile da usare il reindirizzamento. Esegui il comando seguente per aggiornare /boot/grub2/grub.cfg file di configurazione:
[root@testvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.9-200.fc28.x86_64
Found initrd image: /boot/initramfs-4.18.9-200.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.17.14-202.fc28.x86_64
Found initrd image: /boot/initramfs-4.17.14-202.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.16.3-301.fc28.x86_64
Found initrd image: /boot/initramfs-4.16.3-301.fc28.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
Found initrd image: /boot/initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
done
[root@testvm1 grub2]#
Riavvia il tuo sistema di test per visualizzare i messaggi di avvio che altrimenti sarebbero nascosti dietro l'animazione di avvio di Plymouth. Ma cosa succede se hai bisogno di visualizzare i messaggi di avvio e non hai disabilitato l'animazione di avvio di Plymouth? Oppure sì, ma i messaggi scorrono troppo velocemente per essere letti? (Cosa fanno.)
Ci sono un paio di opzioni, ed entrambe coinvolgono file di registro e diari di sistema, che sono tuoi amici. Puoi utilizzare il meno comando per visualizzare il contenuto di /var/log/messages file. Questo file contiene messaggi di avvio e di avvio, nonché messaggi generati dal sistema operativo durante il normale funzionamento. Puoi anche utilizzare il journalctl comando senza alcuna opzione per visualizzare il diario di sistema, che contiene essenzialmente le stesse informazioni:
[root@testvm1 grub2]# journalctl
-- Logs begin at Sat 2020-01-11 21:48:08 EST, end at Fri 2020-04-03 08:54:30 EDT. --
Jan 11 21:48:08 f31vm.both.org kernel: Linux version 5.3.7-301.fc31.x86_64 ([email protected]) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Mon Oct >
Jan 11 21:48:08 f31vm.both.org kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.7-301.fc31.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/VG01-swap rd.lvm.lv=VG01/root rd>
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-provided physical RAM map:
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000100000000-0x000000041fffffff] usable
Jan 11 21:48:08 f31vm.both.org kernel: NX (Execute Disable) protection: active
Jan 11 21:48:08 f31vm.both.org kernel: SMBIOS 2.5 present.
Jan 11 21:48:08 f31vm.both.org kernel: DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jan 11 21:48:08 f31vm.both.org kernel: Hypervisor detected: KVM
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: cpu 0, msr 30ae01001, primary cpu clock
Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: using sched offset of 8250734066 cycles
Jan 11 21:48:08 f31vm.both.org kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Jan 11 21:48:08 f31vm.both.org kernel: tsc: Detected 2807.992 MHz processor
Jan 11 21:48:08 f31vm.both.org kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jan 11 21:48:08 f31vm.both.org kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
<snip>
Ho troncato questo flusso di dati perché può essere lungo centinaia di migliaia o addirittura milioni di righe. (L'elenco del diario sulla mia workstation principale è lungo 1.188.482 righe.) Assicurati di provare questo sul tuo sistema di test. Se è in esecuzione da un po' di tempo, anche se è stato riavviato molte volte, verranno visualizzate enormi quantità di dati. Esplora i dati di questo diario perché contiene molte informazioni che possono essere molto utili durante la determinazione dei problemi. Conoscere l'aspetto di questi dati per un normale avvio e avvio può aiutarti a individuare i problemi quando si verificano.
Parlerò dei giornali di sistema, il journalctl comando e come ordinare tutti quei dati per trovare ciò che desideri in modo più dettagliato in un futuro articolo di questa serie.
Dopo che GRUB ha caricato il kernel in memoria, deve prima estrarsi dalla versione compressa del file prima di poter eseguire qualsiasi lavoro utile. Dopo che il kernel si è estratto e ha iniziato a funzionare, carica systemd e gli passa il controllo.
Questa è la fine del processo di avvio. A questo punto, il kernel Linux e systemd sono in esecuzione ma non sono in grado di eseguire alcuna attività produttiva per l'utente finale perché nient'altro è in esecuzione, non c'è una shell per fornire una riga di comando, nessun processo in background per gestire la rete o altri collegamenti di comunicazione e nulla che consenta al computer di svolgere qualsiasi funzione produttiva.
Systemd ora può caricare le unità funzionali necessarie per portare il sistema a uno stato di esecuzione di destinazione selezionato.
Obiettivi
Una destinazione systemd rappresenta lo stato di esecuzione corrente o desiderato di un sistema Linux. Proprio come gli script di avvio di SystemV, le destinazioni definiscono i servizi che devono essere presenti affinché il sistema possa essere eseguito ed essere attivo in quello stato. La Figura 1 mostra le possibili destinazioni dello stato di esecuzione di un sistema Linux che utilizza systemd. Come visto nel primo articolo di questa serie e nella pagina man di systemd bootup (man bootup), ci sono altri target intermedi necessari per abilitare vari servizi necessari. Questi possono includere swap.target , timer.target , local-fs.target , e altro ancora. Alcuni target (come basic.target ) vengono utilizzati come punti di controllo per garantire che tutti i servizi richiesti siano attivi e funzionanti prima di passare all'obiettivo di livello superiore successivo.
Se non diversamente modificato all'avvio nel menu di GRUB, systemd avvia sempre default.target . Il target predefinito file è un collegamento simbolico al vero file di destinazione. Per una workstation desktop, questo sarà in genere il graphical.target , che equivale al runlevel 5 in SystemV. Per un server, è più probabile che l'impostazione predefinita sia multi-user.target , che è come il runlevel 3 in SystemV. Il obiettivo.emergenza il file è simile alla modalità utente singolo. Gli obiettivi ei servizi sono unità di sistema.
La tabella seguente, che ho incluso nell'articolo precedente di questa serie, confronta le destinazioni systemd con i vecchi runlevel di avvio di SystemV. Gli alias di destinazione systemd sono forniti da systemd per la compatibilità con le versioni precedenti. Gli alias di destinazione consentono agli script e agli amministratori di sistema di utilizzare comandi SystemV come init 3 per cambiare i runlevel. Naturalmente, i comandi SystemV vengono inoltrati a systemd per l'interpretazione e l'esecuzione.
| bersagli di sistema | Livello di esecuzione SystemV | alias di destinazione | Descrizione |
| default.target | Questo target è sempre alias con un collegamento simbolico a multi-user.target o obiettivo.grafico . systemd usa sempre default.target per avviare il sistema. Il target predefinito non dovrebbe mai essere alias di halt.target , poweroff.target o reboot.target . | ||
| obiettivo.grafico | 5 | runlevel5.target | Target.multiutente con una GUI |
| 4 | runlevel4.target | Non utilizzato. Il runlevel 4 era identico al runlevel 3 nel mondo SystemV. Questo target può essere creato e personalizzato per avviare i servizi locali senza modificare il multi-user.target predefinito . | |
| target multiutente | 3 | runlevel3.target | Tutti i servizi in esecuzione, ma solo l'interfaccia della riga di comando (CLI) |
| 2 | runlevel2.target | Multiutente, senza NFS, ma con tutti gli altri servizi non GUI in esecuzione | |
| rescue.target | 1 | runlevel1.target | Un sistema di base, incluso il montaggio dei filesystem con solo i servizi di base in esecuzione e una shell di ripristino sulla console principale |
| emergency.target | S | Modalità utente singolo:nessun servizio è in esecuzione; i filesystem non sono montati. Questo è il livello di funzionamento più elementare con solo una shell di emergenza in esecuzione sulla console principale per consentire all'utente di interagire con il sistema. | |
| halt.target | Arresta il sistema senza spegnerlo | ||
| reboot.target | 6 | runlevel6.target | Riavvia |
| poweroff.target | 0 | runlevel0.target | Arresta il sistema e spegne l'alimentazione |
Ogni destinazione ha una serie di dipendenze descritte nel suo file di configurazione. systemd avvia le dipendenze richieste, che sono i servizi richiesti per eseguire l'host Linux a un livello specifico di funzionalità. Quando tutte le dipendenze elencate nei file di configurazione di destinazione sono caricate e in esecuzione, il sistema è in esecuzione a quel livello di destinazione. Se lo desideri, puoi rivedere la sequenza di avvio di systemd e gli obiettivi di runtime nel primo articolo di questa serie, Imparare ad amare systemd .
Esplorazione dell'obiettivo attuale
Molte distribuzioni Linux per impostazione predefinita installano un'interfaccia desktop GUI in modo che i sistemi installati possano essere utilizzati come workstation. Installo sempre da un'unità USB di avvio Fedora Live con un desktop Xfce o LXDE. Anche quando installo un server o un altro tipo di infrastruttura di host (come quelli che utilizzo per router e firewall), utilizzo una di queste installazioni che installa un desktop GUI.
Potrei installare un server senza desktop (e sarebbe tipico per i data center), ma non soddisfa le mie esigenze. Non è che ho bisogno del desktop GUI stesso, ma l'installazione di LXDE include molti degli altri strumenti che uso che non si trovano in un'installazione del server predefinita. Questo significa meno lavoro per me dopo l'installazione iniziale.
Ma solo perché ho un desktop GUI non significa che abbia senso usarlo. Ho un KVM a 16 porte che posso utilizzare per accedere alle interfacce KVM della maggior parte dei miei sistemi Linux, ma la stragrande maggioranza della mia interazione con loro avviene tramite una connessione SSH remota dalla mia workstation principale. In questo modo è più sicuro e utilizza meno risorse di sistema per eseguire multi-user.target rispetto a graphical.target.
Per iniziare, controlla il target predefinito per verificare che sia il graphical.target :
[root@testvm1 ~]# systemctl get-default
graphical.target
[root@testvm1 ~]#
Ora verifica il target attualmente in esecuzione. Dovrebbe essere lo stesso del target predefinito. Puoi ancora usare il vecchio metodo, che mostra i vecchi runlevel di SystemV. Nota che il runlevel precedente è a sinistra; è N (che significa Nessuno), indicando che il runlevel non è cambiato da quando l'host è stato avviato. Il numero 5 indica il target attuale, come definito nella vecchia terminologia SystemV:
[root@testvm1 ~]# runlevel
N 5
[root@testvm1 ~]#
Nota che la pagina man del runlevel indica che i runlevel sono obsoleti e fornisce una tabella di conversione.
Puoi anche usare il metodo systemd. Non c'è una risposta su una riga qui, ma fornisce la risposta in termini di sistema:
[root@testvm1 ~]# systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network.target loaded active active Network
nfs-client.target loaded active active NFS client services
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File Systems (Pre)
remote-fs.target loaded active active Remote File Systems
rpc_pipefs.target loaded active active rpc_pipefs.target
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sshd-keygen.target loaded active active sshd-keygen.target
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Questo mostra tutti i target attualmente caricati e attivi. Puoi anche vedere il graphical.target e il target multiutente . Il target multiutente è richiesto prima di graphical.target può essere caricato. In questo esempio, graphical.target è attivo.
Passaggio a un target diverso
Passaggio a multi-user.target è facile:
[root@testvm1 ~]# systemctl isolate multi-user.targetIl display dovrebbe ora cambiare dal desktop della GUI o dalla schermata di accesso a una console virtuale. Accedi ed elenca le unità di sistema attualmente attive per verificare che graphical.target non è più in esecuzione:
[root@testvm1 ~]# systemctl list-units --type targetAssicurati di utilizzare il livello di esecuzione comando per verificare che mostri sia i "runlevel" precedenti che quelli attuali:
[root@testvm1 ~]# runlevel
5 3
Modifica del target predefinito
Ora, cambia il target predefinito in multi-user.target in modo che si avvii sempre nel multi-user.target per un'interfaccia della riga di comando della console piuttosto che un'interfaccia desktop GUI. Come utente root sul tuo host di prova, passa alla directory in cui viene mantenuta la configurazione di systemd ed esegui un rapido elenco:
[root@testvm1 ~]# cd /etc/systemd/system/ ; ll
drwxr-xr-x. 2 root root 4096 Apr 25 2018 basic.target.wants
<snip>
lrwxrwxrwx. 1 root root 36 Aug 13 16:23 default.target -> /lib/systemd/system/graphical.target
lrwxrwxrwx. 1 root root 39 Apr 25 2018 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 Apr 25 2018 getty.target.wants
drwxr-xr-x. 2 root root 4096 Aug 18 10:16 graphical.target.wants
drwxr-xr-x. 2 root root 4096 Apr 25 2018 local-fs.target.wants
drwxr-xr-x. 2 root root 4096 Oct 30 16:54 multi-user.target.wants
<snip>
[root@testvm1 system]#
Ho abbreviato questo elenco per evidenziare alcune cose importanti che aiuteranno a spiegare come systemd gestisce il processo di avvio. Dovresti essere in grado di vedere l'intero elenco di directory e collegamenti sulla tua macchina virtuale.
Il target predefinito entry è un collegamento simbolico (collegamento simbolico, collegamento software) alla directory /lib/systemd/system/graphical.target . Elenca quella directory per vedere cos'altro c'è:
[root@testvm1 system]# ll /lib/systemd/system/ | lessDovresti vedere file, directory e altri link in questo elenco, ma cerca in particolare multi-user.target e obiettivo.grafico . Ora mostra i contenuti di default.target , che è un collegamento a /lib/systemd/system/graphical.target :
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@testvm1 system]#
Questo link al graphical.target file descrive tutti i prerequisiti ei requisiti richiesti dall'interfaccia utente grafica. Esplorerò almeno alcune di queste opzioni nel prossimo articolo di questa serie.
Per consentire all'host di avviarsi in modalità multiutente, è necessario eliminare il collegamento esistente e crearne uno nuovo che punti alla destinazione corretta. Crea la PWD /etc/systemd/system , se non lo è già:
[root@testvm1 system]# rm -f default.target
[root@testvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target
Elenca il default.target link per verificare che si colleghi al file corretto:
[root@testvm1 system]# ll default.target
lrwxrwxrwx 1 root root 37 Nov 28 16:08 default.target -> /lib/systemd/system/multi-user.target
[root@testvm1 system]#
Se il tuo link non è esattamente così, eliminalo e riprova. Elenca il contenuto di default.target collegamento:
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[root@testvm1 system]#
Il target predefinito —che è in realtà un collegamento a multi-user.target a questo punto, ora ha requisiti diversi nella [Unità] sezione. Non richiede il display manager grafico.
Riavviare. La macchina virtuale dovrebbe avviarsi al login della console per la console virtuale 1, che è identificata sul display come tty1. Ora che sai come modificare il target predefinito, ripristinalo in graphical.target utilizzando un comando progettato per lo scopo.
Innanzitutto, controlla l'attuale target predefinito:
[root@testvm1 ~]# systemctl get-default
multi-user.target
[root@testvm1 ~]# systemctl set-default graphical.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
[root@testvm1 ~]#
Inserisci il seguente comando per andare direttamente a graphical.target e la pagina di accesso del display manager senza dover riavviare:
[root@testvm1 system]# systemctl isolate default.targetNon so perché gli sviluppatori di systemd hanno scelto il termine "isolate" per questo sottocomando. La mia ricerca indica che potrebbe riferirsi all'esecuzione del target specificato ma "isolando" e terminando tutti gli altri target che non sono necessari per supportare il target. Tuttavia, l'effetto è di cambiare i target da un target di esecuzione a un altro, in questo caso, dal target multiutente al target grafico. Il comando sopra è equivalente al vecchio comando init 5 negli script di avvio di SystemV e nel programma init.
Accedi al desktop della GUI e verifica che funzioni come dovrebbe.
Riassumendo
Questo articolo ha esplorato la sequenza di avvio di sistema Linux e ha iniziato a esplorare due importanti strumenti di sistema, systemctl e journalctl . Spiega anche come passare da una destinazione all'altra e come modificare la destinazione predefinita.
Il prossimo articolo di questa serie creerà una nuova unità systemd e la configurerà per l'esecuzione durante l'avvio. Esaminerà anche alcune delle opzioni di configurazione che aiutano a determinare dove nella sequenza verrà avviata una particolare unità, ad esempio, dopo che la rete è attiva e funzionante.
Risorse
Ci sono molte informazioni su systemd disponibili su Internet, ma molte sono concise, ottuse o addirittura fuorvianti. Oltre alle risorse menzionate in questo articolo, le seguenti pagine Web offrono informazioni più dettagliate e affidabili sull'avvio di systemd.
- Il progetto Fedora ha una buona guida pratica a systemd. Ha praticamente tutto ciò che devi sapere per configurare, gestire e mantenere un computer Fedora usando systemd.
- Il progetto Fedora ha anche un buon cheat sheet che incrocia i vecchi comandi SystemV con quelli di systemd comparabili.
- Per informazioni tecniche dettagliate su systemd e sui motivi della sua creazione, consulta la descrizione di systemd di Freedesktop.org.
- "Più divertimento di sistema" di Linux.com offre informazioni e suggerimenti più avanzati sul sistema.
C'è anche una serie di articoli profondamente tecnici per gli amministratori di sistema Linux di Lennart Poettering, il designer e sviluppatore principale di systemd. Questi articoli sono stati scritti tra aprile 2010 e settembre 2011, ma sono rilevanti ora come allora. Gran parte di tutto ciò che è stato scritto di buono su systemd e il suo ecosistema si basa su questi documenti.
- Ripensare il PID 1
- systemd per amministratori, parte I
- sistema per amministratori, parte II
- sistema per amministratori, parte III
- systemd per amministratori, parte IV
- sistema per amministratori, parte V
- sistema per amministratori, parte VI
- sistema per amministratori, parte VII
- systemd per amministratori, parte VIII
- systemd per amministratori, parte IX
- sistema per amministratori, parte X
- systemd per amministratori, parte XI