[eside-ghost] [solucion] oom-killer , ¿quien es este?

[AngelD]

On Wed, March 1, 2006 02:09, Alvaro Uría wrote:
> Jel-looo! :D
>
> AngelD [28/02/06 12:01 +0100] escribió:
>
>> El problema empieza cuando se tiene muchísima memoria y swap, y el
>> oom-killer aparece de forma aleatoria. El ampliar la swap parece no
>> arreglar el problema, y los logs sólo dicen que los procesos se
>> "mueren"
>> gracias a nuestro amigo.
>
> </sarcasm> XD
>
>
>> ## El problema REAL y la solución ##
>>
>>
>> Estos problemas me ocurrian con una 'Red Hat Enterprise Server 4'
>> (RHES4).
>> Esta distro trae por defecto activado el 'SElinux', unas políticas de
>> seguridad implantadas a nivel de kernel para intentar evitar ciertos
>> ataques  por problemas en las aplicaciones. Al parecer estas políticas
>> no son del todo compatibles con algunas aplicaciones y situaciones (en
>> mi caso 'oracle' realizando copias via 'rman' por NFS), y, por ahora, la
>> solución pasa por desactivar estas políticas.
>>
>> Resumientdo, al cargarme el 'SElinux' (y reiniciar) todo ha vuelto a
>> funcionar, y sin errores aleatorios.
>
> No te he entendido una cosilla... cuando tenías SELinux funcionando y
> toda la parafernalia del servidor, ¿se activaban las rutinas del
> OOM-Killer?
>
> ¿O sólo se activaban cuando intentabas hacer "rman" (¿querías decir
> rsync? o igual es pura ignorancia mía :D) a través de NFS y tal?

 Se activaban el 'oom-killer' cuando intento hacer 'rman' (es una utilidad
de oracle) a traves de NFS, y no siempre. Puede aguantar un par de días
antes de producirse el problema.

> Es que me parece distinto que el OOM entre en funcionamiento en cualquier
>  momento de carga de la máquina, o que lo haga en un determinado
> instante, muy puntual, y que igual tenía que ver con movidas de control de
> acceso que tiene ese módulo (SELinux).
>
> Dicho de otro modo, ¿qué procesos mataba el OOM-Killer?

 El 'oom-killer' entraba en funcionamiento al poner en marcha el 'rman',
pero aunque fuera precedido de algún mensaje de 'SELinux', la razón por
la que se activaba era por falta de memoria, por lo que "arrasaba" con
los procesos, llegandose a cargar desde el 'oracle' hasta el demonio del
'cron'.

>> Si alguien puede iluminarnos con algunos apuntes sobre SElinux, se
>> agradecerá, mientras tanto aquí queda el problema y la solución.
>
> Lo primero de todo, si te fijas en 'include/linux/mm.h' en las fuentes
> del kernel, ->>>>>>>>>>
> /* /proc/<pid>/oom_adj set to -17 protects from the oom-killer */
> #define OOM_DISABLE -17
> <<<<<<<<<<<
>
>
> Eso podría ser un trapi bastante chungo O:-D

 Va a ser que no, prefiero una máquina funcionando si "algún procesillo"
que una máquina "totalmente muerta" por falta de memoria.

> Lo segundo... SELinux no hace diferencia entre usuarios y superusuario.
> Con
> unos hooks que incorpora, se aplican unas políticas de seguridad a base de
>  roles y movidas así. Si no definiste una serie de "privilegios" para
> 'root',
> no tendrías acceso a "hacer cualquier cosa".
>
> Sin haber entendido lo anterior, y sabiendo _nada_ del funcionamiento
> real de SELinux, se me ocurre que igual puede tener alguna medida de
> seguridad para evitar que un usuario llene la memoria virtual (y física)
> de la máquina y le provoque un DoS. Por mucho que ese usuario sea 'root'.

 Aunque las tareas no las ejecute 'root', sospecho que los casques no se
producen por un mecanismo de seguridad para evitar un 'DoS', sino por
alguna  característica de protección de memoria de 'SElinux' que no es
del todo compatible con 'rman'. Al no ocurrir el problema hasta el tercer
día que se ejecuta el programa, se puede sospechar que no se libera la
memoria con la eficiencia debida al tener activado 'SElinux', acumulando
trozos de memoria sin liberar hasta quedarse sin ella, produciendo así el
'oom-killer'.

 Saludos --- Angel