Newsgroup: it.comp.software.database
Titolo: Crash Mysql su VPS Tiscali dopo qualche secondo dal restarting

Crash Mysql su VPS Tiscali dopo qualche secondo dal restarting
 
 
Salve,
posto qui in quanto nonostante i continui solleciti a Tiscali nel 
verificarne le cause, nonostante pago a Tiscali profumatamente circa 400 
euro l'anno per il Server Dedicato, ad oggi continuano a fare orecchio da 
mercante evitando di rispondermi a qualsiasi contatto via e-mail e/o 
telefonico.
 
Sono titolare di un Virtual Private Server di Tiscali con le seguenti 
caratteristiche:
-SO: Redhat Linux Fedora 9.0;
-RAM: 2 GB, con circa 1.5 GB liberi;
-Hard Disk: 20 GB, con circa 7 GB di spazio su disco occupato;
-MySql: versione 5.0.51;
 
La configurazione del file my.cnf è la seguente:
[client]
port        = 3306
socket        = /var/lib/mysql/mysql.sock
 
[mysqld]
port        = 3306
socket        = /var/lib/mysql/mysql.sock
skip-locking
 
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8
 
server-id    = 1
 
max_connections = 50
key_buffer = 32M
tmp_table_size = 64M
max_heap_table_size = 64M
query_cache_limit = 2M
 
ft_min_word_len = 2
 
log=/var/log/mysqld.log
log-warnings=2
 
log-error=/var/log/mysqld-err.log
 
long_query_time = 3
log-slow-queries=/var/log/mysqld-slow.log
 
skip-bdb
skip-innodb
skip-ndbcluster
 
[mysqldump]
quick
max_allowed_packet = 16M
 
[mysql]
no-auto-rehash
 
