OVH Community, your new community space.

Server raggiungibile ma inutilizzabile


LeO
11.06.2009, 09.21
Manda un email su supporto@ovh.it e vaglieremo questa richiesta.

santinod
11.06.2009, 09.19
Citazione Originariamente Scritto da LeO
il test della RAM che esiti ha dato?
Purtroppo non ha segnalato errori. Dico purtroppo perché questo ci riporta in alto mare.

Ho intenzione di provare con un kernel diverso (2.6.29.3-rt-beta) e vedere se l'inconveniente si ripresenta.

A livello commerciale, visto che il ticket che avevo aperto inizialmente è rimasto senza risposta per più di una settimana mentre la macchina era inservibile, sarebbe possibile ottenere un prolungamento del contratto come amichevole risarcimento?

LeO
11.06.2009, 08.43
Ciao,

il test della RAM che esiti ha dato?

santinod
10.06.2009, 18.41
Citazione Originariamente Scritto da LeO
Ammesso che sia la RAM, ha effettuato i vari test hardware?
In questo momento sto effettuando il test CPU. Dalla documentazione però non è chiaro se termina da solo oppure va fermato manualmente con "Stop the test" dopo un certo tempo.

Come non detto: il test è terminato arrivando a buon fine. Ora provo con la memoria.

LeO
10.06.2009, 15.51
Ammesso che sia la RAM, ha effettuato i vari test hardware?

santinod
10.06.2009, 13.25
Citazione Originariamente Scritto da LeO
Bisogna capire qual'e' il problema, di sicuro non e' un problema hardware come si puo' ben capire, l'hardware non compromette l'apertura o chiusura delle porte.
Su questo concordiamo - anche se in realtà una RAM difettosa potrebbe causare malfunzionamenti di ogni tipo...

C'e' da capire cosa ci sia, a livello software, che non va bene.
Il kernel, per esempio? I problemi si sono sempre verificati con il
2.6.28.4-xxxx-std-ipv6-32 #2 SMP Wed Feb 18 16:36:08 UTC 2009 i686 GNU/Linux

L'unica soluzione e' cercare di vedere i log, si fermano a 5 giorni fa? ok, cosa dicono fino a 5 giorni fa? non c'e' alcun errore?
No, niente di strano o sospetto.
BTW dopo l'ultimo malfunzionamento avevo evitato di rebootare la macchina proprio per darvi modo di fare i controlli del caso e raccogliere più dati a riguardo (magari avete modo di osservare dmesg dalla console).

LeO
10.06.2009, 11.54
Bisogna capire qual'e' il problema, di sicuro non e' un problema hardware come si puo' ben capire, l'hardware non compromette l'apertura o chiusura delle porte.
C'e' da capire cosa ci sia, a livello software, che non va bene.
L'unica soluzione e' cercare di vedere i log, si fermano a 5 giorni fa? ok, cosa dicono fino a 5 giorni fa? non c'e' alcun errore?

santinod
10.06.2009, 11.10
Citazione Originariamente Scritto da LeO
Guardi, l'unica cosa e' chrootare la /mnt/ e successivamente digitare il comando iptable -F
In questo modo si cancellano le regole di iptables.
Come ho già scritto, iptables non blocca nulla, non è lui il colpevole.

Se non riesce a risolvere, l'unica opzione e' reinstallare la macchina.
Supponiamo che io reinstalli il sistema operativo e che tra una settimana il problema si ripresenti (cosa molto probabile, visti i trascorsi). Cosa fareste in quel caso?

MnEm0nIc
10.06.2009, 11.05
Citazione Originariamente Scritto da LeO
Guardi, l'unica cosa e' chrootare la /mnt/ e successivamente digitare il comando iptable -F
In questo modo si cancellano le regole di iptables.
se iptables non e' stato configurato di default dovrebbe far passare tutto. in ogni caso, a scanso si equivoci, e' meglio eseguire anche il ripristino dei valori di default delle chain su accept, quindi:
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

ovviamente queste operazioni non sono necessarie se dall'output di un iptables -L risulta una cosa simile:
Codice:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ciao

LeO
10.06.2009, 10.09
Guardi, l'unica cosa e' chrootare la /mnt/ e successivamente digitare il comando iptable -F
In questo modo si cancellano le regole di iptables.
Poi riavvii il server in modalita' normale.
Se non riesce a risolvere, l'unica opzione e' reinstallare la macchina.

santinod
10.06.2009, 10.01
Citazione Originariamente Scritto da LeO
Salve, l'unica opzione percorribile e' quella di mettere la macchina in Rescue Mode http://guida.ovh.it/ModeRescue
Montare i dischi e guardare nei log in "/mnt"/var/log/
Se fa il chroot sulla dir /mnt/ non deve mensionarla infatti bastera' andare direttamente in /var/log/ e guardare kernel ed error log.
I log si interrompono il 29/5 verso le 8 del mattino. Non ci sono tracce di eventi anomali.

