Hola:

Estoy comenzando a pedir hora en el siquiatra. Llevo varioos dias con uno de mis servidores que cae aparentemente sin motivo, algunos puertos continuan abiertos, pero todos los servicios desaparecen.

No me permite tampoco entrar por SSH, por lo que el servidor queda horas a la espera de un reboot desde Rackshack.

Pienso que tiene que ver con las Quotas, he intentado repararlas, incluso eliminándolas y volviendolas a crear, pero en el proceso el servidor vuelve a caer y ya no me atrevo a hacer mucho más.

¿Alguien me puede dar alguna sugerencia o idea de que es lo que puede estar pasando, y como solucionarlo?

Saludos

a que te refieres cuando dices que "cae" el servidor?, es decir, cae apache, o el servidor completo.................¿?¿?

¿Que dicen las logs ?

Cuentame un poco más, pero seguro que lo solucionamos.

Saludos,

Gracias nickmm. Te comento. Muchas veces he estado en línea monitoreando esa máquina cuando pasa. Primero, cae el SMTP, luego el httpd, y comienzan a alternar (suben y bajan constantemente), pero el hecho es que no se puede accesar ni por Web ni por SSH. Sin embargo FTP y POP siguen funcionando.

Tengo instalada la última versión de SIM, y el panel es el 3.1.11.

Una vez que reinician la maquina en RS, el servidor vuelve en línea, pero no sube el HTTP ni Webapp. Entonces debo ingresar por SSH y reiniciar esos servicios manualmente. A veces va bien, pero otras, se cae completamente nuevamente mientras reinicia el httpd.

Cuando logro entrar por SSH (al observar comportamientos erráticos), veo que hay decenas de procesos "cronolog" corriendo. No consumen mucho, pero.... son demasiados a la vez.

Creo que aquí tiene mucho que ver el medidor de bandwidth y los archivos Log, pero no se como manejarlo realmente.

Gracias por cualquier sugerencia,

Sebastian

ufffff,

Yo empezaría con un estudio de las logs del servidor ( /var/log ) y las logs de apache ( /var/log/httpd ), ya que por ejemplo, cuando cae apache, el error_log deberá registrar que ha pasado, si no ves errores en el momento de la caida, sigue leyendo hacia atrás hasta que veas el error.

Esto con apache, y lo mismo con ensim, el sendmail .... etc, debes "sacar" la hora de la caida, y ver en las logs que estaba pasando en ese momento.

Lo primero, es saber que está causando el error, o por lo menos, que está haciendo el servidor en el momento de la caida ( procesos abiertos, carga del servidor ...... etc ).

Mirate bien las logs del servidor, puedes utilizar tail, more o pico y postea los errores que veas.

Otra cosa, ¿que carga tiene normalmente el servidor ?¿que ram tiene, y cuanta está consumiendo? ( esto lo puedes ver con el comando top, pulsa q para salir del top )

Qual é o seu servidor / equipamento / kernel / HD / Chipset?
Existe um thread que isto está sendo exaustivamente discutido, e estamos chegando a conclusões interessantes.

Netino

Bueno, en los logs del http no hay nada extraño antes de la caída, pero en log/messages está esto:

