[Jderobot-admin] Zabbix

Mie Nov 21 13:45:14 CET 2012

El 21/11/2012 11:29, Borja Mon Serrano escribió:
> La reinstalación de zabbix ya la hice en su momento, como te comenté.
> Hice un purge con apt-get (apt-get purge zabbix-agent
> zabbix-server-mysql zabbix-frontend-php) y volví a instalar todo (menos
> el agente) de cero. Aun así, cuando intento acceder al recurso /zabbix
> me salía el mismo mensajito de error que anteriormente:
> mysql_connect(): Access denied for user 'zabbix'@'localhost' (using
> password: YES)[/usr/share/zabbix/include/db.inc.php:58]

Al desinstalar el paquete zabbix-server-mysql creo que ni se borra el 
usuario zabbix de base de datos, ni sus permisos ni la base de datos. La 
verdad es que no lo he hecho nunca, ¿has comprobado que siguieran ahí? 
Podría estar dando problemas si ahora hay varios usuarios con el mismo 
nombre pero diferentes contraseñas o, peor aún, no se limpió la base de 
datos.

Un "DROP DATABASE zabbix;" debería arreglar el problema de mantener 
datos (una vez hecho el dpkg -P zabbix-server-mysql o el apt-get remove 
--purge zabbix-server-mysql).

> Diciéndome además que "Zabbix is temporarily unavailable!". De todas
> formas, reinstalaré de nuevo zabbix, no vaya a ser que metiese la pata
> en la reinstalación última que hice.

Eso siempre lo dice cuando no puede conectarse a la base de datos (por 
estar caída, por no tener permisos, etc).

> Lo de la contraseña de Admin de zabbix lo vi en el enlace que dejaste.
> En la máquina virtual funciona bien, sin problemas, en jderobot no lo sé
> precisamente por el error que te comento un poco más arriba.
> Según la consulta que me has dicho, sí, la contraseña coincide:
> mysql> SELECT alias,passwd,md5('zabbix') as posible FROM users WHERE
> alias LIKE 'admin';
> +-------+----------------------------------+----------------------------------+
> | alias | passwd                           | posible
>       |
> +-------+----------------------------------+----------------------------------+
> | Admin | 5fce1b3e34b520afeffb37ce08c7cd66 |
> 5fce1b3e34b520afeffb37ce08c7cd66 |
> +-------+----------------------------------+----------------------------------+
> 1 row in set (0.00 sec)

Entonces la contraseña web es Admin/zabbix, pero ahora quizá no te 
funcione debido a que en dbconfig.php exista un usuario/contraseña de 
base de datos que no es correcta, quizá al reinstalar la cambiaste y 
ahora hay conflicto... si haces un purge a zabbix-* (incluido el agente) 
puedes eliminar con seguridad el directorio /etc/zabbix.

> mucho intentarlo al final lo conseguí. Estuve "monitorizando" el uso de
> CPU con top durante un rato y de vez en cuando hacía un free -m para ver
> cómo iba la RAM. Normalmente iba todo bien, salvo durante un rato que el
> proceso apache2 se estuvo devorando la CPU (pongo solo lo más
> significativo):

Precisamente hubiera sido un momento genial para iotop más que para top.

> 19072 www-data  20   0 96180  51m 3932 R   93  2.5   1:43.34 apache2
> 19002 www-data  20   0 96272  50m 3728 R   88  2.5   1:25.10 apache2
> 18028 www-data  20   0 66824  14m 3324 S    4  0.7   0:12.11 apache2

Quizá el parámetro para regenerar los hijos de apache2 esté mal 
configurado ya que no debería tener tanto tiempo de ejecución sin 
regenerarse (marca 1 hora y 45 minutos uno de ellos). Nosotros tenemos 
configuradas 50 conexiones por hijo antes de que éste se regenere.

