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

[Alvaro Uría]

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?

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?

> 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

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'.

> Saludos --- Angel

Saludos,
-- 
    ,____________,
    .'          '.
   /~~~~^~~~^~^~~~\
  /      _    /||  \  Alvaro Uría (0x5109E791)
 ;      ( }   \||D  ;  <fermat at movimage.com>
 |    | /\__,=[_]   |  
 ;  ( |_\_  |---|   ;  Don't make me use uppercase...
  \  )|  |/ |   |  / 
   '. |  /_ |   |.'
    '------------'
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 189 bytes
Descripción: Digital signature
Url        : https://listas.deusto.es/mailman/private/eside-ghost/attachments/20060301/f4228cb7/attachment.bin