Il problema e' relativo a qualche modifica fatta al software installato (che sia un firewall o altro questo non possiamo saperlo poiche' non e' possibile accedere al server)
No, iptables lascia passare tutto, e mi sembra irrealistico pensare che il problema nasca in user space. Al momento dei blocchi generalmente sono in esecuzione solo apache e postgres e non vedo come questi possano causare il problema. Se volete controllare, avete le chiavi...

LeO
09.06.2009, 17.34
Salve, l'unica opzione percorribile e' quella di mettere la macchina in Rescue Mode http://guida.ovh.it/ModeRescue
Montare i dischi e guardare nei log in "/mnt"/var/log/
Se fa il chroot sulla dir /mnt/ non deve mensionarla infatti bastera' andare direttamente in /var/log/ e guardare kernel ed error log.
Il problema e' relativo a qualche modifica fatta al software installato (che sia un firewall o altro questo non possiamo saperlo poiche' non e' possibile accedere al server)

Oppure l'opzione piu' drastica e' quella di formattarlo.

santinod
05.06.2009, 17.57
Al ping (IPv4/IPv6) la macchina risponde (come del resto avevo già scritto...) e il RTT pare normale.

Per quanto riguarda il traceroute:

1-4 irrilevanti
5 static-213-205-25-153.clienti.tiscali.it (213.205.25.153) 32.555 ms 34.215 ms 34.254 ms
6 so0-0-0-622M.ar2.LIN1.gblx.net (64.208.110.41) 36.434 ms 36.002 ms 38.234 ms
7 te2-1-10G.ar6.LON3.gblx.net (67.16.130.38) 61.734 ms 45.588 ms 44.471 ms
8 30g.gblx.ldn-1-6k.routers.ovh.net (213.251.130.53) 50.960 ms 48.574 ms 48.451 ms
9 20g.vss-1-6k.routers.chtix.eu (94.23.122.66) 54.946 ms * *
10 87.98.165.253 48.826 ms 48.385 ms 47.335 ms

LeO
05.06.2009, 17.22
Il traceroute ed il ping lo deve fare dal suo computer verso l'RPS

santinod
05.06.2009, 17.19
Salve LeO,
come ho scritto nel ticket e all'inizio del thread, il login sulla macchina mi è impossibile, quindi non ho a disposizione alcun ping o traceroute.

LeO
05.06.2009, 16.04
Salve, ha provveduto a fare un traceroute e una serie di ping??
Senza questo non possiamo capire che problema riscontra.

santinod
05.06.2009, 15.38
Un altro giorno senza segni di vita da OVH, e fanno 8.

santinod
04.06.2009, 16.14
Citazione Originariamente Scritto da torpado
Ho sollecitato l'intervento su questa macchina per il relativo ticket aperto
Grazie, ma all'orizzonte non si vede ancora nulla (a parte l'ombra di qualche OVNI).

Seriamente, il ticket langue da una settimana e il server è indisponibile da ancor più a lungo. Rapportato al periodo di pagamento rappresenta un downtime di più del 25%... :-(

torpado
03.06.2009, 16.34
Citazione Originariamente Scritto da santinod
Dopo alcuni giorni di uptime, il mio RPS (r23022) non risponde più alle connessioni, pur restando parzialmente raggiungibile. Più in dettaglio: risponde al ping, e i tentativi di connessione TCP su varie porte (es. ssh, http) arrivano allo stato ESTABLISHED ma è impossibile scambiare dati.

Questo inconveniente si è già verificato altre 3-4 volte, e sembra accadere regolarmente dopo 7-10 giorni di uptime. Un reboot risolve il problema, ma solo temporaneamente.

Evitando volutamente il reboot per permettere a OVH di esaminare la situazione, ho aperto un ticket a riguardo ben 6 giorni fa ed è tuttora "in attesa di trattamento".

Si può fare qualcosa?

Grazie,
David
Ho sollecitato l'intervento su questa macchina per il relativo ticket aperto

santinod
03.06.2009, 16.04
Dopo alcuni giorni di uptime, il mio RPS (r23022) non risponde più alle connessioni, pur restando parzialmente raggiungibile. Più in dettaglio: risponde al ping, e i tentativi di connessione TCP su varie porte (es. ssh, http) arrivano allo stato ESTABLISHED ma è impossibile scambiare dati.

Questo inconveniente si è già verificato altre 3-4 volte, e sembra accadere regolarmente dopo 7-10 giorni di uptime. Un reboot risolve il problema, ma solo temporaneamente.

Evitando volutamente il reboot per permettere a OVH di esaminare la situazione, ho aperto un ticket a riguardo ben 6 giorni fa ed è tuttora "in attesa di trattamento".

Si può fare qualcosa?

Grazie,
David