alto uso de CPU por daemon 003 bloquea el servidor

This site is best viewed in a modern browser with JavaScript enabled.

alto uso de CPU por daemon 003 bloquea el servidor

hgmnetwork

hola, no se si les ha pasado a alguien, de unos pocos dias hasta hoy el uso del cpu se dispara al 100% utilizao issabel 4

mirando con un simple top me aparece esto
ER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22898 daemon 20 0 10408 4904 212 S 197,0 0,2 10:12.95 003
3615 asterisk 0 -20 1776796 48488 15536 S 0,7 1,7 2:39.07 asteris

el daemon ejecuta el commando 003 y consume toda la cpu practicamente.

he mirado con mas detalle y he localizado estos ficheros

[root@voz /]# find / -name 003
/tmp/003
/dev/02/003
/dev/dahdi/chan/001/003
/dev/bus/usb/003
/opt/openfire/plugins/admin/webapp/003

pero no se si sea por alguno en concreto o el motivo. alguien le ha ocurrido ?

mato el proceso y funciona todo bien pero a las pocas horas se dispara de nuevo con lo mismo

si alguien me puede ayudar se lo agradezco

he revisado y veo en el /tmp se van creando ficheros 003.1 003.2 etc asi muchisimos los elimino pero los crea de nuevo

venturinog

hgmnetwork Tienes instalado OpenFire?

javier

Tengo varias PBX corriendo y monitoreadas, hasta ahora no he visto un uso excesivo de CPU, incluso andan todo el día al 3% de CPU.

Sera un problema adicional de la nueva version?

Saludos

hgmnetwork

javier gracias por responder rapido

la verdad que yo sepa no, instale el issabel directo por el comando de descarga de la web y lo actulice no he instalado nada mas. si me indicas como puedo eliminarlo o saber si esta instalado lo quito ya que no lo utilizamos para nada

venturinog

hgmnetwork De nada!
rpm -qa | grep openfire
Ese comando te dira si esta instalado
yum remove openfire para sacarlo.

hgmnetwork

venturinog

esto es lo que me aparece

[root@voz ~]# rpm -qa | grep openfire
error: db5 error(-30986) de dbcursor->c_get: BDB0075 DB_PAGE_NOTFOUND: Requested page not found
[root@voz ~]#

venturinog

hgmnetwork Esta corrupta o rota la DB de rpm, muy raro. No estara fallando el disco?

hgmnetwork

pues no se si puedo averiguarlo con algun comando o chequear el disco o reparar la db pero el servidor funciona sin problema, como puedo revisarlo ?

es decir lo reinicio y funciona bien ahora lleva 12 horas funcionando y sin problema vi que se activo el 003 ese lo mate al proceso y elimine todo del /tmp y de momento no ha vuelto a pasar pero ayer paso y dias atras tambien

hice un rpm -vv --rebuilddb y ahora no me da error pero no sale nada
[root@voz ~]# rpm -qa | grep openfire
[root@voz ~]#

venturinog

hgmnetwork Podrias bootear un instalador de Issabel o Centos 7 en rescue mode y correr fsck

hgmnetwork

voy a ver si puedo hacerlo aunque no tengo ninguno ya que instale directo el servidor con el centos7 minimal y luego lo del issabel a ver si puedo descargar alguno y lo pruebo

o no se si hay forma de hacer que lo ejecute al reiniciarlo con algun comando y asi veo el resultado en la pantalla o por terminal o algo.

Lo raro es que funciona todo perfectamente no hay errores ni similar.

javier

cuando esta operando el servidor, ejecutando el comando dmesg o en /var/log/message, te muestra algun error?

hgmnetwork

