systemd default.target broken link

[ZeroUno]

Non so se quì c'è qualcuno che ama systemd, ma io al lavoro ho centinaia di macchine virtuali redhat 7 con quindi systemd.

Oggi una macchina non mi partiva.

Dopo un mare di tentativi di ottenere la shell che vi risparmio sono riuscito ad andare in maintenance mode.

Da quello che sono riuscito a ricostruire dalla history e dal confronto con altre macchine funzionanti, qualcuno che girava per le directory di systemd ha notato

Codice: Seleziona tutto

# ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 37 Aug 17 17:20 /etc/systemd/system/default.target -> /etc/systemd/system/multi-user.target
# ls -l /etc/systemd/system/multi-user.target
ls: cannot access /etc/systemd/system/multi-user.target: No such file or directory

quindi un file di sistema broken link.
Malauguratamente ha visto che nella stessa directory c'è anche multi-user.target.wants così ha pensato di correggere il problema sistemando il link.
Ovviamente la macchina non faceva più il boot.

Devo dire che in effetti la caseistica è abbastanza fuorviante e ci sarei cascato probabilmente pure io (ma prima di toccare una cosa simile avrei almeno confrontato con le altre centinaia di macchine) e se non ci fosse stata la history di root non l'avrei mai trovato anche perchè i log non dicevano niente.


Ma è normale secondo voi che il default target level sia identificato da un broken link?


Altro motivo in più per odiare systemd.

[brg]

Ma infatti non mi sembra normale. Probabilmente si pianta perché multi-user.target.wants è una directory e non è quello che si aspetta. Sul mio server domestico c'è una distribuzione basata su Debian ed i file target non sono in /etc, ma solo le directory target.wants. I file target dovrebbero essere in /lib/systemd/system e lì di sicuro non devono essere vuoti.

[ZeroUno]

Ok che non funziona perché il link era ad una directory, ma quello che non si capisce è perché FUNZIONA correttamente se è un link a multi-user.target che è inesistente. Non ha senso.

[brg]

Meglio che continui a girare, piuttosto che si pianti. Si tratta di un target piuttosto scarno, che non ha dipendenze particolari: probabilmente parte in multi-user perché non può partire in graphical, che ha più dipendenze. O qualcosa del genere, nei log ci dovrebbe essere scritto.

[ZeroUno]

Bene.
Mi hai appena tirato fuori un bug megagalattico della piattaforma.

Le macchine vengono create con immagini prefatte. Ogni tanto le immagini vengono aggiornate, fixate ecc.
Una macchina creata con template fatto nel 2015
lrwxrwxrwx. 1 root root 37 Nov 12 2015 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

Nel 2018 è stata fatta una grossa rivisitata dell'immagine
lrwxrwxrwx. 1 root root 37 Mar 20 2018 /etc/systemd/system/default.target -> /etc/systemd/system/multi-user.target

Comunque systemctl get-default su entrambe tira fuori multi-user.target

systemctl set-default multi-user.target
setta
lrwxrwxrwx 1 root root 41 Aug 18 21:03 /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target

/lib è un link a /usr/lib


c'è da aspettarsi che quando default.target in etc è un broken link faccia fallback a quello che è in lib.
lrwxrwxrwx. 1 root root 16 Apr 10 02:19 /usr/lib/systemd/system/default.target -> graphical.target

questo non può partire perchè manca la dipendenza display-manager.service definita in graphical.target e quindi si ferma a multi-user.target che viene immediatamente prima.


Quando il link di etc puntava male ad una directory invece dava un errore che non trovava plymouth, che se non erro viene caricato a runlevel grafico.


