SIGSEGV

Наверное ядро пишет в лог те сегфолты, которые посылает приложению само (то есть в момент отправки).

Те что само послала, но ты можешь выставить kernel.print-fatal-signals

Какая программа в здравом уме сама себе шлёт SIGSEGV? :) Ядро это шлёт, ядро... После того, в процессе этой программы general protection fault проявляется, отлов которого, как известно, является прерогативой и святой обязанностью ядра.

Я это и имел в виду, что ядро посылает сигнал. Просто написал коряво.

sysctl kernel.print-fatal-signals kernel.print-fatal-signals = 0

какие там возможные варианты?

ТС удивился что если руками сигнал послать то в логах нет записи

0 или 1

я не то что бы удивлился но хотел бы четкого описания явления, вот скажем про kernel.print-fatal-signals я не знал, да и сейчас не совсем ясно что оно дает)

как SIGSEGV смоделировать ясно:

char *p = NULL;
*p = 0;

а как смоделировать SIGPIPE? SIGABRT?

abort();

какой именно у тебя вопрос по kernel.print-fatal-signals? Ж)

понятно, включил теперь в лог все валится, спасибо

kill -PIPE/kill -ABRT :)

>Какая программа в здравом уме сама себе шлёт SIGSEGV? :)

Я видел одну, которая сама в себе имитирует сегфолт, получив... SIGQUIT (Вроде упр. передается на пустой указатель функции, как-то так. Может не доимплементили какой-то хэндлер, история умалчивает), а завершается, внезапно, по SIGALRM, при этом падает в кору в дебажной сборке, когда все уже вроде бы завершено (какие-то глобальные статики удаляются, вызывая разрыв мну у glibc) Чтоб сама себе слала - не видел :)

>kill -PIPE/kill -ABRT :)

это я еще в первом сообщении описывал, это не ядро пошлет а я с помощью kill, я говорил о том чтобы смоделировать такую ситуацию когда ядро пошлет этот сигнал

причем если сигнал например SIGSEGV перехватить своим обработчиком то послав сигнал ядро не делает запись в лог

если ты перехваешь сигнал то ядро думает что это штатная фича твоего приложения, поэтому и не пишет :)