Jul 4 03:48:16 ensim proftpd[27660]: ensim.conectared.com (158.Red-80-37-203.pooles.rima-tde.net[80.37.203.158]) - FTP sessi$
Jul 4 03:48:22 ensim proftpd[27739]: ensim.conectared.com (158.Red-80-37-203.pooles.rima-tde.net[80.37.203.158]) - FTP sessi$
Jul 4 03:48:22 ensim proftpd[27739]: ensim.conectared.com (158.Red-80-37-203.pooles.rima-tde.net[80.37.203.158]) - no such u$
Jul 4 03:48:22 ensim last message repeated 4 times
Jul 4 03:48:22 ensim proftpd[27739]: ensim.conectared.com (158.Red-80-37-203.pooles.rima-tde.net[80.37.203.158]) - FTP sessi$
Jul 4 04:00:42 ensim proftpd[2500]: ensim.conectared.com (200.44.123.186[200.44.123.186]) - FTP session opened.
Jul 4 04:00:42 ensim PAM_pwdb[2500]: (ftp) session opened for user xcartay by (uid=0)
Jul 4 04:00:52 ensim proftpd[2500]: ensim.conectared.com (200.44.123.186[200.44.123.186]) - FTP session closed.
Jul 4 04:00:52 ensim PAM_pwdb[2500]: (ftp) session closed for user xcartay
Jul 4 04:15:02 ensim sendmail[8634]: getpeername 107 : Transport endpoint is not connected
Jul 4 04:15:02 ensim server localhost.localdomain [127.0.0.1] cmd read[8634]: getpeername 107 : Transport endpoint is not co$
Jul 4 04:15:42 ensim proftpd[9072]: ensim.conectared.com (200.44.123.186[200.44.123.186]) - FTP session opened.
Jul 4 04:15:44 ensim PAM_pwdb[9072]: (ftp) session opened for user xcartay by (uid=0)
Jul 4 04:15:58 ensim proftpd[9072]: ensim.conectared.com (200.44.123.186[200.44.123.186]) - FTP session closed.
Jul 4 04:15:58 ensim PAM_pwdb[9072]: (ftp) session closed for user xcartay
Jul 4 04:20:20 ensim httpd: httpd shutdown failed
Jul 4 04:20:45 ensim [11578]: Validation succeeded
Jul 4 04:21:52 ensim [12228]: Validation succeeded
Jul 4 04:24:55 ensim httpd: httpd startup succeeded
Jul 4 04:25:02 ensim [13794]: Validation succeeded
Jul 4 04:25:07 ensim httpd: httpd shutdown succeeded
Jul 4 04:25:10 ensim [13938]: Validation succeeded
Jul 4 04:25:13 ensim httpd: httpd shutdown succeeded
Jul 4 04:25:13 ensim httpd: httpd shutdown succeeded


Ese usuario (xcartay) muestra más de 2 horas de logueos por el FTP.

En el maillog:

Jul 4 05:01:20 ensim sendmail[23634]: alias database /etc/aliases rebuilt by root
Jul 4 05:01:20 ensim sendmail[23634]: /etc/aliases: 41 aliases, longest 39 bytes, 443 bytes total
Jul 4 05:01:23 ensim sendmail[23886]: starting daemon (8.11.6): SMTP+queueing@01:00:00
Jul 4 05:01:23 ensim sendmail[23886]: rejecting connections on daemon MTA: load average: 17
Jul 4 05:01:25 ensim sendmail[24100]: alias database /etc/aliases rebuilt by root
Jul 4 05:01:25 ensim sendmail[24100]: /etc/aliases: 41 aliases, longest 39 bytes, 443 bytes total
Jul 4 05:01:27 ensim sendmail[24492]: starting daemon (8.11.6): SMTP+queueing@01:00:00
Jul 4 05:01:28 ensim sendmail[24492]: rejecting connections on daemon MTA: load average: 16
Jul 4 05:01:30 ensim sendmail[24767]: alias database /etc/aliases rebuilt by root
Jul 4 05:01:30 ensim sendmail[24767]: /etc/aliases: 41 aliases, longest 39 bytes, 443 bytes total
Jul 4 05:01:32 ensim sendmail[25093]: starting daemon (8.11.6): SMTP+queueing@01:00:00
Jul 4 05:01:32 ensim sendmail[25093]: rejecting connections on daemon MTA: load average: 16
Jul 4 05:01:33 ensim sendmail[25281]: alias database /etc/aliases rebuilt by root
Jul 4 05:01:33 ensim sendmail[25281]: /etc/aliases: 41 aliases, longest 39 bytes, 443 bytes total
Jul 4 05:01:35 ensim sendmail[25525]: starting daemon (8.11.6): SMTP+queueing@01:00:00
Jul 4 05:01:35 ensim sendmail[25525]: rejecting connections on daemon MTA: load average: 16
Jul 4 05:01:36 ensim sendmail[25695]: alias database /etc/aliases rebuilt by root
Jul 4 05:01:36 ensim sendmail[25695]: /etc/aliases: 41 aliases, longest 39 bytes, 443 bytes total
Jul 4 05:01:39 ensim sendmail[26175]: starting daemon (8.11.6): SMTP+queueing@01:00:00
Jul 4 05:01:39 ensim sendmail[26175]: rejecting connections on daemon MTA: load average: 16
etc-etc-etc-etc

