¿Qué mató mi proceso y por qué?

Mi aplicación se ejecuta como un proceso en segundo plano en Linux. Actualmente se inicia en la línea de comando en una ventana de Terminal.

Recientemente, un usuario estaba ejecutando la aplicación por un tiempo y murió misteriosamente. El texto:

Delicado

Estaba en la terminal. Esto sucedió dos veces. Pregunté si alguien en una Terminal diferente usó el comando kill para matar el proceso. No.

¿En qué condiciones Linux decidiría matar mi proceso? Creo que el caparazón se mostró "asesinado" porque el proceso murió después de recibir la señal de matar (9). Si Linux envió la señal de apagado, ¿debería haber un mensaje en un registro del sistema en algún lugar que explique por qué fue eliminado?

Si el usuario o el administrador del sistema no mataron el programa que el kernel puede tener. El kernel solo mataría un proceso en circunstancias excepcionales, como la falta de recursos extrema (piense en mem + agotamiento de intercambio).

Tratar:

dmesg -T| grep -E -i -B100 'killed process'

Donde -B100significa el número de líneas antes de que ocurriera la muerte.

Omitir -T en Mac OS.

Esto parece un buen artículo sobre el tema: domar al asesino OOM .

La esencia es que Linux compromete demasiadomemoria. Cuando un proceso solicita más espacio, Linux le dará ese espacio, incluso si es reclamado por otro proceso, bajo el supuesto de que nadie realmente usa toda la memoria que solicita. El proceso obtendrá un uso exclusivo de la memoria que ha asignado cuando realmente lo usa, no cuando lo solicita. Esto hace que la asignación sea rápida y puede permitirle "engañar" y asignar más memoria de la que realmente tiene. Sin embargo, una vez que los procesos comiencen a usar esta memoria, Linux podría darse cuenta de que ha sido demasiado generoso al asignar memoria que no tiene, y tendrá que eliminar un proceso para liberar algo. El proceso que debe eliminarse se basa en una puntuación que tiene en cuenta el tiempo de ejecución (los procesos de ejecución prolongada son más seguros), el uso de memoria (los procesos codiciosos son menos seguros) y algunos otros factores, incluido un valor que puede ajustar para hacer que un proceso sea menos probable que se elimine. Todo se describe en el artículo con mucho más detalle.

Editar: Y aquí hay otro artículo que explica bastante bien cómo se elige un proceso (anotado con algunos ejemplos de código de kernel). Lo bueno de esto es que incluye algunos comentarios sobre el razonamiento detrás de las diversas badness()reglas.

Permítanme explicar primero cuándo y por qué se invoca a OOMKiller.

Digamos que tiene 512 RAM + 1GB de memoria de intercambio. Entonces, en teoría, su CPU tiene acceso a un total de 1.5GB de memoria virtual.

Ahora, durante algún tiempo, todo funciona bien dentro de 1,5 GB de memoria total. Pero de repente (o gradualmente) su sistema ha comenzado a consumir más y más memoria y alcanzó un punto en torno al 95% de la memoria total utilizada.

Ahora supongamos que cualquier proceso ha solicitado una gran cantidad de memoria del núcleo. Kernel verifica la memoria disponible y descubre que no hay forma de que pueda asignar más memoria a tu proceso. Por lo tanto, intentará liberar memoria invocando / invocando OOMKiller ( http://linux-mm.org/OOM ).

OOMKiller tiene su propio algoritmo para calificar el rango de cada proceso. Por lo general, qué proceso usa más memoria se convierte en la víctima a matar.

¿Dónde puedo encontrar registros de OOMKiller?

Típicamente en el directorio / var / log. /Var/log/kern.log o / var / log / dmesg

Espero que esto te ayudará.

Algunas soluciones típicas:

1. Aumentar la memoria (no cambiar)
2. Encuentra las pérdidas de memoria en tu programa y arréglalas
3. Restrinja la memoria que cualquier proceso puede consumir (por ejemplo, la memoria JVM puede restringirse usando JAVA_OPTS)
4. Ver los registros y google :)

Este es el administrador de Linux sin memoria (OOM) . Su proceso fue seleccionado debido a ' maldad ': una combinación de actualidad, tamaño de residente (memoria en uso, en lugar de solo asignada) y otros factores.