Es lo normal de un servidor web en carga:
top - 12:31:58 up 7 days,  5:26,  2 users,  load average: 0.73, 0.64, 0.52
Tasks: 228 total,   2 running, 226 sleeping,   0 stopped,   0 zombie
Cpu0  : 43.0%us,  5.6%sy,  0.0%ni, 49.3%id,  0.0%wa,  0.3%hi,  1.7%si, 
0.0%st
Cpu1  : 11.8%us,  5.2%sy,  0.0%ni, 83.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu2  :  6.9%us,  4.9%sy,  0.0%ni, 88.2%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu3  : 12.5%us,  3.6%sy,  0.0%ni, 83.9%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu4  :  3.7%us,  4.7%sy,  0.0%ni, 91.7%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu5  :  3.6%us,  4.0%sy,  0.0%ni, 92.4%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu6  :  2.3%us,  4.0%sy,  0.0%ni, 93.7%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Cpu7  :  1.7%us,  4.2%sy,  0.0%ni, 94.1%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:   2060264k total,  1703880k used,   356384k free,    84288k buffers
Swap:   499704k total,        0k used,   499704k free,  1157184k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13903 www-data  20   0  225m  35m  12m S   20  1.8   0:01.32 apache2
13016 www-data  20   0  225m  34m  11m S   13  1.7   0:01.39 apache2
13238 www-data  20   0  219m  28m  12m S   11  1.4   0:01.22 apache2
15795 www-data  20   0  213m  20m 9.8m S    9  1.0   0:00.26 apache2
  9421 www-data  20   0  219m  29m  13m S    8  1.5   0:03.10 apache2
  9007 www-data  20   0  217m  28m  13m S    8  1.4   0:02.79 apache2
15794 www-data  20   0  216m  24m  10m S    7  1.2   0:00.31 apache2
  9422 www-data  20   0  225m  36m  13m S    6  1.8   0:03.34 apache2
  9004 www-data  20   0  217m  27m  13m R    4  1.4   0:02.35 apache2
  8693 www-data  20   0  219m  28m  12m S    1  1.4   0:01.98 apache2

Aunque el ejemplo no vale mucho debido a que el servidor está tras un 
acelerador web (un squid que balancea la carga entre varios servidores 
web) y que esta máquina tiene 8 núcleos "Intel(R) Xeon(R) CPU 
E7450  @ 2.40GHz" (sacado del /proc/cpuinfo), pero es normal que ante 
ciertas páginas se queden durante un par de segundos usando el 99% de 
cpu uno o varios procesos apache2 (he estado esperando un par de minutos 
a ver si pillaba alguno así y no ha habido suerte, pero ha habido 
ocasiones en los que he visto eso).

Quizá deberíais probar a cambiar:
MaxRequestsPerChild   50

Lo único que hace es que los procesos "hijos" de apache2 que realmente 
sirven las peticiones "mueran" tras atender 50 peticiones, liberando 
memoria (para evitar agujeros o zonas muertas de memoria, etc) y 
posteriormente (si se necesita y está dentro del rango de procesos 
configurado) levantará un proceso fresco. De este modo será difícil que 
un proceso apache2 siga vivo con una hora y tres cuartos de tiempo de 
ejecución.

> En esos momentos al servidor le costaba mucho devolver la página web,
> pero bueno, aunque lento (como por la mañana) iba bien. Me sorprendió
> también que hubiera tantísima memoria RAM libre:

El iotop, ha fallado el iotop aquí para descartar velocidad de acceso a 
disco (si los datos están en disco local).

Por cierto, provecho para preguntar, ¿es un sistema de archivos local o 
es nfs?

> jderobot:~# free -m
>               total       used       free     shared    buffers     cached
> Mem:          2018        344       1674          0          6         71
> -/+ buffers/cache:        265       1752
> Swap:         1608        110       1497

También te ha faltado un "uptime" para saber si el servidor ha sido 
reiniciado o no... por la poca memoria "cached" y la cantidad de memoria 
libre tiene toda la pinta de que llevaba poco tiempo levantado (vamos, 
que había sido reiniciado hacía poco, aunque fuera la madrugada anterior).