Fuera de esto, lo que comentaba antes: muchos procesos cronolog......

Netino:

No se cual es el Hardware instalado, si sabes como extraerlo, por favor indícame y lo postearé aquí.

Lo único que sé es que es un Celeron 1.3 con 512 RAM, Kernel: kernel-2.4.9-34

nickmm:

Este es el Top en este momento, cuando la carga del server está baja:

7:51pm up 6:54, 1 user, load average: 2.25, 3.11, 3.17
471 processes: 469 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 41.4% user, 23.7% system, 1.3% nice, 33.4% idle
Mem: 504792K av, 380604K used, 124188K free, 13172K shrd, 87072K buff
Swap: 1020116K av, 96384K used, 923732K free 118856K cached

Hola Sebastian,

Sobre el messages, si no conces el usuario xcartay, rastrea la IP ( puedes hacerlo con programas como el visual route ), y si crees conveniente bloqueas la ip. No es que este comprometiendo la seguridad del server, pero a nadie le apetece que esten dos horas intentado acceder FTP.

Jul 4 04:20:20 ensim httpd: httpd shutdown failed
Jul 4 04:24:55 ensim httpd: httpd startup succeeded

Estas lineas del archivo messages, nos dicen que Apache ha fallado para apagarse, pero que ha arrancado de forma correcta. Esto puede ser debido a un error de apache, o que habia alguien haciendo "cosas" en el servidor, tu o un reseller.

Mira en el error_log de apache ( /var/log/httpd ) si entre las 4:20 o 4:24 hay algun aviso o error.

Mira tambien, que son todos esos procesos que aparecen en top ejecutanto ps aux, o con el comando netstat. Estos comandos, te diran que son todos esos procesos.

Sabiendo esto, la solucion ya esta mas cerca.

Saludos,

Dices que el load esta bajo, pero esta a 3.17 en una media de 15 minutos. A cuanto suele llegar el load?

A mi parecer tienes demasiada carga en el servidor. Cuando el servidor ve que no puede con todo empieza a desactivar servicios y por eso primero se apaga el correo, despues apache, etc.

Te aconsejo hacer 3 cosas:

1. Comprobar con frecuencia /var/log/messages por si ves algo raro.

2. Optimizar apache y desactivar "persistent connections" en /etc/php.ini

3. Optimizar las base de datos con este comando desde SSH:
mysqlcheck -o -u root -p --all-databases

Un saludo

Bueno, además de ir haciendo todo lo que me han indicado (gracias coolio), hoy a las 3:30am he visto nuevamente en /log/messages que el mismo usuario intentó las conexiones con los errores de la noche anterior. Luego, http cayó y SIM lo levantó nuevamente. Vi la IP desde donde se conectaba y la bloqueé en el servidor, negándole todo acceso.... y milagrosamente el servidor no arrojó ningún solo error más, hasta ahora donde ya han transcurrido casi 6 horas.

En que línea de php.ini se desactivan exactamente las "persistent connections"?

Aquí hay algo extraño:

Jul 4 05:30:39 ensim PAM_pwdb[8097]: (ftp) session opened for user xcartay by (uid=0)

El usuario xcartay no existe en el servidor... de que se puede tratar esto?

Busca esto:

[MySQL]
; Allow or prevent persistent links.
mysql.allow_persistent = On

Y cambias On por Off.

Ok coolio, ya hice el cambio.

Una cosa más, httpd acaba de reiniciarse. En los logs de error pude encontrar esto:

[Sat Jul 5 10:04:56 2003] [notice] child pid 28116 exit signal Segmentation fault (11)

