come faccio ad individuarlo?

devo capire/studiare come eseguire il debugging del processo mysql?

puoi darmi qualche dritta?

No, basta il tracing delle syscalls. C'è un programma apposito e si chiama strace.

Riporto diseguito il risultato dell'strace sul processo mysql, risultatoidentico ad ogni riavvio(quest'ultimo avviene tramite cronjobpuntualmente ogni minuto visto che il db cade dopo pochi secondidall'avvio):

getsockname(19, {sa_family=AF_FILE,path="/var/lib/mysql"}, [28]) = 0
fcntl64(19, F_SETFL, O_RDONLY) = 0
fcntl64(19, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(19, F_SETFL, O_RDWR|O_NONBLOCK)= 0
setsockopt(19, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x86e7024, FUTEX_WAKE_OP_PRIVATE,1, 1, 0x86e7020, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_EQ, 0}) = 1
select(6, [4 5], NULL, NULL, NULL) = 1 (in [5])
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
Occept(5, {sa_family=AF_FILE, path="ñ
"}, [2]) = 58
fcntl64(5, F_SETFL, O_RDWR) = 0
getsockname(58, {sa_family=AF_FILE,path="/var/lib/mysql"}, [28]) = 0
fcntl64(58, F_SETFL, O_RDONLY) = 0
fcntl64(58, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(58, F_SETFL, O_RDWR|O_NONBLOCK)= 0
setsockopt(58, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation not supported)
futex(0x86e7024, FUTEX_WAKE_OP_PRIVATE,1, 1, 0x86e7020, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_EQ, 0}) = 1
select(6, [4 5], NULL, NULL, NULL<unfinished ...>
+++ killed by SIGKILL +++

Da quanto ho capito il problema datrattare è l'errore “EOPNOTSUPP” appartenente al mysql.

In rete ho trovato dei link incui ne parlano(link che questo sito non mi permette di inserire non essendo un utente premium), anche se i log non sono proprio uguali.

Mi era sembrato di capire che potevadipendere da un problema di privilegi, quindi ho fatto ripartire ilmysql con l'utente root(prima partiva con l'utente mysql) pensando dirisolvere però purtroppo il problema persiste.
Sembra sia un problema frequente,quindi potrebbe accadere la stessa cosa se si cambia gestore del VPS.
Il problema è che non mi èassolutamente chiaro come e dove intervenire per risolverla una voltaper tutte.

Qualche consiglio?

Non è necessariamente quello l'errore. Anzi il SIGKILL arriva dopo la select. Potrebbe trattarsi di selinux che killa il processo credendo che sia malware. Potrebbe dipendere dalla poca ram a disposizione, con conseguente swap ( che notoriamente porta a crash di mysql ).

A questo punto ti conviene postare sul forum di mysql, in modo che gli sviluppatori possano almeno cercare di capire cosa succede. Onestamente con mysql se ne vedono di tutti i colori e non è il genere di dbms che raccomanderei. Mi spiace doverlo dire ma, dopo anni di tribolazione, passare ad un dbms come postgresql è stata una boccata d'aria fresca.

Qual'è esattamente il forum su cui postare?

Quali sono le informazioni che dovrei postare per essere il più chiaro possibile?

Utilizzi anche tu un Virtual Server per gestire dei siti web? E il tuo virtual server ha il postgresql? Poi indicarmi il link con le caratteristiche del VPS?

Grazie.

Questo qui http://forums.mysql.com/

Descrivi la situazione, postando i log, eventualmente dai prima un'occhiata alla questione della ram, swap e controlla che l'IDS ( selinux in genere ) non killi mysql perchè lo crede un malware.

Si, io uso anche alcuni vps ( per la verità molti meno che in passato ). Un paio su xtrahost, cioè questo http://xtrahost.co.uk/xenvps/

Il perchè uso xen è per via di compatibilità, stabilità e soprattutto performance ( molti vps virtuozzo fanno overselling ). La distribuzione che uso su quasi tutti è archlinux, a parte qualche dedicato con freebsd.

Ma il problema è che è proprio mysql che presenta significative problematiche, che vanno da crash per i quali non si capisce il motivo, a rallentamenti, instabilità in generale. Ovviamente il tutto avviene quando ci sono carichi di lavoro importanti.

Come verifico che l'IDS ( selinux in genere ) non killi mysql perchè lo crede un malware?

Qui c'è una guida per selinux http://wiki.centos.org/HowTos/SELinux

Quello che devi fare è essenzialmente creare un log leggibile tramite il comando "sealert -a /var/log/audit/audit.log > /path/to/mylogfile.txt" e poi guardare nel file creato se c'è qualcosa riguardo mysql.

Ovviamente puoi pure disabilitare momentaneamente l'IDS e vedere se mysql viene chiuso lo stesso.

Dopo averle provate di tutti i colori, non mi è rimasto altro che ripristinare il server tiscali al momento dell'acquisto.

Ho quindi potuto selezionare il ripristino del server scegliendo tra le seguenti distribuzioni:
-Fedora 9
-Fedora 13
-Centos 5.3
-Centos 6.2
-Ubuntu 10.4

Una vera delusione aver scoperto che le prime 4 distribuzioni sono bacate. In pratica il mysql installato in quelle distribuzioni crasha dopo qualche secondo dall'avvio rendendo quindi impraticabile un sito web. Il problema non si risolve nemmeno aggiornando i package della singola distribuzione.
Insomma una vera delusione nei confronti di Tiscali, per la presenza del software bacato oltre alla mancata assistenza nonostante le numerose e-mail e nonostante sul loro sito per il servizio Virtual Server Special si ostinano ad assicurare un servizio di assistenza professionale ANCHE TELEFONICO(e telefonando c'è la vocina registrata che informa che per i d servizi web si deve far riferimento alla sezione "assistenza" del loro sito web, e quindi ci si deve arrangiare a ciò che si trova nella pseudo-faq).

L'unica fortuna è che il tutto funziona sulla Ubuntu 10.4...ma questo lo si deve scoprire da soli, dopo aver perso circa 1 mese e mezzo di prove e studio su possibili cause sul webserver attivo, e dopo aver perso posizioni in termini di indicizzazione con il sito down per circa 2 mesi.

Mah...