Project

General

Profile

Segnalazione #369

strano comportamento fuss-client

Added by Markus Pfeifer over 2 years ago. Updated about 2 years ago.

Status:
Chiuso
Priority:
Normale
Start date:
08/02/2017
Due date:
% Done:

0%


Description

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.

History

#1 Updated by Christopher R. Gabriel over 2 years ago

  • Project changed from octofuss-client to fuss-client
  • Assignee changed from Christopher R. Gabriel to Elena Grandi

#2 Updated by Elena Grandi over 2 years ago

  • Assignee changed from Elena Grandi to 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 Updated by Markus Pfeifer over 2 years ago

  • Assignee changed from Markus Pfeifer to 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 Updated by Elena Grandi over 2 years ago

  • Assignee changed from Elena Grandi to 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 Updated by Markus Pfeifer over 2 years ago

  • Assignee changed from Markus Pfeifer to 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 Updated by Christopher R. Gabriel over 2 years ago

  • Assignee changed from Elena Grandi to Markus Pfeifer

Ok, grazie Markus!

#7 Updated by Gianni Battista Lisci about 2 years ago

  • Assignee changed from Markus Pfeifer to 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 Updated by Christopher R. Gabriel about 2 years ago

  • Assignee changed from Christopher R. Gabriel to 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 Updated by Paolo Dongilli about 2 years ago

  • Assignee changed from Paolo Dongilli to 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 Updated by Christopher R. Gabriel about 2 years ago

  • Assignee changed from Christopher R. Gabriel to Elena Grandi

#11 Updated by Christopher R. Gabriel about 2 years ago

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

#12 Updated by Elena Grandi about 2 years ago

  • Assignee changed from Elena Grandi to 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 Updated by Paolo Dongilli about 2 years ago

  • Assignee changed from Paolo Dongilli to 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 Updated by Markus Pfeifer about 2 years ago

  • Status changed from Nuovo to 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.

Also available in: Atom PDF