¿Cómo verificar qué límite se superó? (Proceso terminado debido a ulimit.)

Supongamos que el proceso se ejecuta en un entorno limitado:

(
ulimit  ... -v ... -t ... -x 0 ...
./program
)

El programa ha finalizado.

Puede haber muchas razones: memoria / tiempo / límite de archivo excedido; simplemente segfault simple; o incluso terminación normal con el código de retorno 0.

¿Cómo verificar cuál fue el motivo de la finalización del programa, sin modificar el programa?

PD Me refiero a "cuando se da binario". ¿Tal vez algún envoltorio (trazado, etc.) podría ayudar?

Hablando en general, no creo que puedas desafortunadamente. (Algunos sistemas operativos pueden proporcionarlo, pero no conozco los que sé que lo respaldan).

Documento de referencia para límites de recursos: getrlimitde POSIX 2008.

Tomemos, por ejemplo, el límite de la CPU RLIMIT_CPU.

• Si el proceso excede el límite flexible, se envía un SIGXCPU
• Si el proceso excede el límite estricto, se obtiene un claro SIGKILL

Si puede wait()en su programa, podría decir si fue asesinado por SIGXCPU. Pero no se podía diferenciar un SIGKILLdespacho por incumplimiento del límite estricto de una vieja matanza desde afuera. Además, si el programa maneja el XCPU, ni siquiera lo verá desde afuera.

Lo mismo para RLIMIT_FSIZE. Se puede ver la SIGXFSZdel wait()estado si el programa no manejarlo. Pero una vez que se excede el límite de tamaño de archivo, lo único que sucede es que más E / S que intente probar ese límite nuevamente simplemente recibirán EFBIG, esto será manejado (o no, desafortunadamente) por el programa internamente. Si el programa maneja SIGXFSZ, igual que el anterior, no lo sabrá.

RLIMIT_NOFILE? Bueno, ni siquiera recibes una señal. openy amigos acaban de regresar EMFILEal programa. No se molesta de otra manera, por lo que fallará (o no) de cualquier manera que se codificó para fallar en esa situación.

RLIMIT_STACK? Muy bien SIGSEGV, no se puede distinguir de la puntuación de otras razones para obtener uno. (Sin embargo, sabrá que eso fue lo que mató el proceso, por el waitestado).

RLIMIT_ASy RLIMIT_DATAsolo se producirá malloc()y algunos otros comenzarán a fallar (o recibirán SIGSEGVsi se alcanza el límite AS al intentar extender la pila en Linux). A menos que el programa esté muy bien escrito, probablemente fallará de manera bastante aleatoria en ese punto.

En resumen, en general, las fallas no son visiblemente diferentes de otras razones de muerte del proceso, por lo que no puede estar seguro o puede manejarse completamente desde el programa, en cuyo caso decide si / cuándo / cómo procede, no usted desde fuera.

Hasta donde sé, lo mejor que puede hacer es escribir un código que bifurca su programa, lo espera y:

• verifique el estado de salida para detectar SIGXCPUy SIGXFSZ(AFAIK, esas señales solo serán generadas por el sistema operativo para problemas de límite de recursos). Dependiendo de sus necesidades exactas, podría suponer eso SIGKILLy SIGSEGVtambién estar relacionado con los límites de recursos, pero eso es un poco exagerado.
• mire lo que puede obtener de getrusage(RUSAGE_CHILDREN,...)su implementación para obtener una pista sobre los otros.

Es posible que existan recursos específicos del sistema operativo para ayudar aquí (posiblemente cosas como ptraceen Linux o Solaris dtrace), o posiblemente técnicas de tipo depurador, pero eso estará aún más vinculado a su implementación específica.

(Espero que alguien más responda con algo mágico que desconozco por completo).

Actualmente estoy trabajando en el mismo tema. He podido tener una solución parcial. He usado el subsistema de auditoría . Puedes seguir el trabajo en [1].

[1] https://github.com/PaulDaviesC/Logging-limits.conf