Обработчик macOS sigaction () с SA_SIGINFO не включает si_pid

Сейчас я использую macOS Mojave 10.14.1.

How can I get the pid of the process sending the signal on macOS 10.14? I don't recall having this issue on 10.12 which is what I was using before.

Следующий код просто соответствует вашему желанию. Если вы отправляете SIGTERM, вы можете увидеть pid процесса отправителя.

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <string.h>

static void hdl (int sig, siginfo_t *siginfo, void *context)
{
    printf ("Sending PID: %ld, UID: %ld\n",
            (long)siginfo->si_pid, (long)siginfo->si_uid);
}

int main (int argc, char *argv[])
{
    struct sigaction act;

    fprintf(stderr, "%i pp %i\n",getpid(), getppid());

    memset (&act, '\0', sizeof(act));

    /* Use the sa_sigaction field because the handles has two additional parameters */
    act.sa_sigaction = &hdl;

    /* The SA_SIGINFO flag tells sigaction() to use the sa_sigaction field, not sa_handler. */
    act.sa_flags = SA_SIGINFO;

    if (sigaction(SIGTERM, &act, NULL) < 0) {
        perror ("sigaction");
        return 1;
    }

    while (1)
        sleep (10);

    return 0;
}

Для вашего кода

Rule of thumb: Don't forget to carry burial procedures out even though you are sure that child process ends prior parent process. By invoking wait(...) you tell the operating system that I'm done my things for my child so now you can clean allocated fields etc.

Я бы предпочел инициализировать сигнальные утилиты перед разветвлением. А что, если родительский процесс не имеет возможности зарегистрировать сигнальное действие? Более того, я не понимаю, зачем вы обрабатываете кейсы 0 и 1 в switch. По сути дела, случаи не затрагиваются, поэтому всегда опускаются.

Кроме того, вы не использовали break в своем состоянии if в main(). Через некоторое время она не попадает в if, но следующее обстоятельство, которое не ожидается и желательно, заключается в том, что программа навсегда остается в цикле while(). Я бы предпочел привести signaled в состояние петли while().

Наконец, что не менее важно, из-за вызова sleep() в дочернем процессе, пока signaled не выключен, 0, SIGTERM успешно ловится несколько раз. Когда сигнализируется 0, цикл останавливается.

#include <unistd.h>
#include <signal.h>
#include <stdio.h>
#include <memory.h>
#include <sys/wait.h>

volatile sig_atomic_t histogram[3] = {0,0,0};
volatile sig_atomic_t signaled = 0;
const int testsig = SIGTERM;

void sigaction_handler(int sig, siginfo_t* info, void* context)
{
    switch (info->si_pid) {
    case 0:
    case 1:
        histogram[info->si_pid]++;
        break;

    default:
        fprintf(stderr, "sender pid -> %i\n", info->si_pid);
        histogram[2]++;
        break;
    }
    signaled = 1;
}

int main(int argc, const char * argv[]) {


    struct sigaction sigAction;
    memset( &sigAction, 0, sizeof( sigAction ) );

    sigAction.sa_sigaction = sigaction_handler;
    sigemptyset (&sigAction.sa_mask);
    sigAction.sa_flags = SA_SIGINFO;
    sigaction(testsig, &sigAction, NULL);

    pid_t mainpid = getpid();
    pid_t pid = fork();
    if (pid == 0) {
        fprintf(stderr, "my pid -> %i parent's pid-> %i\n", getpid(), getppid());
        if (kill(mainpid, 0) == 0) { // signals are not queued not need loop
            sleep(1);
            kill(mainpid, testsig);
        }
        _exit(0);
    } else {

        wait(NULL); // play with this line to see what the difference is
        while ( signaled ) {
            printf("pid 0: %d, pid 1: %d, others: %d\n", histogram[0], histogram[1], histogram[2]);
            signaled = 0;
            sleep(1);
        }
        // wait(NULL); // play with this line to see what the difference is

    }
}

Оказывается, виновата отладка через Xcode LLDB. Если я собираю и запускаю программу в обычном режиме, она работает нормально. Если узнаю, зачем обновлю этот ответ.

У меня уже есть «PASS», установленный для SIGTERM в lldb, как указано в вопросе, поэтому кажется, что каким-то образом есть ошибка в версии lldb, поставляемой с Xcode 10.0, и он «передает» сигнал, создавая новую структуру и установка номера сигнала, а не структуры, которая обычно была бы получена. Как я уже говорил ранее, раньше это работало нормально в любой версии lldb, поставляемой с macos 10.12.

Если у кого-то есть более подробное объяснение, отправьте ответ, и я приму награду и вручу награду.