[Jderobot-admin] Ca�da del servidor del finde pasado

[Oscar Garcia]

El jue, 01-11-2012 a las 14:29 +0100, Borja Mon Serrano escribi�:
> Despu�s de analizar c�mo estaba el sistema (o as� interpreto yo todo
> lo que hay antes del siguiente oom-killer) mat� el servidor apache.
> Despu�s de varias llamadas a oom-killer (en las que no s� exactamente
> qu� es lo que est� haciendo) termin� por matar la base de datos,
> mysqld.


No creo que se cargara el servidor web, posiblemente matara un proceso
hijo que ser�a regenerado por el proceso apache padre. Estoy casi seguro
que fue un hijo pq oom-killer deja los procesos cuyo id es "root" para
los �ltimos, a parte de que trata de matar los procesos que llevan menos
tiempo ejecut�ndose y los procesos apache hijos tienen una vida mucho
m�s corta que el proceso apache padre. Eso asegura que servidores como
apache o sshd seguir�n en pie y s�lo sus hijos (procesos workers) ser�n
los sacrificados.



> A las 00:05:57 se tiene el �ltimo log, por lo que tampoco se puede
> determinar en qu� momento termin� de caer el servidor. Lo que s� est�
> claro es que desde que se mat� al servidor apache ya no se pudo volver
> a levantar.


Repito que posiblemente el servidor apache no muriera. He tenido
much�simos servidores con problemas de memoria que han provocado a
oom-killer a matar procesos apache y �ste no ha ca�do nunca (bueno,
menos los que se quedan "zombies" despu�s de eso, pero no es por haber
muerto un proceso hijo).


> �El problema? Que se quedase sin swap. No s� a qu� puede responder
> exactamente. Lo peor es que he le�do que no tiene por qu� solucionarse
> a�adiendo m�s memoria RAM al sistema [1], si no que habr�a que
> recurrir a otras alternativas como se explican en ese enlace. Lo que
> s� estar�a bien es, tal y como coment� �scar, instalar herramientas de
> monitorizaci�n del sistema. Pero aqu� nos topamos con el problema del
> libc de ayer...


Perdona que no consulte la web proporcionada. Depende del problema que
origin� el desastre aumentar la RAM ayuda o no. Lo que s� que no ayuda
ABSOLUTAMENTE NADA es aumentar la SWAP.

Tengo decenas de servidores en producci�n con 1 o 2 GB de swap y algunos
SIN SWAP alguna (sobre todo en las instancias ligeras de EC2).

El problema es que hay que dimensionar el servidor (o los procesos
servidor) para la RAM que se tiene. Por ejemplo, limitar el n�mero de
procesos hijos que puede levantar apache (con zabbix ser�a bueno
monitorizar el n�mero) o usar un acelerador web como squid para
aligerarle el trabajo.

Tambi�n se puede limitar el n�mero de sesiones activas de un usuario
en /etc/security/limits.conf (maxlogins) para evitar acumulaciones de
intentos de entrada svn, rsync, ssh, etc.

Por otro lado hay que ver qu� m�s procesos se levantan y si hay tareas
programadas o bots que hagan algo de manera autom�tica que se puedan ir
acumulando si no terminan el trabajo en el tiempo que se supon�a que
deb�an hacerlo.

Por ejemplo, uno de mis servidores cascaba cada x d�as debido a que la
sincronizaci�n de archivos que se ejecutaba cada 30 minutos usando lftp
se ralentizaba por problemas de ancho de banda o se quedaban pillados
los procesos de manera indefinida (porque el servidor de la Junta de
Andaluc�a se ca�a y se quedaba zombi como el vuestro) de modo que se
acumulaban cientos de procesos lftp todos conectados al servidor FTP.

El servidor empezaba a sufrir problemas de memoria (oom-killer al
ataque) pero �ste se equivocaba matando procesos "j�venes" como los del
servidor web en vez de los lftp que se iban acumulando ya que �stos
ten�an un tiempo de ejecuci�n elevado y, error m�o, eran ejecutados por
el usuario root en cron.

Casi siempre lo arreglaban simplemente reiniciando el servidor cuando lo
ve�an "raro" y todo iba bien, pero en vacaciones el servidor se
"cuajaba" hasta que descubr� el problema real.


> Durante todo el rato que he estado analizando el fichero de log he ido
> mirando cu�nta memoria disponible hay en el servidor. Tiene 2GB
> instalados, y normalmente hay usados unos 1650MB (unas veces m�s y
> otras veces menos, pero por ah�); eso s�, la swap est� completamente
> libre.


�Has restado a esa cantidad la cach� de disco usada?

redstar en greystar:~$ cat /proc/meminfo 
MemTotal:        2431608 kB
MemFree:          512600 kB
Buffers:          189232 kB
Cached:           470668 kB

redstar en tauri:~$ cat /proc/meminfo 
MemTotal:        4020452 kB
MemFree:          549760 kB
Buffers:          709448 kB
Cached:           536100 kB

Aunque pone en ambos casos que la memoria libre es cerca a 512 MB es
falso, a eso hay que a�adirle la totalidad de la cach� de disco (Cached)
que es descartada cuando se requiere memoria RAM y parte de los buffers
(sockets, archivos, etc) que tambi�n pueden ser liberados.

�Tuviste en cuenta esos datos para tomar la medida de uso de memoria? �O
usaste el valor que te pon�a alg�n comando como top o free?


> Veo poco probable el hecho de que hubiera un ataque al servidor para
> tirarlo abajo, aunque tambi�n se podr�a intentar mirar (en estos
> momentos no s� exactamente c�mo, tendr�a que investigarlo) si hubo un
> aumento inusual del tr�fico en la noche del s�bado al domingo.
> Seguramente fuese alg�n proceso que se terminase de comer toda la
> memoria disponible del sistema, pero es algo que no he alcanzado a ver
> con el syslog. Os adjunto un extracto del syslog donde se ve todo lo
> que os he comentado. Si necesit�is m�s, lo saco y os lo env�o.


El problema es que el syslog pudo ser matado y dej� de loguear eventos,
por eso es bueno tener un watchdog configurado. En la configuraci�n
viene para descomentar la monitorizaci�n del archivo de log "syslog"
para que se reinicie la m�quina en caso de que �ste caiga.


> A d�a de hoy no hay nada que indique que no se pueda volver a
> producir, as� que de momento, mientras no se pueda arreglar lo de la
> dependencia de libc, hay que andarse con mucho ojo.


Recuerdo que dijiste que todo el software adicional se instalaba en /opt
o /usr/local... pero tiene toda la pinta de que alguien instal� perl5
(creo recordar) en el directorio root.

�Pod�is comprobarlo? Cuando se instalan programas en paralelo que son
usados por los gestores de paquetes para ejecutar scripts de instalaci�n
o configuraci�n... �puf! es cuando te la juegas.

Por cierto, �no hab�is pensado en redundar la instalaci�n?

Por otro lado, podr�ais meter ciertos servicios dentro de un contenedor
virtual dentro de la misma m�quina para limitar los recursos usados. Yo
soy un usuario compulsivo de openvz.

Creo que cuanto antes se tenga montado el servidor zabbix y se
monitorice el comportamiento del servidor antes sabremos cu�l es el
origen del problema (cuando se repita) para arreglarlo.

PD: Hablando de ataques, tambi�n recomendar�a usar fail2ban para tener
una m�nima defensa contra ataques de fuerza bruta en el servidor ssh (y
otros que se configuren) y tener watchlog enviando informes diarios de
actividad del servidor. 

Un saludo.