Come ottenere uno stack trace completo di mysqld (il server MariaDB)
Contents
- Compilare MariaDB per il debug
- Aggiornare il file my.cnf
- Rimpiazzare temporaneamente il mysqld standard con la versione di debug
- Ripristinare la versione originale di mysqld
- Usare il file core
- Se non si ottiene un file core quando mysqld va in crash
- Eseguire una copia della directory del database
- Segnalare il bug
Se si verifica un errore critico di mysqld
(core dump), per default scriverà uno stack trace nel file 'nomehost'.err
nella directory dei database. Tuttavia vi sono casi in cui questo non è sufficiente per individuare il problema.
Le seguenti istruzioni spiegano come ottenere uno stack trace completo su Unix.
Per capire dov'è il problema, uno sviluppatore di MariaDB necessita di una o più fra le seguenti informazioni:
- Uno stack trace completo (che si può ottenere solo usando un binario compilato per il debug)
- Un file core (immagine del programma crashato)
- Un mysqld compilato per il debug.
Ecco come creare tutto questo:
- Si scarichi un file tar.gz dei sorgenti
(like
mariadb-5.2.9.tar.gz
). - Lo si compili per il debug
- Si aggiorni il file my.cnf per ottenere un
core
e uno stack trace. - Si installi il mysqld di debug al posto di quello regolare.
- Si esegua la versione di debug fino a quando non avviene un nuovo crash.
- Si ripristini la vecchia versione di
mysqld
.
Compilare MariaDB per il debug
Segue un esempio di come compilare MariaDB per il debug nella propria home directory con MariaDB 5.2.9:
cd ~ mkdir mariadb cd mariadb tar xvf mariadb-5.2.9.tar.gz ln -s mariadb-5.2.9 current cd current ./BUILD/compile-pentium64-debug-max
L'ultimo comando produce una versione di debug di sql/mysqld
. Se si ha un sistema che non sia Intel/AMD a 64 bit con Linux, si può utilizzare un diverso file BUILD/...-debug-max
. Se il comando fallisce, si provi in questo modo:
./BUILD/autorun.sh ./configure --with-debug=full -with-extra-charsets=complex \ --with-plugin-aria --with-aria-tmp-tables --without-plugin-innodb_plugin \ --with-plugins=max \ --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static make
Aggiornare il file my.cnf
Si aggiungano le righe seguenti al file ~/.my.cnf
:
[mysqld] --stack-trace --core-file [mysqld-safe] --core-file-size=unlimited
Si può lasciare anche per il futuro, non creano problemi.
Nota: Se si sta utilizzando safe_mysqld
ed eseguendo mysqld
come root
, su alcuni sistemi non verrà creato alcun file core
. La soluzione è eseguire mysqld
con un altro utente.
Rimpiazzare temporaneamente il mysqld standard con la versione di debug
Ecco come farlo su Open SuSE. Sulle altre distribuzioni di Linux, mysqld
potrebbe trovarsi in altre directory.
mysqladmin shutdown cd /usr/local/mysql/libexec mv mysqld mysqld-orig cp ~/mariadb/current/sql/mysqld mysqld-debug ln -s mysqld-debug mysqld
I comandi sopra riportati rimpiazzano mysqld
con la versione di debug, e lo fanno in un modo che rende semplicissimo il ritorno alla versione originale.
A questo punto, si avvi di nuovo mysqld con un comando come:
/etc/rc.d/mysql start
Ripristinare la versione originale di mysqld
E' possibile ripristinare il binario originale di mysqld in questo modo:
cd /usr/local/mysql/libexec rm mysqld ln -s mysqld-orig mysqld
Si noti che il binario di debug non viene cancellato: viene rimosso soltanto il sym-link, che immediatamente viene sostituito con uno che punti al binario originale. In questo modo, il binario di debug potrà essere riutilizzato in futuro.
Usare il file core
Se la versione di debug di mysqld va in crash, si dovrebbe avere:
- Uno stack trace più preciso nel file
'nomehost'.err
, che si trova nella directory dei dati. - Un file
core
ocore.
, sempre nella directory dei dati.##
Per esaminare lo stack trace e altre informazioni nel debugger gdb
:
cd ~/mariadb/current cp directory-del-db/core* core gdb ~/mariadb/current/sql/mysqld core backtrace full
Se non si ottiene un file core quando mysqld va in crash
Su alcuni sistemi, le dimensioni del file core hanno un limite. Per conoscere il limite e incrementarlo:
ulimit -c ulimit -c unlimited
Dopodichè, si riavvii mysqld.
Su alcuni sistemi Linux i file core sono disabilitati dal kernel. Per controllare:
sysctl -a | grep k.*core sysctl -a | grep dumpable
Si verifichi che fs.suid_dumpable=2
. Per impostarlo:
/sbin/sysctl -w fs.suid_dumpable=2
Si veda anche http://www.cyberciti.biz/tips/linux-core-dumps.html#comments
Eseguire una copia della directory del database
Se non si vuole eseguire il debug binario sul database di produzione, è possibile copiare il database in un altro percorso e utilizzare la nuova versione. In questo caso si può evitare di installare MariaDB come spiegato sopra, ed eseguire mysqld direttamente dalla directory dei sorgenti.
In questo modo si potrà sapere senza rischi quale istruzione ha mandato in crash il server.
Si avii mysqld con l'opzione
--datadir=/copia-della-directory
Segnalare il bug
Infine si segnali il problema nel database dei bug di MariaDB, includendo lo stack trace.
Per errori molto complicati o critici, si può inviare a Monty Program Ab la versione di debug di mysqld
, il file core
e informazioni su come essere ricontattati nel file .tar
o .zip
. Loro analizzeranno il tutto e tenteranno di risolvere il problema.