(disculpen todas las preguntas y antecedentes que voy aportando, pero de las 8 máquinas que tengo en RS, esta es la única que me da estos problemas y quiero llegar a descubrir que es lo que sucede realmente. Ya he intentado todo lo que está a mi alcance, instalado SIM y otras herramientas, seguido todos los post en RS, etc., sin resultados)

Cosas que tenes que pensar:

1- tenes actualizado ssl en el servidor??
2- pensaria en poner a correr el php en safe mode a ver si este para.
3- haria un netstat de las conexiones al momento al servidor.

cualquier cosa que pueda ayudar avisame.

carlos

Si usa ensim entonces php trae el safe mode activado por defecto.

El servidor ya lleva 5 horas abajo hoy en la tarde. Cada vez que lo reinician en RS a duras penas alcanzo a entrar por SSH, y al intentar hacer partir el httpd, se tranca nuevamente, pierdo contacto por SSH y debo pedir un nuevo reinicio.

La última respuesta que me han dado en RS fue:

"server was hanging on tomcat4. server has been booted into single user mode and is accessible via ssh. closing ticket. "

Efectivamente pude entrar por SSH, todos los servicios estaban abajo, reinicie http, pero nada pasó. Revisé /log/messages y encontré una serie de errores relacionados con CATALINA:Tomcat4, lo bajé y reinicie el servidor completo nuevamente, ahora no vuelve a línea y en RS demoran un poco en los reboot, sobre todo cuando uno los pide cada 5 minutos....

De verdad esto me está sacando de casillas, no puedo entender que pasa ni como solucionarlo.

Había logrado 24 horas de paz deshabilitando webppliance, al parecer algo tiene que ver el que los revendedores puedan trabajar sobre el server. Detuve webppliance y todo se mantuvo en calma, lo habilité y una hora después comenzaron los problemas. 2 revendedores entraron a modificar sus cuentas en ese lapso de tiempo.

Solo en el caso de que logre tener este servidor en línea nuevamente: ¿Cual es la mejor forma de descubrir que sitio(s) puede estar causando overloads o problemas con Tomcat?

(Agradezco a todos la ayuda que me han dado hasta ahora)

Tal como dije en un mensaje mas arriba, este problema parece ser por excesiva carga en el servidor. Tomcat es una de las cosas que mas recursos consume en un servidor Ensim. Webbpliance es otra ya que usa Python, que tambien usa muchos recursos.

Quiza te vendria bien mover los sitios que mas recursos consuman a otro servidor.

Ese es justamente el problema. Tengo poco menos de 70 sitios creados en ese servidor, no creo en ningún caso que sea excesivo (tengo otras máquinas con 200 cuentas y trabajan como reloj).

El tema es como saber cuales son los sitios que están consumiendo en exceso... tienes alguna idea?

Prueba a activar server-status en php.ini (busca en ese archivo la cadena server-status y lo encontraras) y miras que sitios usan mucho el apache.

O otra posibilidad podria ser mirar cuales consumen mucha transferencia. Cuanta mas transferencia consuma un sitio, mas recursos estara usando, no?

Mira a ver que sitios usan BBDD, y cuales hacen un uso fuerte de ella. Lo mismo con los sitios que usen Java.

Se puede tener 70 sitios en un servidor y tenerlo mas cargado que uno con 200. Todo depende de si los sitios son estaticos, usan mucho email, mucho java, mucho mysql, etc.

Bueno, eso es lo unico que se me ocurre ahora mismo.

Son las 2:15 de la mañana, creo que voy a dormir un poquillo

Saludos

Descubrí que cada vez que el servidor cae, una de las últimas acciones es el logueo por FTP de un usuario específico (siempre el mismo), además del que nombraba anteriormente que no existe en el sistema.

Esto sucedió nuevamente durante esta madrugada, bloqueé la IP desde la cual se conectaban y el servidor volvió a trabajar con normalidad hasta ahora... veré que es lo que sucede el Lunes.

