imbabolamento semi-periodico di alcuni servizi

[eiyen]

Salve!

Prova a postare questa situazione per vedere se qualcuno ha qualche suggerimento su cosa si potrebbe verificare...

su un web server (del tipo "virtual server": su cui insomma si può avere un controllo "quasi" totale) ho predisposto dei servizi canonici: web server, ftp, mail, etc.. semi-periodicamente (nel senso che è già successo due/tre volte in un paio di mesi) alcuni servizi si "imbambolano", e in particolare è capitato per: FTP e MAIL... nel caso dell'ftp viene rifiutato l'accesso (come se il processo si piantasse), mentre nel caso delle mail succede che non si ricevono (a meno di non accedere alla webmail e mandarsela "internamente" al server) e chi le spedisce non riceve alcun avviso. RIAVVIANDO semplicemente il server l'FTP torna funzionante e le mail tornano a posto (quelle inviate durante il periodo di blocco arrivano regolarmente e se si è mandata una mail ad un account inesistente, a questo punto - e solo a questo punto - torna al mittente il warning corrispondente).

Cosa mi suggerite di verificare durante la fase di blocco per capire cosa possa succedere? E inoltre da cosa potrebbe dipendere (nel caso facciate delle ipotesi)?

Non si è mai fermato il servizio "www" per cui il sito è risultato sempre attivo.

Stavo anche valutando di programmare un riavvio periodico "preventivo" (per es.: ogni settimana)...

[DigItalWarrior]

Sistema operativo?
Usi un pannello web? Quale?
Servizio ftp utilizzato?
Servizio email utilizzato?

Dacci maggiori informazioni.

[eiyen]

il "VS" è basato su Linux (è preinstallato e in questo momento non posso controllare la distribuzione e non ho sottomano i dettagli, ma li posso cercare) e dispone tra l'altro di:

Apache2
PHP5
ProFTPD
qmail

(accesso tramite SSH o pannello PLESK)

NOTA: sottolineo che da un periodo di "buon" funzionamento a un "blocco" non intercorre alcune variazioni di configurazione: l'unico "uso" del server è l'accesso al sito installato (quindi le uniche operazioni di "scrittura" sul server sono quelle dovute al web server e alle variazioni sul db

[eiyen]

sto provando a verificare i "log", ma non ho ancora trovato nulla... qualche consiglio in quale e cosa cercare?

[eiyen]

ok (si fa per dire)... ho trovato che il problema dovrebbe essere legato a xinetd

xinetd[.....]: ..... {general_handler} (.....) Unexpected signal: 11 (Segmentation fault)
last message repeated 9 times
xinetd[.....]: ..... {bad_signal} Received xx bad signals. Exiting...

dove ..... è il numero di processo e .. il limite oltre cui si ha la chiusura automatica del processo

cercando in giro pare si tratti di un problema abbastanza "comune", ma non ho ben capito come ovviare... il "Segmentation fault" sembrerebbe legato a problemi hardware (contatterei il provider, in questo caso) e non a poche risorse disponibili.

Mi servirebbe anche una soluzione tampone nel frattempo, come un riavvio automatico.

[eiyen]

in effetti non ho ancora risolto... avrei bisogno di capire il modo più corretto per isolare la causa del problema e in ogni caso la soluzione più giusta per riavviare automaticamente xinetd in questi casi (non dovrebbe essere possibile usare l'opzione respawn perchè il servizio è avviato all'interno di uno script richiamato dall'inizializzazione insieme a un altro elenco di servizi).

Grazie.

[eiyen]

(up)

[SUPERMIKY]

il famoso "signal eleven" è uno dei più temuti messaggi di errore da che mondo è mondo
succede quando un processo cerca di accedere ad uno stack di memoria a cui non ha diritto (di solito si usa abbreviarlo in SIGSEGV, Signal segmentation violation).

ad ogni modo, sarebbe interessante capire che distribuzione di linux monti, ed, in ogni caso, provare a reinstallare (in caso di ubuntu, per esempio, con un dpkg-reconfigure) il pacchetto che va in segmentation fault.

[eiyen]

@SUPERMIKY: grazie per le info... alcuni dettagli li conoscevo dopo aver fatto delle ricerche in giro.

Sapevo qualcosa, ma non mi ci ero imbattuto... per quanto riguarda l'analisi+soluzione del caso devo trovare un "workaround" (non posso reinstallare tutto)... il server è un "virtual server" di un provider a pagamento che fornisce il sistema preinstallato (direi a migliaia di utenti e più): vorrei capire se può dipendere comunque da fattori "esterni" e controllabili o meno... sto seriamente valutando di usare crontab per schedulare il forzato riavvio di xinetd (con periodicità che deciderei empiricamente in base alla frequenza del problema: in teoria potrebbe essere sufficiente una/due volte la settimana, ma al limite anche ogni giorno... sto valutando se questo potrebbe creare problemi, ma fin'ora non ho trovato vere controindicazioni, a parte appunto l'empiricità e la "artigianalità" di tale soluzione, che però potrebbe essere abbastanza efficace come "tamponamento").

Non capisco bene invece se è possibile configurare il numero di "bad signals" dopo i quali xinetd si interrompe... in ogni caso durante il tentativo di accesso errato alla memoria il servizio risulta bloccato? Questo non mi è del tutto chiaro... o può essere un processo figlio di xinetd?

Grazie ancora per le info, cmq.

[SUPERMIKY]

Originariamente inviato da eiyen
@SUPERMIKY: grazie per le info... alcuni dettagli li conoscevo dopo aver fatto delle ricerche in giro.

Sapevo qualcosa, ma non mi ci ero imbattuto... per quanto riguarda l'analisi+soluzione del caso devo trovare un "workaround" (non posso reinstallare tutto)... il server è un "virtual server" di un provider a pagamento che fornisce il sistema preinstallato (direi a migliaia di utenti e più): vorrei capire se può dipendere comunque da fattori "esterni" e controllabili o meno... sto seriamente valutando di usare crontab per schedulare il forzato riavvio di xinetd (con periodicità che deciderei empiricamente in base alla frequenza del problema: in teoria potrebbe essere sufficiente una/due volte la settimana, ma al limite anche ogni giorno... sto valutando se questo potrebbe creare problemi, ma fin'ora non ho trovato vere controindicazioni, a parte appunto l'empiricità e la "artigianalità" di tale soluzione, che però potrebbe essere abbastanza efficace come "tamponamento").

Non capisco bene invece se è possibile configurare il numero di "bad signals" dopo i quali xinetd si interrompe... in ogni caso durante il tentativo di accesso errato alla memoria il servizio risulta bloccato? Questo non mi è del tutto chiaro... o può essere un processo figlio di xinetd?

Grazie ancora per le info, cmq.

ma hai provato magari a reinstallare xinetd?