• N
    User •

    Crash Mysql su VPS Tiscali dopo qualche secondo dal restarting

    Crash Mysql su VPS Tiscali dopo qualchesecondo dal restarting

    Salve,
    posto qui in quanto nonostante icontinui solleciti a Tiscali nel verificarne le cause, nonostantepago a Tiscali profumatamente circa 400 euro l'anno per il ServerDedicato, ad oggi continuano a fare orecchio da mercante evitando dirispondermi a qualsiasi contatto via e-mail e/o telefonico.

    Sono titolare di un Virtual PrivateServer 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 dispazio su disco occupato;
    -MySql: versione 5.0.51;

    La configurazione del file my.cnf è laseguente:
    [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 MySqlcrasha in continuazione, in pratica riesce a stare in piedi perqualche secondo dal restart, e questo anche se i miei siti sono inmanutenzione(quindi non c'è alcun accesso al db), e se non effettuoalcuna comunicazione al db tramite client mysql. Crashando ho notatoche 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 comeintervenire, ho provato a tenere in manutanzione i siti noneffettuando alcuna richiesta al database, a riavviare ilservizio(tenendo attivati tutti i log) ottenendo puntualmente ilcrash del database dopo circa 5 secondi.
    Riporto di seguito quanto è statoscritto 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' (usingpassword: YES)
    120912 9:08:51 2 Connect root CHIOCCIOLA host6-76-DYNAMIC.2-79-r.retail.telecomitalia.it n
    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 GLOBALSTATUS
    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 INNODBSTATUS
    120912 9:09:01 2 Query SHOW GLOBAL STATUS

    Nell'ultimo log noto che c'è unaconnessione non autorizzata dall'esterno + una serie di ?ShowGlobal Status? e ?Show Innodb Status? che sicuramente noneseguo io da client. Devo dedurre che c'è qualcuno che riesce adentrare in continuazione nel mio db facendomelo crashare? E in questocaso come risolvo?
    Dipende da un problema diconfigurazione del my.cnf?
    Può essere corrotto il db, e quindiserve l'installazione di una nuova versione di MySql oppuresemplicemente la ricreazione di tutti i db?

    Qualcuno mi sa indicare a questo puntodov'è il problema?

    Attendo al più presto riscontri avendotutti i siti bloccati.

    Grazie e buona giornata.

    0
  • P
    Moderatore •

    Verifica se il dbms è accessibile anche dall'esterno del server. In questo caso puoi aggiungere bind-address=127.0.0.1 per renderlo accessibile solo da localhost.

    Da quello che vedo, qualcuno sta cercando di creare un exploit per bucarti il db.

    0
  • N
    User •

    Ho provato a limitare 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' CHIOCCIOLA '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.

    0
  • P
    Moderatore •

    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.

    0
  • N
    User •

    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.

    0
  • P
    Moderatore •

    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 😄

    0
  • N
    User •

    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?

    0
  • P
    Moderatore •

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

    0
  • N
    User •

    come faccio ad individuarlo?

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

    puoi darmi qualche dritta?

    0
  • P
    Moderatore •

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

    0
  • N
    User •

    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?

    0
  • P
    Moderatore •

    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.

    0
  • N
    User •

    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.

    0
  • P
    Moderatore •

    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.

    0
  • N
    User •

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

    0
  • P
    Moderatore •

    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.

    0
  • P
    Moderatore •

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

    0
  • N
    User •

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

    0
Effettua l'accesso per rispondere