Eu tenho um programa (C ++) que funciona com sockets TCP de maneira multithread. O multithreading é intensivo, cerca de 100 threads (threads POSIX).
Às vezes, não tenho certeza quando, o programa é finalizado por SIGTERM . Depois de algum googling, descobri que não é normal que o sistema envie SIGTERM . Eu decidi olhar o que acontece se eu ignorar o sinal. Agora o sistema envia SIGKILL . Eu suponho que tente com SIGTERM e quando o aplicativo não terminar, o sistema o mata.
Eu tentei executá-lo no gdb e não recebi nenhum sinal.
Eu corri em valgrind, sem sinais. Nenhum erro valgrind também. Consumo de memória foi normal, parece que não tenho vazamentos de memória. Na saída, o heap tinha 7Mb em uso.
Nada suspeito em /var/log/messages, /var/log/syslogd .
O sistema é Debian 2.6.32-5.
Basicamente, a questão é por que o sistema pode enviar SIGTERM seguido por SIGKILL para um processo arbitrário? E como posso parar nesse ponto para ver o que acontece (o gdb altera o comportamento).
'sistema' é um termo muito ambíguo. Se estamos falando do kernel, o kernel nunca enviará um SIGTERM. Ele enviará SIGKILL quando o killer da OOM for chamado.
O cenário provável é um script ou algo que tenha um mau comando pkill ou killall que esteja correspondendo inadequadamente ao seu processo. Quando você inicia o comando com gdb , o nome do processo & argumentos são diferentes, então seria diferente para o pkill / killall .
Pegue um script systemtap e monitore a entrega de sinal. A abordagem mais simples que pode ser suficiente é, e. aqui: link
Pode ser estendido para, e. imprima a árvore inteira do processo do assassino.
Um script melhor não monitora o syscall, mas o lugar onde o sinal é realmente entregue. Chegar com esse roteiro é deixado como um exercício para o leitor.
Tags linux signals multithreading