[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
 
[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M
 
[mysqlhotcopy]
interactive-timeout
 
 
Da circa un mese mi capita che MySql crasha in continuazione, in pratica 
riesce a stare in piedi per qualche secondo dal restart, e questo anche se i 
miei siti sono in manutenzione(quindi non c'è alcun accesso al db), e se non 
effettuo alcuna comunicazione al db tramite client mysql. Crashando ho 
notato che tutti i processi mysql scompaiono anche tra i processi del SO, 
che seguo tramite l'htop lanciato nella shell unix.
 
Alla fine, per capire meglio come intervenire, ho provato a tenere in 
manutanzione i siti non effettuando alcuna richiesta al database, a 
riavviare il servizio(tenendo attivati tutti i log) ottenendo puntualmente 
il crash del database dopo circa 5 secondi.
Riporto di seguito quanto è stato scritto nei log.
 
-mysqld-err.log:
120912  9:08:46 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.51a-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306 
Source distribution
 
-mysqld-slow.log:
/usr/libexec/mysqld, Version: 5.0.51a-log (Source distribution). started 
with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
 
-mysqld.log:
120912 09:08:46  mysqld started
/usr/libexec/mysqld, Version: 5.0.51a-log (Source distribution). started 
with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
120912  9:08:47          1 Connect     Access denied for user 
'UNKNOWN_MYSQL_US'@'localhost' (using password: YES)
120912  9:08:51          2 Connect 
ro...@host6-76-dynamic.2-79-r.retail.telecomitalia.it
 on
              2 Query       SET NAMES utf8
120912  9:08:52          2 Query       SHOW GLOBAL STATUS
120912  9:08:53          2 Query       SHOW INNODB STATUS
              2 Query       SHOW GLOBAL STATUS
120912  9:08:54          2 Query       SHOW INNODB STATUS
120912  9:08:55          2 Query       SHOW GLOBAL STATUS
120912  9:08:56          2 Query       SHOW INNODB STATUS
120912  9:08:57          2 Query       SHOW GLOBAL STATUS
120912  9:08:58          2 Query       SHOW INNODB STATUS
120912  9:09:00          2 Query       SHOW GLOBAL STATUS
              2 Query       SHOW INNODB STATUS
120912  9:09:01          2 Query       SHOW GLOBAL STATUS
 
 
Nell'ultimo log noto che c'è una connessione non autorizzata dall'esterno + 
una serie di “Show Global Status” e “Show Innodb Status” che sicuramente non 
eseguo io da client. Devo dedurre che c'è qualcuno che riesce ad entrare in 
continuazione nel mio db facendomelo crashare? E in questo caso come 
risolvo?
Dipende da un problema di configurazione del my.cnf?
Può essere corrotto il db, e quindi serve l'installazione di una nuova 
versione di MySql oppure semplicemente la ricreazione di tutti i db?
 
Qualcuno mi sa indicare a questo punto dov'è il problema?
 
Attendo al più presto riscontri avendo tutti i siti bloccati.
 
Grazie e buona giornata.
 
 

 
 
secondo me e' piu' un problema da sistemista che non da dba.
 
hai provato a disattivare l'accesso a mysql via rete o a limitarlo a 
localhost?
 
una delle due:
bind-address=127.0.0.1
oppure:
skip-networking
 
il firewall della macchina cosa dice? c'e' qulche log sospetto?
 
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

Ho provato a seguire il tuo consiglio limitando l'accesso al mysql al 
127.0.0.1 e non permettendo le connessioni dall'esterno.
 
Ora nel log scrive solo questo:
 
120912 14:45:06  mysqld started
/usr/libexec/mysqld, Version: 5.0.51a-log (Source distribution). started 
with:
Tcp port: 3306  Unix socket: /var/lib/mysql/mysql.sock
Time                 Id Command    Argument
120912 14:45:07          1 Connect     Access denied for user 
'UNKNOWN_MYSQL_US'@'localhost' (using password: YES)
 
Il tentativo di connessione c'�, per� viene subito respinto.
Il problema � che il db crasha puntualmente dopo qualche secondo nonostante 
non venga eseguita alcuna query sul db. Quindi deduco che il problema del 
crash del db non dipenda dal tentativo di connessione esterno. Giusto?
 
A questo punto cosa mi consigli di verificare a livello sistemistico?
 
Come anticipato parliamo di un VPS Tiscali, e tiscali non mi da alcuna 
assistenza...devo sbrigarmela io, anche perch� ho il pieno controllo del 
server dedicato.
 
Fammi sapere non appena puoi, e ti ringrazio per la collaborazione. 
 

 
 


Puoi indicarmi quali sono i log che dovrei tracciare/controllare anche a 
livelli di Firewall/SO?
 
Per tiscali, � una storia lunga che ti risparmio...ovviamente se non ne 
dovessi venir fuori non posso far altro che andare altrove anche se alla 
fine il servizio in corso di tiscali PREVEDE l'assistenza tecnica...solo che 
non � possibile parlargli al telefono, non rispondo alle e-mail...
 
 
"Paolo opg"  ha scritto nel messaggio 
news:XnsA0CD59A5DB53Csp...@193.43.96.1...


Esito dei test:
-ho impostato tutti i siti in manutenzione, quindi nessun accesso al db da 
parte loro;
-ho impedito accessi al db dall'esterno tramite parametri bind-adress e 
skip-network, quindi sul db non lavora nessuno. La connect riportata in 
precedenza viene fatta di default dal Mysql così come visto in altri log di 
mysql sql trovati in rete. Le istruzioni “show status” riscontrate nei 
precedenti log erano appartenenti al Mysql Administrator avviato sulla mia 
macchina.
-ho modificato la porta di mysql, giusto per essere sicuro che se fosse 
“attaccato” sarebbe rimasto su durante il mio test;
-ho verificato che la porta del mysql non fosse occupata da qualche altro 
processo quando mysql non risultava più su tra i processi;
-ho eseguito il mysqlcheck e il myisamchk individuando e riparando alcune 
tabelle che risultavano corrotte;
-ho provato ad eseguire “yum update install”, nell'ottiva di aggiornare il 
mysql, però non mi è stato trovato nessun pacchetto da installare;
-ho installato e fatto girare rkhunter al fine di trovare eventuali rootkit, 
e non è stato trovato nulla di anomalo sul sistema;
-ho verificato nel file di firewall la presenza di eventuali attacchi 
dall'esterno, esito negativo;
 
Non sono riuscito a:
-scaricare/installare/configurare una nuova istanza Mysql parallela a quella 
già presente. Purtroppo non ho trovato alcuna documentazione online che 
spiega come installare una seconda istanza sullo stesso sistema.
-verificare l'integrità del filesystem della partizione su cui è installato 
il mysql in quanto ho notato che, nonostante sia utente “root”, non posso 
eseguire l'istruzione “fdisk”...forse perchè parliamo comunque di un Server 
Virtuale.
 
Dopo tutte le suddette prove il risultato è che:
-nei log di mysql non trovo puntualmente nulla di anomalo tranne che la 
traccia del restart del db;
-da shell tramite “htop”(opzione “s”) vedo il processo mysql killare sempre 
dopo pochi secondi dal restart. Tracciando lo stato del processo, dopo 
essere stato killato leggo il seguente messaggio nella console di “htop”: 
“+++ KILLED by SIGKILL +++”. Cosa vuol dire?
 
Ciò che mi resta da provare al fine di risolvere l'anomalia è:
-ricreare da zero i database, supponendo magari ci sia comunque 
qualcos'altro di corrotto. Può essere?
-ripristinare il VPS alla situazione iniziale(al momento dell'acquisto) 
accollandomi il costo di riconfigurare successivamente i siti web – 
database – cronjob attualmente disponibili. Ma prima di riconfigurare il 
tutto verifecherò se il Mysql resterà su' per qualche oretta senza subire 
kill strani.
-mettere in conto di cambiare VPS migrando da un concorrente di tiscali, la 
paura è ritrovarmi: con ulteriori limitazioni su configurazione del VPS e 
stessi problemi tecnici irrosilvibili visto che il servizio di 
assistenza(Telefonico-Email) PRATICAMENTE è inesistente.
 
Che ne pensate? Posso provare qualcos'altro prima di eseguire gli ultimi 2 
punti come ultima spiaggia?
 
Fatemi sapere.
 
Grazie 1000. 
 

Riporto di seguito il risultato dell'strace sul processo mysql, risultato 
identico ad ogni riavvio(quest'ultimo avviene tramite cronjob puntualmente 
ogni minuto visto che il db cade dopo pochi secondi dall'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 da trattare è l'errore  “EOPNOTSUPP” 
appartenente al mysql.
 
In rete ho trovato i seguenti link in cui ne parlano, anche se i log non 
sono proprio uguali:
-
http://bugs.mysql.com/bug.php?id=28690
 
-
http://forums.serverbeach.com/showthread.php?6133-To-Ticket-Or-Not..-MySql-EOPNOTSUPP
 
-
http://bugs.mysql.com/bug.php?id=16988
 
 
Mi era sembrato di capire che poteva dipendere da un problema di privilegi, 
quindi ho fatto ripartire il mysql con l'utente root(prima partiva con 
l'utente mysql) pensando di risolvere 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 volta per tutte.
 
Qualche consiglio?
 

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

 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
 
Parecchi anni or sono gestivo alcuni vps su Areserver, tutti con Debian, 
sia miei che di clienti. Non era un servizio eccellente ma valeva 
assolutamente quello che si stava pagando, un centinaio di euro/anno se 
non ricordo male.
 
Quando Tiscali acquis� Areaserver cominci� a presentarsi una serie 
infinita di problematiche... dal lato tecnico all'assistenza fino a 
quello amministrativo, ne ho viste di tutti i colori.
Tutti, per un motivo o per l'altro sono stati costretti a migrare... e 
come ciliegina Tiscali ci ha messo in mezzo varie problematiche 
pretestuose nella migrazione dei domini tanto che in diversi casi si � 
dovuti ricorrere ad internic/icann per sbloccare la situazione.
 
Dopo quell'odissea mi basta sentir nominare il nome T... per girare 
immediatamente alla larga.
 
-- 
TeeBX VoIP communication platform (coming soon)
http://code.google.com/p/teebx/
 
-----------------------------------------------
Lightweight++ Business Friendly++ Open++