Quelle con immagine vecchia che stanno bene hanno un uptime troppo alto e i log hanno rotato quindi non so come sono partiti, se con multi-user come dice il link in etc o come graphical come dice il link in lib.
Per quelle vecchie systemctl|grep target non mostra per niente graphical (ma il lib c'è)
Per quelle nuove vengono mostrati tutti i target in "loaded active active" incluso graphical.target

Ho appena provato su una di collaudo non in uso a sistemare con "systemctl set-default multi-user.target"
curiosamente non è ancora risalita (di solito il boot è rapido e non ho la console in questo momento)


Al momento la via ufficiale è avere il broken link in etc
poi vediamo di sistemare.

[ZeroUno]

ok. ha impiegato un po' più di tempo rispetto a quello che mi aspettavo ma è partito e senza il graphical.target active.

grazie

[brg]

Se non ci fossero questi subdoli bachi a ravvivare le giornate, che gusto ci sarebbe a fare il sistemista?

[ZeroUno]

Quando mi chiedono che lavoro fai io dico sistemista, ma poi alla domanda "Cioè?" - visto che non tutti conoscono la parola - la mia risposta è "Quello che sfascia i computer"... eh si, perchè se tutto funziona mi licenziano perchè mi giro i pollici

[hashbang]

Non so se quì c'è qualcuno che ama systemd, ma io al lavoro ho centinaia di macchine virtuali redhat 7 con quindi systemd.

Oggi una macchina non mi partiva.

Dopo un mare di tentativi di ottenere la shell che vi risparmio sono riuscito ad andare in maintenance mode.

Codice: Seleziona tutto

systemd.unit=emergency.target

al boot o

Codice: Seleziona tutto

rd.break

sempre al boot non andavano? Anche se il secondo ti porta nel ramdisk nel momento subito prima dello switch_root.

Da quello che sono riuscito a ricostruire dalla history e dal confronto con altre macchine funzionanti, qualcuno che girava per le directory di systemd ha notato

Codice: Seleziona tutto

# ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 37 Aug 17 17:20 /etc/systemd/system/default.target -> /etc/systemd/system/multi-user.target
# ls -l /etc/systemd/system/multi-user.target
ls: cannot access /etc/systemd/system/multi-user.target: No such file or directory

quindi un file di sistema broken link.

E già questo mi insospettisce. Chi ha cambiato il link ad un target? Per standard le unit installate sono in /usr/lib/systemd/system, mentre in /etc/systemd/system ci sono quelle abilitate, quelle create custom ed i drop-in. Difficile che l'abbia fatto systemd visto che ha dei path hardcoded e ha settato quello standard praticamente da sempre.

Malauguratamente ha visto che nella stessa directory c'è anche multi-user.target.wants così ha pensato di correggere il problema sistemando il link.
Ovviamente la macchina non faceva più il boot.

multi-user.target.wants è la directory in cui vengono inserite le unit richieste dal target, ovvero quelle che hanno un WantedBy nella sezione [Install].
Il fatto che non sia partito dopo aver fatto un symlink di default.target a quella directory è del tutto corretto.

Ma è normale secondo voi che il default target level sia identificato da un broken link?

No.

Altro motivo in più per odiare systemd.

Qui per me systemd c'entra poco, visto che a quanto ho capito il sistema parte comunque pur avendo default.target come broken link.
E questa situazione a mio avviso sembra più un errore umano. Tipo che qualcuno ha cancellato default.target per sbaglio, e, non sapendo che con un set-default systemd avrebbe sistemato tutto da solo, ha fatto un symlink a mano.

Ok che non funziona perché il link era ad una directory, ma quello che non si capisce è perché FUNZIONA correttamente se è un link a multi-user.target che è inesistente. Non ha senso.

Credo che il motivo sia che systemd lanci la unit splittandone il filename dal path e la vada cercare nei suoi percorsi (spulciando il sorgente c'è un path-lookup.c che ha i path hardcoded) e non in quelli a cui punta il file.
Essendo quindi che /etc/systemd/system/multi-user.target non esiste, la trova in /usr/lib/systemd/system e quindi la lancia correttamente. Non so se è un bug o un comportamento voluto (credo più la seconda ipotesi, onestamente). Per queste cose occorrerebbe aprire un case a Red Hat e capire con il supporto.

Le macchine vengono create con immagini prefatte. Ogni tanto le immagini vengono aggiornate, fixate ecc.

Motivo per il quale da sempre consiglio ai clienti in cui vado per progetti inerenti automazione lato provisioning di VM di fare sempre boot da PXE tramite Satellite, che prevede già template di configurazioni da trasformare in file di kickstart per anaconda. Almeno si ha sempre la certezza di avere macchine "fresche" e non copia-incolla di qualcosa di esistente.
I template VM li ho sempre trovati un metodo che col tempo si trasforma in un porcile e che diventano difficili da manutenere.
Il problema è che la maggior parte dei clienti pensa che Satellite serva giusto per fare il patching.

ok. ha impiegato un po' più di tempo rispetto a quello che mi aspettavo ma è partito e senza il graphical.target active.

Dai un

Codice: Seleziona tutto

# systemd-analyze blame

e controlla chi ha rallentato il boot.

[ZeroUno]

Più o meno è quello a cui mi riferivo con

Dopo un mare di tentativi di ottenere la shell che vi risparmio sono riuscito ad andare in maintenance mode

Provo a ricostruire la cronistoria.
- conosco veramente poco systemd ed ero ancora abituato a init=/bin/bash
- la macchina è una macchina virtuale su architettura openstack per cui aprire la console è un incubo che passa per la dashboard in http di openstack
- la macchina con boot senza aggiunta caricava il kernel e ad un certo punto sembrava fermarsi, con un messaggio ogni tanto (quindi no panic)
- durante il boot partiva il caricamento del driver drm che fondamentalmente cancella tutta la history precedente
- init=/bin/bash mandava in kernel panic (attempt to kill init)
- rd.break dava quasi lo stesso effetto del boot normale
- idem systemd.unit=emergency.target
Il mondo si è schiarito quando
- aggiunto nomodeset per non cancellare la history e vedere di capire dove si fermava
- scoperto che sulla riga c'era sia console=tty1 che console=ttyS0 (di solito viene messo per avere una console senza bisogno di una gui, ma in questo momento non l'abbiamo ancora attivata la feature
A questo punto lasciato solo tty1 ho la visione più aperta
- scopro che il boot andava avanti ma si fermava in maintenance mode in attesa di password di root, come quando si ferma perché vuole un fsck.
- giro un po' vanamente, perché ovviamente non era fsck il problema.
- journalctl -xb non mostrava nulla che potesse fare arrivare al problema
- dato una 'history' e vista qualche mail precedente e confrontato con le macchine gemelle, si scopre l'arcano.
In pratica un collega (che volevo mangiarmi) stava lavorando per un servizio che non partiva al boot, quindi vedeva systemd che evidentemente non conosce a sufficienza (ma chi lo conosce? la differenza è che una cosa che non si conosce non si tocca) ha visto il broken link e l'ha settato al più simile :O, ovvero multi-user.target.wants
Pensando fosse quello il problema ha riavviato per vedere se ora il servizio partiva. E non è più salita la macchina.
In mia assenza hanno pensato di distruggere e ricreare la macchina (la concezione del cloud). Fortuna ho letto la mail e li ho fermati.

Il motivo del broken link è da cercare nell'aggiornamento delle immagini; evidentemente chi l'ha fatto ha fatto un errore di copia incolla o di definizione del playbook di ansible che usiamo per tuning e installazioni.

Interessante l'analize. per quell'host dice

2min 15.752s kdump.service

Gli altri ora non posso postarli, ma il più lungo è sotto i 5 secondi.