/* становимся демоном */
pid = fork();
if (pid == 0) {
    /* дочерний */
    /* убиваем родителя SIGTERM*/
else if (pid > 0) {
    /* родитель */
    /* ставим обработчик сигнала SIGTERM и ждем
       этого сигнала */
} else {
    /* ошибка */
}

Проблема в том, что потомок убивает родителя раньше, чем тот ставит обработчик сигнала.
Вопрос допустимо-ли это, или-же это проблема с системой? (linux-2.4.X glibc-2.2.X).
Из-за этого некорректно стартует (в частности) syslog-ng. И похоже, что по той-же причине падает lsh.
Что вы можете ответить?

• RE: fork: странное поведение,Арлекин, 12:02 , 18-Май-01
  • RE: fork: странное поведение,slava, 12:25 , 18-Май-01
  • RE: fork: странное поведение,XMan, 17:41 , 19-Май-01

Если значение pid_t определено до вызова, то ты застрянешь на signal()( fork() тоже там шарится ) - попробуй установить SIGTERM непосредственно перед вызовом fork(), ибо
fork() не может ( не должен )вернуть > 0 .
Удачно он вертает 0 , а неудачно -1.

Так вот.

Дело в том, что один и тот-же бинарник нормально работает на linux-2.2.X, glibc-2.1.X, но криво на 2.4.X glibc-2.2.X. Все программы не исправить, да и не программер я. Хотелось-бы узнать, нормально-ли такое поведение, или же нет и проблема в самой системе...

fork() может и должен возвращать >0 процессу-родителю. Это пид нового процесса-потомка. Собственно, таким образом и распознаются процессы потомок и родитель - потомку возвращается 0, а родителю возвращается пид нового процесса.
Что касается преждевременного SIGTERM - ничем не помогу. Вполне вероятно, что потомок посылает этот сигнал до того, как родитель установит обработчик. Ведь эти процессы выполняются независимо друг от друга и никак не синхронизированы между собой.
У меня на RH 7.0 с ядром 2.4.2 пока все работает нормально.

Жаль, что народ поступил при написании программы именно так. Я предпочитаю сначала устанавливать все обработчики и нужные данные, а потом уже можно форкаться или нити порождать.