Posiblemente saltó watchdog para salvar la situación desde el error de 
anoche. Si watchdog salta tras una congelación debida a paginación 
excesiva es normal que no deje rastro en el syslog (si watchdog falla 
con el reboot "suave" tira de un reset brusco).

> Unos minutos más tarde, que sería cuando yo me metí (aproximadamente),
> aparecen mensajes:
>
> Nov 20 23:42:28 jderobot kernel: [110400.572039] INFO: task syslogd:927
> blocked for more than 120 seconds.
> Nov 20 23:42:28 jderobot kernel: [110400.572074] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Nov 20 23:42:28 jderobot kernel: [110400.572107] syslogd       D
> c1087f2a     0   927      1 0x00000000

¡Eso sí es un síntoma de paginación excesiva! Ese es el típico mensaje 
que sale cuando la máquina pagina con tantísima frecuencia que si una 
operación de entrada/salida se retrasa más de 120 segundos aparece un 
mensaje en el log advirtiendo sobre eso... y poco a poco lo hace con más 
frecuencia.

Si en ese momento hiciéramos un top veríamos una carga de CPU muy 
elevada (por encima de 15), y un tiempo iowait también elevado (por 
encima del 75%) y un uso de swap elevado.

Un consejo: un servidor debería tener menos del 50% de swap que de 
memoria RAM, así el equipo no perdería rendimiento por uso de memoria, 
si no que se dedicaría a matar procesos que considere que puedan ser 
eliminados.

Yo prefiero una caída suave de los servicios que una caída completa del 
servidor.

> Y eso repetido para otras tareas:
>
> Nov 20 23:42:31 jderobot kernel: [110760.573026] INFO: task
> kjournald:238 blocked for more than 120 seconds.
> Nov 20 23:42:33 jderobot kernel: [110760.573299] INFO: task mysqld:17108
> blocked for more than 120 seconds.
> Nov 20 23:42:33 jderobot kernel: [110760.573567] INFO: task mysqld:17361
> blocked for more than 120 seconds.

Es normal que los primeros procesos que sufran las consecuencias sean 
mysql, por la cantidad de operaciones de lectura/escritura que realiza, 
y kjournald, el encargado de mantener el jornal del sistema de archivos, 
ya que es el proceso que afianza dicha información escrita en disco.

> Ese último mensaje de mysqld que ves repetido sale varias veces
> repetido. Supongo que ahora mismo la base de datos no está del todo
> bien, a parte de los mensajes esos, hay otros de por la mañana que dicen:
>
> Nov 20 11:21:04 jderobot mysqld: 121120 11:21:04 [ERROR]
> /usr/sbin/mysqld: Incorrect key file for table
> './wikidb/wikijde_searchindex.MYI'; try to repair it
> Nov 20 11:21:04 jderobot mysqld: 121120 11:21:04 [ERROR]
> /usr/sbin/mysqld: Incorrect key file for table
> './wikidb/wikijde_searchindex.MYI'; try to repair it

Es lo malo de los reinicios "bruscos", pero nada que no se pueda reparar 
con un "REPAIR TABLE ...". Los índices siempre se pueden reconstruir a 
partir de los datos (tenemos suerte en ese aspecto), si llega a ser un 
archivo de datos entonces recuperar a partir del log de transacciones es 
más complejo, no es tan fiable (nunca sabes si los datos que te faltan 
están recogidos en el reducido tamaño de log que tiene mysql) y encima 
no está soportado en bases de datos myisam, sólo en innodb (es como la 
diferencia entre ext2 y ext3).

> Nov 20 13:28:03 jderobot mysqld: 121120 13:26:58 [ERROR]
> /usr/sbin/mysqld: Got an error writing communication packets
>
> Nov 20 13:34:20 jderobot suhosin[22676]: ALERT - canary mismatch on
> efree() - heap overflow detected at 0xb99faf44 (attacker 'REMOTE_ADDR
> not set', file
> '/var/www/mediawiki-1.18.1/includes/db/DatabaseMysql.php', line 23)

He hecho una búsqueda rápida en los bugs de debian y he encontrado esto:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535148#65