hola, he probado a ver el /var/log/messajes y he localizado errores muy raros se los copio
Jan 29 13:00:31 voz kernel: dialerd[19359]: segfault at 8000000 ip 0000558b683ab659 sp 00007ffe4fa00a90 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:32 voz kernel: dialerd[19360]: segfault at 7f3380049070 ip 0000558b683ab659 sp 00007ffe4fa00ab0 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:32 voz kernel: dialerd[19361]: segfault at 63000000 ip 0000558b683ab659 sp 00007ffe4fa00af0 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:33 voz kernel: dialerd[19362]: segfault at 3b000040 ip 0000558b68398689 sp 00007ffe4fa031d0 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:33 voz kernel: dialerd[19309]: segfault at 7f3300846b78 ip 0000558b68362cb0 sp 00007ffe4fa03400 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:36 voz kernel: dialerd[19363]: segfault at 6000000 ip 0000558b68396668 sp 00007ffe4fa03140 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:36 voz kernel: dialerd[19364]: segfault at 7f33820585f8 ip 0000558b683ab659 sp 00007ffe4fa00af0 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:36 voz kernel: dialerd[4220]: segfault at 0 ip 0000558b6838586f sp 00007ffe4fa03010 error 4 in php[558b6811e000+3c8000]
Jan 29 13:00:37 voz kernel: dialerd[4167]: segfault at ec000000 ip 00000000ec000000 sp 00007ffe4fa03588 error 14 in php[558b6811e000+3c8000]
Jan 29 13:05:01 voz kernel: php[19443]: segfault at 7f230012bea0 ip 00007f23dd31b6df sp 00007fff57e02630 error 4 in ld-2.17.so[7f23dd312000+21000]
Jan 29 13:06:17 voz kernel: dialparties.agi[19455]: segfault at 62000004 ip 0000560fa6c8a7ba sp 00007fffedb813f0 error 4 in php[560fa6a11000+3c8000]
Jan 29 13:06:48 voz kernel: postdrop[19467]: segfault at 7f7300590836 ip 00007f7300590836 sp 00007ffd5a9c6568 error 14 in libnss_files-2.17.so[7f731af4f000+c000]
Jan 29 13:06:48 voz kernel: trivial-rewrite[19470]: segfault at 5652ff2cceb0 ip 00005652ff2cceb0 sp 00007fff2f6a8e98 error 14 in libnss_files-2.17.so[7f2eec04b000+c000]
Jan 29 13:06:48 voz kernel: hangup.agi[19474]: segfault at 33000040 ip 000055ed7ece8215 sp 00007fff5b797ec0 error 4 in php[55ed7ea6f000+3c8000]
Jan 29 13:07:15 voz kernel: dialparties.agi[19480]: segfault at 7fa1ff5a1df0 ip 000055cd0b9f6659 sp 00007ffc67c267a0 error 4 in php[55cd0b769000+3c8000]
Jan 29 13:07:37 voz kernel: hangup.agi[19493]: segfault at 7fc5f7ca9210 ip 00007fc5f7ca9210 sp 00007ffcf521eef8 error 14
Jan 29 13:07:50 voz kernel: dialparties.agi[19498]: segfault at 562c9eacc1d0 ip 0000562cbcf81668 sp 00007ffe47f85790 error 4 in php[562cbcd09000+3c8000]
Jan 29 13:08:58 voz NetworkManager[632]: <info> [1517227738.5603] device (wlp0s26f7u3): set-hw-addr: set MAC address to 4A:F6:50:06:BC:A0 (scanning)
Jan 29 13:09:00 voz kernel: IPv6: ADDRCONF(NETDEV_UP): wlp0s26f7u3: link is not ready
Jan 29 13:09:00 voz NetworkManager[632]: <info> [1517227740.4678] device (wlp0s26f7u3): supplicant interface state: inactive -> disconnected
Jan 29 13:09:00 voz NetworkManager[632]: <info> [1517227740.5043] device (wlp0s26f7u3): supplicant interface state: disconnected -> inactive
Jan 29 13:10:01 voz systemd: Started Session 41 of user root.
Jan 29 13:10:01 voz systemd: Starting Session 41 of user root.
Jan 29 13:10:01 voz systemd: Started Session 42 of user root.
Jan 29 13:10:01 voz systemd: Starting Session 42 of user root.
Jan 29 13:10:01 voz kernel: php[19522]: segfault at ff000040 ip 00005631beac7215 sp 00007ffccd653d70 error 4 in php[5631be84e000+3c8000]
Jan 29 13:11:27 voz kernel: sh[19537]: segfault at 7f7bffc8ce50 ip 00007f7b18ec16d7 sp 00007fff0e56af50 error 4 in ld-2.17.so[7f7b18eb8000+21000]
Jan 29 13:11:27 voz kernel: sh[19539]: segfault at 7f7bffc8ce50 ip 00007f7b18ec16d7 sp 00007fff0e56af50 error 4 in ld-2.17.so[7f7b18eb8000+21000]
Jan 29 13:11:27 voz kernel: sh[19536]: segfault at 7f7bff0d896d ip 00007f7b18ec16ab sp 00007fff0e56b410 error 4 in ld-2.17.so[7f7b18eb8000+21000]
Jan 29 13:14:15 voz NetworkManager[632]: <info> [1517228055.5602] device (wlp0s26f7u3): set-hw-addr: set MAC address to 72:CB:E0:50:31:0A (scanning)

