Progetto

Generale

Profilo

Segnalazione #369

strano comportamento fuss-client

Aggiunto da Markus Pfeifer oltre un anno fa. Aggiornato circa un anno fa.

Stato:
Chiuso
Priorità:
Normale
Assegnato a:
Versione prevista:
-
Inizio:
02-08-2017
Scadenza:
% completato:

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 circa 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 circa 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 circa 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 circa un anno fa

  • Assegnato a modificata da Christopher R. Gabriel a Elena Grandi

#11 Aggiornato da Christopher R. Gabriel circa un anno fa

Lascio risposta ad Elena che conosce il problema molto meglio di me.

#12 Aggiornato da Elena Grandi circa 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 circa 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 circa 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.

Esporta su Atom PDF