Quella connessione però è dall'interno. Chi è che sta cercando di connettersi? E' uno script o c'è qualcos'altro?

Riguardo il crash, è difficile scoprirne il motivo. Quando crasha non scrive ovviamente nulla nei log e quindi la vera causa non viene esposta. L'unica cosa da fare è dare uno sguardo alla configurazione dell'intero server, cominciando con l'individuare chi è quel tizio che cerca di loggare come UNKNOWN_MYSQL_US' CHIOCCIOLA.

Esito deitest:
-ho impostato tutti i siti inmanutenzione, quindi nessun accesso al db da parte loro;
-ho impedito accessi al db dall'esternotramite parametri bind-adress e skip-network, quindi sul db nonlavora nessuno. La connect riportata in precedenza viene fatta didefault dal Mysql così come visto in altri log di mysql sql trovatiin rete. Le istruzioni “show status” riscontrate nei precedentilog erano appartenenti al Mysql Administrator avviato sulla miamacchina.
-ho modificato la porta di mysql,giusto per essere sicuro che se fosse “attaccato” sarebbe rimastosu durante il mio test;
-ho verificato che la porta del mysqlnon fosse occupata da qualche altro processo quando mysql nonrisultava più su tra i processi;
-ho eseguito il mysqlcheck e ilmyisamchk individuando e riparando alcune tabelle che risultavanocorrotte;
-ho provato ad eseguire “yum updateinstall”, nell'ottiva di aggiornare il mysql, però non mi è statotrovato nessun pacchetto da installare;
-ho installato e fatto girare rkhunteral fine di trovare eventuali rootkit, e non è stato trovato nulla dianomalo sul sistema;
-ho verificato nel file di firewall lapresenza di eventuali attacchi dall'esterno, esito negativo;

Non sono riuscito a:
-scaricare/installare/configurare unanuova istanza Mysql parallela a quella già presente. Purtroppo nonho trovato alcuna documentazione online che spiega come installareuna seconda istanza sullo stesso sistema.
-verificare l'integrità del filesystemdella partizione su cui è installato il mysql in quanto ho notatoche, nonostante sia utente “root”, non posso eseguirel'istruzione “fdisk”...forse perchè parliamo comunque di unServer Virtuale.

Dopo tutte le suddette prove ilrisultato è che:
-nei log di mysql non trovopuntualmente nulla di anomalo tranne che la traccia del restart deldb;
-da shell tramite “htop”(opzione“s”) vedo il processo mysql killare sempre dopo pochi secondi dalrestart. Tracciando lo stato del processo, dopo essere stato killatoleggo il seguente messaggio nella console di “htop”: “+++KILLED by SIGKILL +++”. Cosa vuol dire?

Ciò che mi resta da provare al fine dirisolvere l'anomalia è:
-ricreare da zero i database,supponendo magari ci sia comunque qualcos'altro di corrotto. Puòessere?
-ripristinare il VPS alla situazioneiniziale(al momento dell'acquisto) accollandomi il costo diriconfigurare successivamente i siti web – database – cronjobattualmente disponibili. Ma prima di riconfigurare il tuttoverifecherò se il Mysql resterà su' per qualche oretta senza subirekill strani.
-mettere in conto di cambiare VPSmigrando da un concorrente di tiscali, la paura è ritrovarmi: conulteriori limitazioni su configurazione del VPS e stessi problemitecnici irrosilvibili visto che il servizio diassistenza(Telefonico-Email) PRATICAMENTE è inesistente.

Che ne pensate? Posso provarequalcos'altro prima di eseguire gli ultimi 2 punti come ultimaspiaggia?

Fatemi sapere.

Grazie 1000.

E' decisamente curioso che l'utente root non possa eseguire fdisk. Prova ad eseguire fsck per fare un controllo sullo stato del filesystem.

A parte eventuali corruzioni del filesystem o dei database, non c'è rimasto nient'altro da controllare. A meno che non si ammetta che il dbms crasha normalmente, il che sarebbe stato notato da qualche centinaio di milioni di utenti di mysql

Premetto che proverò in serata l'fsck...

Ma cosa si potrebbe evincere leggendo il messaggio finale “+++KILLED by SIGKILL +++” nella console di “htop” tracciando l'esecuzione del processo Mysql con l'opzione "s"?
E' la conferma che il processo viene arrestato dal Sistema Operativo, quindi il mysql non crasha da solo?

C'è qualche processo che chiede la chiusura di mysql.

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...