¿Podrías comprobar si somos víctimas de ese bug? En caso afirmativo, 
¿podrías desinstalar el paquete php5-suhosin?

Es un bug extremadamente viejo, pero sin poder ver las versiones 
instaladas no sé si estamos bajo su influjo. Por lo pronto desactivar o 
desinstalar ese paquete podría arrojar luz sobre el problema aunque 
también podría estar derivado de peticiones al servidor MySQL que han 
sido canceladas, postpuestas, etc por latencias altas de acceso a disco 
y que PHP no haya sabido cómo tratar ese evento.

> Lo que creo es que con lo que pasó el otro día con watchdog, que no
> hacía otra cosa que reiniciar el servidor, hubo varias cosas que se
> cargaría. Entre ellas, algo de la base de datos. Y digo entre ellas
> porque desde ese momento no se puede acceder al recurso del mediawiki
> que enviaste y, por ejemplo, dejó de funcionar phpldapadmin (lo tuve que
> reinstalar, ahora ya funciona).

Podría tratarse de corrupción del sistema de archivos, ¿has hecho un 
fsck o lo has forzado para el próximo reinicio? No es normal que un 
archivo se quede "colgado" accediendo a él o que un registro de una 
tabla de la base de datos se quede "congelada" de esa manera, pero sí me 
ha pasado que tras periodos muy largos de paginación de una máquina en 
repetidas ocasiones, el calor que genera la actividad ha terminado por 
dañar los discos duros físicos de la máquina y han empezado a 
comportarse de manera extraña a partir de entonces.

Prueba antes de nada un RECOVER TABLE de todas las tablas. Como no la 
base de datos de la wiki no es muy grande no tardará mucho.

Para asegurarte _haz antes_ un backup _completo_ con mysqldump (-p --opt 
--all-databases, etc) por si las moscas. Nunca se sabe, no me ha pasado 
nunca que se corrompan las bases de datos, pero siempre hay un primer 
día para que ocurra algo. Vuelca a local y, si puedes, a un USB o equipo 
externo en dos ejecuciones diferentes (no copies un archivo previamente 
generado), así evitamos propagar cualquier problema de disco.

Si quieres, por velocidad, excluye del backup la base de datos zabbix (y 
si hacéis backups lógicos diarios más vale excluirla de ellos a no ser 
que sean backups binarios).

Después de todo esto, si sigue la congelación del equipo habrá que mirar 
dmesg por si hay errores de entrada/salida del tipo:

[332888.147751] ata1.00: failed command: WRITE FPDMA QUEUED
[332888.150324] ata1.00: cmd 61/08:50:48:9c:1e/00:00:06:00:00/40 tag 10 
ncq 4096 out
[332888.150327]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 
0x44 (timeout)
[332888.155453] ata1.00: status: { DRDY }
[332888.158000] ata1: hard resetting link
[332888.500039] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[332888.566365] ata1.00: configured for UDMA/133
[332888.566373] ata1.00: device reported invalid CHS sector 0
[332888.566406] ata1.00: device reported invalid CHS sector 0
[332888.566427] ata1: EH complete
[333184.165140] ata1.00: exception Emask 0x50 SAct 0x1 SErr 0x280900 
action 0x6 frozen
[333184.167747] ata1.00: irq_stat 0x08000000, interface fatal error
[333184.170354] ata1: SError: { UnrecovData HostInt 10B8B BadCRC }
[333184.172942] ata1.00: failed command: READ FPDMA QUEUED
[333184.175506] ata1.00: cmd 60/a8:00:e0:00:b9/00:00:03:00:00/40 tag 0 
ncq 86016 in
[333184.175508]          res 40/00:00:e0:00:b9/00:00:03:00:00/40 Emask 
0x50 (ATA bus error)
[333184.180671] ata1.00: status: { DRDY }
[333184.183242] ata1: hard resetting link
[333184.530054] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Ve probando y vamos a ver si terminamos de poner a punto todo para que 
vuelva todo a la normalidad.

Un saludo.