Lo que me molesta es no poder saber que es lo que hacen para botar los servicios... y a esa misma hora comienza la actualización del bandwidth, por lo que no he podido encontrar la relación entre estos dos eventos....

A la hora que comienze lo del bandwidth seguramente tambien se haran otras cosas que esten programadas para ejecutarse diariamente, con lo que subira la carga del servidor.

chequea los crons que se ejecutan antes de que se caiga el servidor.
capaz que hay alguno que ejecuta una tarea o procesos que consume recursos del servidor.

carlos

¿Quien sabe que significa que cuando reinicie un servicio, específicamente httpd, se detenga el proceso y me indique "terminated" ?

¿Como se puede solucionar eso?

Gracias por todo

Sebastian, eos em pasaba con mi maquina tambien, hable con support en el chat y uno de ellos entro al server le hizo algo y jamas se ha vuelto a caer.

Gracias, voy a hacer exactamente lo mismo ahora.

Saludos

Sebastian,

Verifique se você possui o chipset VIA vt82c686b em sua configuração. Tenho exatamente um Celeron 1.3 com 512 MB de RAM, com um crash regularmente, provavelmente devido ao chipset acima, mas acredito que este hardware é mais que suficiente para dar conta de 400Gb/mês de tráfego.

Veja se você o possui, com o seguinte comando:
# grep -i vt82c686b /var/log/dmesg

Se você encontrar alguma linha, então você possui este chipset.

A solução provavelmente seria efetuar um upgrade para o kernel 2.4.21 ou para o 2.4.20, porém com um patch, muito simples, que posso lhe passar. Você deverá compilar o kernel, pois somente com os RPM´s da RedHat não será possível aplicar. O problema é que ainda não consegui uma configuração estável com este kernel, pois ainda tenho uma mensagem de erro de conflito com o teclado, que em hipótese alguma poderia ficar sem ser configurado corretamente, para fins de suporte da RS.

Netino

Si... me ha dado esta línea:

VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1

Me dices que al obtener este retorno debo hacer un upgrade al Kernel... es lo único que no me he atrevido a hacer en ninguna de mis máquinas..... parece que va a ser tiempo de comenzar... al menos con esta....

Sebastian,

Avise se tiver dúvidas sobre como recompilar seu kernel.

O patch que você precisa é o seguinte:
===========================
/caminho/do/kernel/linux-2.4.XXX/drivers/pci/quirks.c
===========================
663a664
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_vialatency },

Inclua somente a linha acima naquela posição (linha 663) no arquivo quirks.c (não esqueça de [TAB] entre os campos), onde "/caminho/do/kernel/linux-2.4.XXX" é o caminho do código fonte do kernel.

Assegure-se de que em seu kernel esteja selecionada a opção:
CONFIG_BLK_DEV_VIA82CXXX=y

Após compilá-lo, aparecerá no arquivo /var/log/dmesg a seguinte mensagem:
(...)
Applying VIA southbridge workaround.
(...)

Parece haver um bug na distribuição do kernel com relação ao chipset acima.

A informação acima custou-me um enorme trabalho para obtê-la, e alguns clientes perdidos depois dos 46 sucessivos crashes em 50 semanas.

Abraços,

Netino

Adicionalmente, procure acompanhar a evolução de seu swap, antes e depois do patch, para ver como é notável a diferença.

# cat /proc/meminfo

Se instalar o mrtg (veja howto do mrtg) fica mais fácil de visualizar.

Aparentemente, o swap se comporta muito melhor, de forma controlada. Sem o patch, a tendência era aumentar o espaço ocupado sem parar.

Abraços,

Netino

Netino, agradezco muchísimo tu ayuda, pero la verdad es que no me atrevo a hacer un upgrade al Kernel basado en instrucciones en portugues..... Gracias de todas formas, intentaré encontrar alguien que entienda bien tu lengua, o seguiré en busca de instrucciones en inglés o español.

Gracias,

Sebastian

The howto compiled kernel are in:
http://forum.rackshack.net/showthread.php?...+kernel+upgrade

Regards,

Netino