y aparte dentro del /tmp me ha creado estos ficheros
[root@voz tmp]# ls -lha
total 40M
drwxrwxrwt. 14 root root 12K ene 29 13:24 .
dr-xr-xr-x. 19 root root 4,0K ene 29 11:13 ..
-rwxrwxrwx 1 daemon daemon 2,3M ene 16 02:02 003
-rw-r--r-- 1 daemon daemon 767K ene 29 13:24 003.1
-rw-r--r-- 1 daemon daemon 1,8M ene 26 15:48 003.147
-rw-r--r-- 1 daemon daemon 2,3M ene 16 02:02 003.2
-rw-r--r-- 1 daemon daemon 2,3M ene 16 02:02 003.3
-rw------- 1 asterisk asterisk 7,1M ene 29 13:02 core.19397
-rw------- 1 asterisk asterisk 16M ene 29 13:06 core.19455
-rw------- 1 asterisk asterisk 6,7M ene 29 13:06 core.19474
-rw------- 1 asterisk asterisk 6,7M ene 29 13:07 core.19480
-rw------- 1 asterisk asterisk 15M ene 29 13:07 core.19493
-rw------- 1 asterisk asterisk 4,2M ene 29 13:07 core.19498
-rw------- 1 root root 1,4M ene 27 01:46 core.22863
-rw------- 1 root root 1020K ene 27 02:05 core.472

y se ejecuta un daemon con 003 y consume el 100% del cpu de nuevo.
Lo reinicio de todo bien sin problemas , por lo que entiendo que el disco no debe ser porque arranca sin problemas y funciona bien todo

ruego si me pueden ayudar porque no se porque se debe este error. empezo sin cambiar nada ni actualizar nada

gracias de antemano

y justo ahora paso y no deja conectar via web error mysql mire de nuevo el log y sale esto
Jan 29 13:27:47 voz kernel: issabel-helper[21055]: segfault at 40000000 ip 000055f39031e659 sp 00007ffe4ac46680 error 4 in php[55f390091000+3c8000]
Jan 29 13:27:48 voz kernel: hdmodelreport[21069]: segfault at dc000040 ip 0000559fb0f2b215 sp 00007ffe8ad436d0 error 4 in php[559fb0cb2000+3c8000]

no se si sea algo mal de issabel o del servidor o de alguna configuracion.

gracias de nuevo

hgmnetwork

revisando mas a fondo he descubierto /opt/openfire y dentro admin y dentro muchos archivos 003.xxx

he eliminado todos a ver si asi se soluciona y puesto con permisos a 0 por si se trata de algun intento de acceso o algo similar

he visto que en ese directorio hay cosas nuevas creadas y no se si es apor algun acceso o vulnerabilidad
en
[root@voz plugins]# pwd
/opt/openfire/plugins
Tiene correo nuevo en /var/spool/mail/root
[root@voz plugins]# ls -lh
total 80K
drwxr-xr-x. 3 daemon daemon 4,0K oct 9 20:03 admin
drwxr-xr-x 4 daemon daemon 4,0K ene 29 16:48 helloworld
-rw-r--r-- 1 daemon daemon 33K ene 29 16:42 helloworld.jar
drwxr-xr-x 5 daemon daemon 4,0K oct 9 22:09 search

el directorio de admin le quite todo ya que tenia dentro todo los ficjheros creados y demas y le di permisos 000 a ver si asi no ocurre o al menos descartarlo

hgmnetwork

al hacer un yum update me sale un error raro
Complementos cargados:fastestmirror
LowayResearch | 951 B 00:00:00

One of the configured repositories failed (Desconocido),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=<repoid> ...

 4. Disable the repository permanently, so yum won't use it by default. Yum
    will then just ignore the repository until you permanently enable it
    again or use --enablerepo for temporary usage:

        yum-config-manager --disable <repoid>
    or
        subscription-manager repos --disable=<repoid>

 5. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: base/$releasever/x86_64

hgmnetwork

por si le ocurre a alguno, he desactivado y puesto a 0 y eliminado los ficheros dentro de openfire ya que no lo usamos y no entendemos porque tenian esos ficheros y de momento no ha vuelto a pasar, apenas llevamos un par de horas pero iremos revisando a ver si ocurre de nuevo ya lo unico que se nos ocurre es formatear e instalar todo desde 0, a ver si tenemos suerte y se soluciona.

hgmnetwork

Después de unas 10 horas parece todo normal por lo que estimamos que sea problema del openfire en un día o dos revisaremos pero ahora parece todo nornalsi ha lguien le sucede que desactive o eliminé el oñpenfire

hgmnetwork

Definitivamente el problema era el openfire, una vez desactivado el servidor ha regresado a la normalidad por si le ocurre a alguien que sepa como solucionarlo.