TLDR: в настоящее время вы полагаетесь на неопределенное поведение signal(2); вместо этого используйте sigaction (осторожно).

Во-первых, SIGCHLD странный. Со страницы руководства для sigaction;

POSIX.1-1990 запрещает устанавливать действие для SIGCHLD на SIG_IGN. POSIX.1-2001 допускает такую ​​возможность, поэтому игнорирование SIGCHLD можно использовать для предотвращения создания зомби (см. wait(2)). Тем не менее, историческое поведение BSD и System V для игнорирования SIGCHLD различается, так что единственный полностью переносимый метод обеспечения того, чтобы завершенные дочерние элементы не стали зомби, состоит в том, чтобы перехватить сигнал SIGCHLD и выполнить wait(2) или подобное.

А вот фрагмент с страницы руководства wait(2):

POSIX.1-2001 указывает, что если расположение SIGCHLD установлено в SIG_IGN или флаг SA_NOCLDWAIT установлен для SIGCHLD (см. sigaction(2)), то дочерние элементы, которые завершаются, не становятся зомби, и вызов wait() или waitpid() будет блокироваться до тех пор, пока все дочерние процессы завершаются, а затем завершаются с ошибкой, установленной на ECHILD. (Исходный стандарт POSIX оставил поведение при установке SIGCHLD на SIG_IGN неопределенным. Обратите внимание, что хотя расположение SIGCHLD по умолчанию — «игнорировать», явное задание расположения SIG_IGN приводит к другому обращению с дочерними процессами-зомби.) Linux 2.6 соответствует этому Технические характеристики. Однако в Linux 2.4 (и более ранних версиях) этого не происходит: если вызов wait() или waitpid() выполняется, когда SIGCHLD игнорируется, вызов ведет себя так же, как если бы SIGCHLD не игнорировался, то есть вызов блокируется до завершения следующего дочернего элемента, а затем возвращает идентификатор процесса и статус этого дочернего элемента.

Обратите внимание, что эффект от этого заключается в том, что если обработка сигнала ведет себя так, как установлено SIG_IGN, то (в Linux 2.6+) вы увидите поведение, которое вы видите, то есть wait() вернет -1 и ECHLD, потому что дочерний элемент будет автоматически собран.

Во-вторых, обработка сигналов с помощью pthreads (которую, я думаю, вы используете здесь) общеизвестно сложна. То, как это должно работать (как я уверен, вы знаете), заключается в том, что сигналы, направленные процессом, отправляются в произвольный поток внутри процесса, в котором сигнал разоблачен. Но в то время как потоки имеют свою собственную сигнальную маску, существует обработчик действий всего процесса.

Объединив эти две вещи, я думаю, вы столкнулись с проблемой, с которой я сталкивался раньше. У меня были проблемы с обработкой SIGCHLD для работы с signal() (что достаточно справедливо, поскольку это было объявлено устаревшим до pthreads), которые были исправлены путем перехода к sigaction и тщательной настройки масок сигналов для каждого потока. В то время я пришел к выводу, что библиотека C эмулирует (с sigaction) то, что я говорил ей делать с signal(), но pthreads сбивает ее с толку.

Обратите внимание, что в настоящее время вы полагаетесь на неопределенное поведение. На странице руководства signal(2):

Влияние signal() на многопоточный процесс не указано.

Вот что я рекомендую вам сделать:

1. Перейдите к sigaction() и pthread_sigmask(). Явно задайте обработку всех сигналов, которые вам нужны (даже если вы считаете, что это текущее значение по умолчанию), даже при установке их на SIG_IGN или SIG_DFL. Я блокирую сигналы, пока делаю это (возможно, чрезмерная осторожность, но я откуда-то скопировал пример).

Вот что я делаю (примерно):

sigset_t set;
struct sigaction sa;

/* block all signals */
sigfillset (&set);
pthread_sigmask (SIG_BLOCK, &set, NULL);

/* Set up the structure to specify the new action. */
memset (&sa, 0, sizeof (struct sigaction));
sa.sa_handler = handlesignal;        /* signal handler for INT, TERM, HUP, USR1, USR2 */
sigemptyset (&sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGINT, &sa, NULL);
sigaction (SIGTERM, &sa, NULL);
sigaction (SIGHUP, &sa, NULL);
sigaction (SIGUSR1, &sa, NULL);
sigaction (SIGUSR2, &sa, NULL);

sa.sa_handler = SIG_IGN;
sigemptyset (&sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGPIPE, &sa, NULL);     /* I don't care about SIGPIPE */

sa.sa_handler = SIG_DFL;
sigemptyset (&sa.sa_mask);
sa.sa_flags = 0;
sigaction (SIGCHLD, &sa, NULL);     /* I want SIGCHLD to be handled by SIG_DFL */

pthread_sigmask (SIG_UNBLOCK, &set, NULL);

2. По возможности установите все ваши обработчики сигналов, маски и т. д. перед любыми pthread операциями. По возможности не меняйте обработчики сигналов и маски (вам может понадобиться сделать это до и после вызовов fork()).

3. Если вам нужен обработчик сигнала для SIGCHLD (вместо того, чтобы полагаться на SIG_DFL), по возможности, пусть он будет получен любым потоком, и используйте метод self-pipe или аналогичный для оповещения основной программы.

4. Если у вас должны быть потоки, которые обрабатывают/не обрабатывают определенные сигналы, попробуйте ограничить себя pthread_sigmask в соответствующем потоке, а не sig* вызовами.

5. На всякий случай, если вы сломя голову столкнетесь со следующей проблемой, с которой я столкнулся, убедитесь, что после того, как у вас есть fork(), вы снова настроили обработку сигналов с нуля (в дочернем), а не полагаетесь на то, что вы можете унаследовать от родительского процесса . Если и есть что-то хуже, чем сигналы, смешанные с pthread, так это сигналы, смешанные с pthread с fork().

Обратите внимание, что я не могу полностью объяснить, почему изменение (1) работает, но оно устранило то, что выглядит очень похожей для меня проблемой, и, в конце концов, полагалось на что-то, что ранее было «неопределенным». Это ближе всего к вашей «гипотезе 2», но я думаю, что это действительно неполная эмуляция устаревших сигнальных функций (в частности, имитация ранее колоритного поведения signal(), что в первую очередь привело к его замене на sigaction() - но это всего лишь предположение ).

Кстати, я предлагаю вам использовать wait4() или (поскольку вы не используете rusage) waitpid(), а не wait3(), чтобы вы могли указать конкретный PID для ожидания. Если у вас есть что-то еще, что генерирует дочерние элементы (у меня это была библиотека), вы можете ждать не того, что нужно. Тем не менее, я не думаю, что это то, что здесь происходит.