systemd default.target broken link

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

systemd default.target broken link

Messaggioda ZeroUno » sab ago 17, 2019 22:48

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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
brg
Linux 2.x
Linux 2.x
Messaggi: 466
Iscritto il: sab mar 12, 2011 14:20
Slackware: 14.2
Kernel: 4.4.172
Desktop: KDE4
Località: Montecatini
Contatta:

Re: systemd default.target broken link

Messaggioda brg » dom ago 18, 2019 13:35

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.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: systemd default.target broken link

Messaggioda ZeroUno » dom ago 18, 2019 13:49

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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
brg
Linux 2.x
Linux 2.x
Messaggi: 466
Iscritto il: sab mar 12, 2011 14:20
Slackware: 14.2
Kernel: 4.4.172
Desktop: KDE4
Località: Montecatini
Contatta:

Re: systemd default.target broken link

Messaggioda brg » dom ago 18, 2019 19:57

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.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: systemd default.target broken link

Messaggioda ZeroUno » dom ago 18, 2019 21:52

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 :D (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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: systemd default.target broken link

Messaggioda ZeroUno » lun ago 19, 2019 8:11

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

grazie
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

Avatar utente
brg
Linux 2.x
Linux 2.x
Messaggi: 466
Iscritto il: sab mar 12, 2011 14:20
Slackware: 14.2
Kernel: 4.4.172
Desktop: KDE4
Località: Montecatini
Contatta:

Re: systemd default.target broken link

Messaggioda brg » mar ago 20, 2019 16:12

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

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: systemd default.target broken link

Messaggioda ZeroUno » mar ago 20, 2019 16:31

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 ;)
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111

hashbang
Packager
Packager
Messaggi: 1975
Iscritto il: ven giu 04, 2010 10:27
Nome Cognome: Luca De Pandis
Distribuzione: macOS Catalina
Località: Lecce / Bergamo / Milano
Contatta:

Re: systemd default.target broken link

Messaggioda hashbang » mar ago 20, 2019 16:56

ZeroUno ha scritto: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. #-o

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.

Avatar utente
ZeroUno
Staff
Staff
Messaggi: 5201
Iscritto il: ven giu 02, 2006 14:52
Nome Cognome: Matteo Rossini
Slackware: current
Kernel: slack-current
Desktop: ktown-latest
Distribuzione: 01000000-current
Località: Roma / Castelli
Contatta:

Re: systemd default.target broken link

Messaggioda ZeroUno » mar ago 20, 2019 18:08

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.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg

Codice: Seleziona tutto

1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111