sudo journalctl -xb

Verás un mensaje como:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

Como dwc y Adam Jaskiewicz han declarado, el culpable es probablemente el Asesino OOM. Sin embargo, la siguiente pregunta que sigue es: ¿Cómo evito esto?

Hay varias formas:

1. Dele a su sistema más RAM si puede (fácil si es una VM)
2. Asegúrese de que el asesino de OOM elija un proceso diferente.
3. Deshabilitar el asesino OOM
4. Elija una distribución de Linux que se envíe con el OOM Killer deshabilitado.

Descubrí que (2) es especialmente fácil de implementar, gracias a este artículo .

El módulo PAM para limitar los recursos causó exactamente los resultados que describió: mi proceso murió misteriosamente con el texto Asesinado en la ventana de la consola. No hay salida de registro, ni en syslog ni en kern.log . El programa superior me ayudó a descubrir que exactamente después de un minuto de uso de la CPU, mi proceso se anula.

Una herramienta como systemtap (o un trazador) puede monitorear la lógica de transmisión de señal del núcleo e informar. por ejemplo, https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

El ifbloque de filtrado en ese script puede ajustarse al gusto o eliminarse para rastrear el tráfico de señal en todo el sistema. Las causas pueden aislarse aún más mediante la recopilación de trazas inversas (agregue ay print_backtrace()/ o print_ubacktrace()a la sonda, para el núcleo y el espacio de usuario, respectivamente).

En un entorno lsf (interactivo o de otro tipo) si la aplicación excede la utilización de la memoria más allá de un umbral preestablecido por los administradores en la cola o la solicitud de recursos al enviar a la cola, los procesos serán eliminados para que otros usuarios no sean víctimas de un potencial huir. No siempre envía un correo electrónico cuando lo hace, dependiendo de cómo esté configurado.

Una solución en este caso es encontrar una cola con recursos más grandes o definir requisitos de recursos más grandes en el envío.

Es posible que también desee revisar man ulimit

Aunque no recuerdo haber ulimitresultado en que Killedhaya pasado un tiempo desde que lo necesitaba.

Hemos tenido problemas recurrentes bajo Linux en el sitio de un cliente (Red Hat, creo), con OOMKiller (asesino sin memoria) matando tanto nuestra aplicación principal (es decir, la razón por la que existe el servidor) como sus procesos de base de datos.

En cada caso, OOMKiller simplemente decidió que los procesos usaban muchos recursos ... la máquina ni siquiera estaba a punto de fallar por falta de recursos. Ni la aplicación ni su base de datos tienen problemas con pérdidas de memoria (o cualquier otra pérdida de recursos).

No soy un experto en Linux, pero más bien reuní su algoritmo para decidir cuándo matar algo y qué matar es complejo. Además, me dijeron (no puedo hablar de la precisión de esto) que OOMKiller está integrado en el Kernel y que no se puede simplemente no ejecutarlo.

En mi caso, esto estaba sucediendo con un trabajador de cola Laravel. Los registros del sistema no mencionaron ningún asesinato, así que busqué más y resultó que el trabajador básicamente se estaba suicidando debido a un trabajo que excedía el límite de memoria (que está configurado en 128M por defecto).

Ejecutando el trabajador de cola con --timeout=600y --memory=1024solucionó el problema para mí.

El usuario tiene la capacidad de matar sus propios programas, usando kill o Control + C, pero tengo la impresión de que no es lo que sucedió, y que el usuario se quejó a usted.

root tiene la capacidad de matar programas, por supuesto, pero si alguien tiene root en su máquina y está matando cosas, tiene mayores problemas.

Si no es el administrador del sistema, el administrador del sistema puede haber configurado cuotas en la CPU, la RAM, el uso del disco ort y los procesos de eliminación automática que los superan.

Aparte de esas conjeturas, no estoy seguro sin más información sobre el programa.

Encontré este problema últimamente. Finalmente, descubrí que mis procesos se interrumpieron justo después de que se llamara automáticamente a la actualización de Opensuse zypper. Para deshabilitar la actualización de zypper resolvió mi problema.

Resolvió este problema aumentando el tamaño del intercambio :

/ubuntu/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04