Segnalazione #369
strano comportamento fuss-client
0%
Descrizione
Buonasera,
ieri durante l'installazione di una delle scuola pilota a Merano ho riscontrato uno strano comportamento di fuss-client durante l'agganciamento al dominio di due client.
Eseguendo il commando fuss-client -a -g <aula123> il processo termina con l'interruzione dell'agganciamento con una serie di messaggi d'errore però senza sommario finale.
I due PC possedevano und CD/DVD-ROM guasto. Ho notato che all'esecuzione del commando di agganciamento il processo ha iniziato a fare dei tentativi di accesso al CD/DVD-ROM che inizava a fare il spin-up e stop del motorino che fà girare i CD/DVD per un certo tempo. Alla fine il motorino si ferma e subito dopo termina anche il processo di agganciamento nella maniera descritta.
Rimovendo le spine di alimentazione delle due CD/DVD-ROM guasti e rilanciando il commando di agganciamento l'operazione è andata a buon fine senza errori e mostrando anche il sommario pulito con tutti processi eseguiti con successo.
Non mi sembra neccessario che fuss-client faccia delle verifiche sull'hardware soporattutto su componenti che non influiscono la communicazione sulla rete o le funzionalità del sistema operativo.
Saluti
Markus.
Cronologia
#1
Aggiornato da Christopher R. Gabriel oltre un anno fa
- Progetto modificata da octofuss-client a Fuss Client
- Assegnato a modificata da Christopher R. Gabriel a Elena Grandi
#2
Aggiornato da Elena Grandi oltre un anno fa
- Assegnato a modificata da Elena Grandi a Markus Pfeifer
Sarebbe utile sapere quali siano i messaggi di errore citati, idealmente con un typescript completo (come spiegato su Bug_Reporting)
Basandomi su quanto scritto fin'ora:
fuss-client -a
non fa (esplicitamente) verifiche sull'hardware: fa delle richieste via rete verso il server, e al massimo delle richieste verso i repository per scaricare pacchetti da installare (che però su fuss-client dovrebbero essere già installati).
Nel caso fallisca l'agganciamento al server con richiesta password effettivamente fuss-client si interrompe senza dare il messagio di riepilogo finale, ma a quel punto ha solo contattato il server per ottenere alcuni dati e per fare l'agganciamento, scrivendo localmente nella directory /root
, che non dovrebbe coinvolgere il lettore cdrom in alcun modo.
Il primo punto in cui mi viene in mente qualcosa che potrebbe leggere dal cdrom è successivo, quando vengono letti i repository dei pacchetti: questo però avviene dopo che sono iniziati i messaggi colorati, e quindi dovrebbe esserci un messaggio di riepilogo finale.
Questo caso potrebbe avvenire nel caso in cui dopo l'installazione siano rimasti abilitati in /etc/apt/sources.list
i riferimenti al disco di installazione: questo mi stupisce, dato che mi risulta vengano disabilitati automaticamente, ma potrebbero essere stati riabilitati per qualche motivo, e spiegherebbero l'avvenuto tentativo (fallito) di lettura dal cdrom.
Per poterne sapere di più però, come scritto sopra, serve necessariamente il log completo dell'esecuzione.
#3
Aggiornato da Markus Pfeifer oltre un anno fa
- Assegnato a modificata da Markus Pfeifer a Elena Grandi
Mi dispiace ma a ripordurre questo errore dovrei tornare in quella scuola sganciare il PC dal dominio ripristinare il hardware staccato e rifare la procedura. In sostanza il comportamento è quello che fuss-client -a -g <cluster> parte con la conferma della chiave ssh 3 volte la richiesta della password di root/sudoers del server per l'agganciamento ... Dopo di che iniza a fare delle manovre sul CD/DVD-ROM per mezzo minuto e poi secondo mè fuss-client va in timeout e butta fuori una serie di errori ...
#4
Aggiornato da Elena Grandi oltre un anno fa
- Assegnato a modificata da Elena Grandi a Markus Pfeifer
Il problema è che ad andare in timeout probabilmente non è fuss-client ma uno dei tanti programmi che fuss-client lancia internamente per svolgere i suoi compiti.
Senza avere un log completo di quando il problema succede e con quali errori è impossibile scoprire di quale dei programmi si tratti e quindi non c'è modo di intervenire per aiutare fuss-client a prevenire la situazione.
Con le informazioni attuali io non posso fare altro che proporre di chiudere il bug in quanto non riproducibile, e semmai lo si può riaprire / aprirne un altro nel caso in cui succeda ancora e ci sia un typescript dell'esecuzione su cui lavorare.
#5
Aggiornato da Markus Pfeifer oltre un anno fa
- Assegnato a modificata da Markus Pfeifer a Elena Grandi
Vista la neccessità del log completo appena rientro dalle ferie dopo il 20 agosto andrò alla scuola nella quale ho riscontrato l'errore descritto e cerco di riprodurlo. Quindi sospendiamo intanto il ticket e lo aggiorno quando ho disponibile l'esito delle prove che farò.
#6
Aggiornato da Christopher R. Gabriel oltre un anno fa
- Assegnato a modificata da Elena Grandi a Markus Pfeifer
Ok, grazie Markus!
#7
Aggiornato da Gianni Battista Lisci oltre un anno fa
- Assegnato a modificata da Markus Pfeifer a Christopher R. Gabriel
Buonasera!
non serve log :D
ho installato l'aula a vipiteno e tutti i pc con drive cdrom/dvd difettosi davano questo errore:
TASK [setup] ***********************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: TimeoutError: Timer expired
fatal: [localhost]: FAILED! => {"changed": false, "cmd": "/bin/lsblk --list --noheadings --paths --output NAME,UUID --exclude 2", "failed": true, "msg": "Timer expired", "rc": 257}
to retry, use: --limit @/usr/share/fuss-client/connect.retry
da root manualmente il comando:
/bin/lsblk --list --noheadings --paths --output NAME,UUID --exclude 2
dava solo questo output:
/dev/sda
/dev/sda1 9ce3a25c-d9e5-4a15-a76d-958987171f56
/dev/sda2 82231d1a-753e-440f-8ad1-3d03143ffae6
/dev/sr0
pure usando lo switch -t di fuss-client settato a 100000 dava sempre timeout(col drive cdrom/dvd che cmq faceva rumori)
l'unica soluzione al momento è aprire i pc(appena visto battlestar galactica e mi ricorda sharon/boomer che si infila la fibra ottica nel polso) e staccare il drive cdrom/dvd che in alcune aule è un'impresa. tipo a vipiteno i pc sono appesi sotto al tavolo con una cinghia XD
saluti
Gianni
#8
Aggiornato da Christopher R. Gabriel oltre un anno fa
- Assegnato a modificata da Christopher R. Gabriel a Paolo Dongilli
Riassegno a Paolo, dopo discussione di oggi sull'argomento.
Il problema e' legato ad ansible, non tanto a fuss-client, che fa la collects dei facts della macchina prima di procedere.
#9
Aggiornato da Paolo Dongilli oltre un anno fa
- Assegnato a modificata da Paolo Dongilli a Christopher R. Gabriel
Puoi intervenire sulla collect dei facts di ansible?
Anche se rimango dell'idea che sarebbe meglio intervenire sull'hardware fuori uso (piuttosto levandolo) ed evitando che n utenti provino ad utilizzarlo lamentandosi del malfunzionamento.
#10
Aggiornato da Christopher R. Gabriel oltre un anno fa
- Assegnato a modificata da Christopher R. Gabriel a Elena Grandi
#11
Aggiornato da Christopher R. Gabriel oltre un anno fa
Lascio risposta ad Elena che conosce il problema molto meglio di me.
#12
Aggiornato da Elena Grandi oltre un anno fa
- Assegnato a modificata da Elena Grandi a Paolo Dongilli
Innanzitutto, noi usiamo alcuni dei facts durante la configurazione, per cui non possiamo semplicemente disattivare la loro raccolta.
È possibile disattivare la raccolta di una parte dei facts, ma in modo poco granulare, per cui non si può semplicemente dire di ignorare i cdrom, ma bisogna escludere tutti i fatti relativi all'hardware (e poi reinserire quelli relativi alla rete, che sicuramente ci servono: mi segno qui che il valore giusto di gather_subset
per farlo sembra essere '!hardware,network'
— da mettere nell'ansible.cfg
).
Prima di farlo bisogna però controllare con cura che non si stia usando nessun fact della categoria "hardware", in nessuna delle modalità di funzionamento del fuss-client.
Però è un po' un hack per coprire il caso specifico dei cdrom che non funzionano, e anche secondo me la soluzione di togliere l'hardware che non va per evitare che poi gli utenti cerchino di usarlo è molto più pulita.
#13
Aggiornato da Paolo Dongilli oltre un anno fa
- Assegnato a modificata da Paolo Dongilli a Markus Pfeifer
Come dicevo, se ci sono componenti hw guasti, o si disattivano/levano o si sostituiscono.
Non è il primo caso che mi capita: hai una macchina non nuova (e per la quale sorge il dubbio che tutto l'hardware sia funzionante) per la quale non vuoi fare un memtest e poi, a macchina installata, ti chiedi come mai il sistema vada in crash in modo non deterministico.
#14
Aggiornato da Markus Pfeifer oltre un anno fa
- Stato modificata da Nuovo a Chiuso
Chiudiamo il discorso che mi sembra non porta alla soluzione del problema indicato ... A me sembra più un bug che un Feature.
Acetto gli argomenti e la decisione in merito a questo discorso e cerco di arrangiarmi.
Saluti
Markus.