Supporto di secondo livello per DGAS

La seguente pagina contiene appunti su problemi relativi a DGAS. Per ogni caso e' riportato il tipo di problema, quando e dove si' e verificato e cosa e' stato fatto per risolverlo. Se presente, e' riportato anche il link al ticket con il quale il problema e' stato seguito. Lo scopo e' quello di tenere traccia dei problemi riscontrati e mantenere un unico posto per trovare la loro storia.

urForward muore continuamente

Descrizione

Il processo urForward e' a volte running a volte no. Lanciando infatti il comando /etc/init.d/glite-dgas-hlrd status si ha a volte:
...
generic: error trying to contact the server.
listener seems'to be frozen
/opt/glite/var/lock/dgas_hlr_urforward.lock
Process urForward: 31256
root 31256 0.8 0.4 29508 4468 pts/0 Sl 16:52 0:00 /opt/glite//libexec/glite-dgas-hlr-urforward -c /opt/glite//etc/dgas_hlr.conf -d
The process is running.

A volte invece:
...
Process urForward:
The process is not running.

Dove e quando si e' verificato e ticket di riferimento

INFN-FRASCATI - Aprile 2011
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=10238
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=10340

Approccio

Avendo fatto girare gli script di check su CE e HLR, ci siamo accorti che i CE mandano correttamente i dati all'HLR e l'HLR li riceveva bene, ma questi non sono presenti nella jobTransSummary. Allora pensiamo che i dati siano presenti nella trans_queue ma non vengono trasferiti nella jobTransSummary. Facciamo eseguire il comando /opt/glite/sbin/glite-dgas-hlr-translatedb ed infatti il risultato e':
Another instance of hlr-translatedb put a lock. Exiting.

Soluzione

Facciamo cercare il file di lock del translatedb (che non e' configurabile ma scritto hardcoded) e lo facciamo cancellare. Il translatedb e' partito e i dati sono arrivati.

ATTENZIONE: il problema si e' ripresentato e al momento e' seguito nel tkt 10340.

riprocessamento di log gia' processati in passato

Descrizione

Dai log del CE sembra che il pushd provi a mandare all'HLR record gia' mandati in passato, in quanto gia' presenti sull' HLR, come indica l'existatus=70. Puo' essere che per qualche motivo sia stato cancellato il file /opt/glite/var/dgasCollectorBuffer che contiene il timestamp prima del quale il sistema non processa i job.

Dove e quando si e' verificato e ticket di riferimento

INFN-PERUGIA - Aprile 2011
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=10271

Approccio

Sembra che il sistema stia riprocessando tutti i log indietro nel tempo. Dovrebbe arrivare alla data indicata come ignoreJobsLoggedBefore nel file dgas_sensors.conf e poi cominciare a processare log recenti.

Soluzione

Aspettare che il giro finisca, senza riavviare l'urlcollector, e vedere se i log nuovi vengono processati. Quando arrivano i dati recenti all'HLR, verificare che le cartelle dgasURBox e dgasURBox/ERR si siano svuotate.

record che rimangono indietro e frequenti errori di connessione all'hlr di secondo livello nel log di urForward

Descrizione

Il log dell'urforward sull'HLR di primo livello segnala alcuni errori del tipo:

LOG (5) 2011 May 04 09:59:55 : Entering contactServer()
LOG (3) 2011 May 04 09:59:55 : 2lw-hlr.to.infn.it:56568:
LOG (3) 2011 May 04 10:00:20 : Got error sending XML!
LOG (3) 2011 May 04 10:00:20 : Error sending UR to:2lw-hlr.to.infn.it
LOG (4) 2011 May 04 10:00:20 : run(),Contacting server:hlr2-test-26.to.infn.it
LOG (3) 2011 May 04 10:00:20 : Entering getInfo()
LOG (6) 2011 May 04 10:00:20 : Performing query:select max(id) FROM jobTransSummary
LOG (5) 2011 May 04 10:00:20 : Entering contactServer()
LOG (3) 2011 May 04 10:00:20 : hlr2-test-26.to.infn.it:56568:
LOG (3) 2011 May 04 10:03:29 : getInfo():error contacting server.
LOG (3) 2011 May 04 10:03:29 : Error retrieving info from 2LHLR:hlr2-test-26.to.infn.it

Dove e quando si e' verificato e ticket di riferimento

INFN-ROMA1 - Maggio 2011
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=10366

Approccio

La causa e' il crash pariodico (3/4 volte al giorno) dei servizi dgas sull'hlr di secondo livello, imputabile al bug 55062 di mysql. Non esistono per il momento gli rpm per scientific 5 della versione 5.6 di mysql che fissa il bug.

Soluzione

Nel file /opt/glite/etc/dgas_hlr.conf sull'HLR portare il valore di forwardPeriod a 1800 e defConnTimeOut a 600. Se quest'ultima non esiste, crearla ex novo.
Questo chiaramente e' un workaround che evita l'accumulo di un backlog eccessivo di record da inviare.

tabella transInLog piena

Descrizione

Il log hlr_qmgr.log segnala diversi errori del tipo:

Error inserting info in transInLog table.

Dove e quando si e' verificato e ticket di riferimento

INFN-MILANO-ATLASC - Giugno 2011
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=11725

Approccio

L'errore indica una impossibilita' a inserire record nella tabella transInLog. Probabilmente e' piena. Per verificare si suggeriscono le seguenti query:

show table status like 'transInLog' \G
show table status like 'jobTransSummary \G
show table status like 'trans_in' \G

Dall'output per la transInLog si nota che questa e' piena:

...
Data_length: 4294966800
Max_data_length: 4294967295
...

Soluzione

Aumentare il numero di righe per la tabella transInLog dell'HLR:

ALTER TABLE transInLog MAX_ROWS = 40000000;

indicando circa 10 volte il numero delle righe attualmente presenti (Rows: 4555712)

cambio versione torque

Descrizione

Nel log dell'urCollector non ci sono entry dal giorno in cui e' stato aggiornato Torque.

Dove e quando si e' verificato e ticket di riferimento

INFN-PARMA - Luglio 2011
https://ticketing.cnaf.infn.it/checklist-new/modules/xhelp/ticket.php?id=11746

Approccio

L'errore indica che i log non sono stati processati, forse a causa del fatto che non vengono piu' trovati. Si suggerisce di controllare nel dgas_sensors.conf se il valore della variabile pbsAcctLogDir corrisponde al path dove sono i log realmente.

Da questa verifica si nota che il path e' cambiato.

Soluzione

Modificare il valore di pbsAcctLogDir in dgas_sensor.conf e anche nel site_info.def. Questa ultima operazione viene fatta per evitare che alla successiva riconfigurazione il file dgas_sensors.conf venga riscritto con il valore sbagliato.