Bug Number 5679560 (INIT.CSSD CAUSING SYSTEM LOG FILE FLOODED AFTER 10.2.0.3 PSR INSTALLATION)

lunedì 9 luglio 2007 alle 09:19 | Pubblicato su Diario, Installation and Configuration, Linux | 1 commento

Premetto che siccome il nostro “core business” è vendere il nostro prodotto che a sua volta utilizza come motore database Oracle, cerchiamo di proporre, per i clienti che non ci impongono scelte diverse, una architettura hardware/software più o meno standard per noi che ci da garanzia di affidabilità. Questo significa che cerchiamo di proporre sempre lo stesso hardware, lo stesso sistema operativo la stessa versione di Oracle, ove possibile. Questo significa che sull’hardware X proponiamo Suse SLES9 (Suse Linux Entrerprise Server 9) architettura X86_64. Poi sopra ci mettiamo Oracle 10.2, questo ci permette di ridurre la cosidetta curva di apprendimento e prevenire situazioni impreviste, per quanto possibile.

La scorsa settimana, sono stato in trasferta per un’installazione di Oracle RAC, versione 10.2 su un cluster di due nodi. Ho stabilito il mio record di installazione base, in quanto ho iniziato al mattino, partendo dallo scrupoloso esame dei prerequisiti hardware e software, come indicato dal manuale installazione e terminato a sera con l’importazione di un export di database di prova. Ora, forse non sarà un record mondiale di velocità di installazione, cosa a cui non tengo in quanto credo che la fretta sia cattiva consigliera, però per me è stato un buon risultato. Ciò mi ha fatto riflettere molto, perchè ho riflettuto sul fatto che quando sono in ufficio sono costretto a fare più cose contemporaneamente, sono interrotto ripetutamente per assistenze varie ed in più lavoro in un ambiente “open-space” dove c’è gente che discute, gente che urla al telefono e così via. Il fatto di fare più lavori contemporaneamente deriva dal fatto che noi informatici crediamo di essere degli elaboratori elettronici, piccoli processori in grado di fare continui “context-switching” in modo facile e veloce. Ho capito che non è così, e purtroppo non posso fare nulla per cambiare questa situazione, certo è che ho verificato che in condizioni umane posso rendere molto di più, in quanto in ufficio una installazione di questo di tipo fin’ora mi ha richiesto 2/3 giorni di lavoro.

A parte la digressione, il titolo di questo post rimanda ad un baco oracle in cui sono incorso nell’installazione di cui sopra, installazione comprensiva di PATCH SET 10.2.0.3. Avendo terminato relativamente presto ho avuto modo di fare i controlli che secondo me sempre vanno fatti dopo una installazione di questo tipo. Fra questi ho dato un’occhiata al log del sistema operativo, il file /var/log/messages trovando che venivano continuamente generati una sfilza di messaggi del tipo:

“Jan 10 04:15:05 mynode1 su: pam_unix2: session started for user oracle, service su
Jan 10 04:15:05 mynode1 su: pam_unix2: session finished for user oracle, service su

Una breve ricerca sul metalink mi ha portato alla nota 414889.1 in cui si imputa il problema al baco numero 5679560 (riportato nel titolo). Quindi ho provveduto, come consigliato nella nota, a scaricare la patch relativa, a leggere le note e ad installarla. Effettivamente dopo l’installazione della patch il problema è scomparso.

Il giorno successivo, verificato che tutto fosse regolare, insieme al cliente ho fatto un piccolo test, ho fatto scollegare il cavo della scheda di rete dedicata all’heartbeat, come mi aspettavo si è verificato lo split-brain ed il clusterware ha provocato il reboot di una delle due macchine. Una cosa che però non mi è piaciuta è però che in questa condizione il secondo nodo, si è riavviato, al boot ha rilevato che la connessione di heartbeat non era su, quindi tutta la parte di clusterware Oracle non è andata su. Però il file init.cssd viene attivato da file inittab (in modalità “respawn” con il parametro “fatal”), questo script evidentemente al suo interno ha un ciclo di controllo che lancia una istruzione tipo “su – oracle -c xy.sh” che provoca il log sul file /var/log/messages come riportato sopra. Quindi in questa situazione è ricomparso il problema della generazione ripetuta di messaggi sul log del sistema operativo, cosa secondo me non buona, perchè rende difficile l’esame del file di log stesso.

1 commento »

RSS feed for comments on this post. TrackBack URI

  1. […] Archivio ← Bug Number 5679560 (INIT.CSSD CAUSING SYSTEM LOG FILE FLOODED AFTER 10.2.0.3 PSR INSTALLATION) […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: