Checking if a process has terminated?

I am confused here.

What I want to do is checking if a child process has terminated or if it is still running.
Basic, right? Well, it seems not so much.

First research seems to indicate that using waitpid can achieve this. It is important to note that I do not want to wait until a process has exited, but merely check if it has (and remove zombie processes).
The manual says that by checking the status with WIFEXITED, I should know if a process has exited by means of a return statement or exit function (at least to a degree).
Now, this confuses me since this...

Code:

---

waitpid(child, &status, (background ? WNOHANG : 0));
printf("WIFEXITED: %d, WEXITSTATUS: %d, WIFSIGNALED: %d, WTERMSIG: %d, WCOREDUMP: %d, WIFSTOPPED: %d, WSTOPSIG: %d, WIFCONTINUED: %d",
        WIFEXITED(status), WEXITSTATUS(status), WIFSIGNALED(status), WTERMSIG(status), 0/*WCOREDUMP(status)*/, WIFSTOPPED(status),
        WSTOPSIG(status), WIFCONTINUED(status));

---

(background = true)
...doesn't seem to work. WIFEXITED seems to be set to 1, even though the process is still running.
I can easily verify this by running ps.

So I thought about using waitid. Unfortunately, for some reason (perhaps the system I am using is outdated?), the siginfo_t structure and P_PID constant are undeclared in the headers (well, I tried including them, but gcc is giving me errors). So that didn't work either.

So color me confused. How do I figure out if a child has terminated and remove it as a zombie process? It doesn't matter if it exited normally or some abnormal means. Both should be detected.

Any information would be welcome.

Are you running ps and then calling waitpid()? A terminated process will still show up in the process list UNTIL someone calls waitpid() on it. Run ps again after calling waitpid(), the process should be gone. A terminated but not yet waited-for process is in "zombie" state ('Z')

EDIT: Hmm. Looks like you probably understand that. What state IS the child in?

Quote:

---

Originally Posted by brewbuck

EDIT: Hmm. Looks like you probably understand that. What state IS the child in?

---

Just running. Or so I hope.
I tested by created a test process (the process is spawned by the process that checks for it to terminate) that simply does

sleep(60);

The process shows as running before and after the waitpid call.
If it's a zombie process, it usually marks them as "degenerate" in the ps command output.

What's the return of waitpid? If that doesn't equal child (or is greater than 0 if child is one of the wildcard values) there's no point trying to make sense of status.

Ah. It returns 0, which according to the manual seems to indicate that the process whose status I am trying to query has not changed any state - IE has not quit.
Mistakes are trivial when you are still a beginner to things. You helped me out greatly, so many thanks.

Although, a question remains. Does checking for the return of waitpid == child && WIFEXITED capture the case if the process exited for some (abnormal) reason?

EDIT: It appears it does not. So what is the best way? Simply checking for all types of flags?

if I were you, I would look into signal() or sigaction(). they are the means by which unix/linux notify the parent process that something has happened to the child. you can get the child's return code and the signal (if any) that terminated the child. signal()/sigaction() handlers are not C++ exception safe, just so you know.

Well, the assignment requires me to both normal polling and signalling. So yes, I have looked into signals.
Actually, I do believe I've solved this sometime before. I found a number of problems and fixed them, and so got the polling to work reliably.
Now trying to get signal handlers to work, but still haven't been able to detect terminated processes that way. But I will find a way in due time.

what problems are you experiencing with detecting terminated processes using signals?

EDIT: just wanted to note that this was my post #666 \m/ :)

I don't get any signal when they're killed (SIGKILL).
(I do get a signal when they terminate properly.)

you don't get a signal at all? that's strange. normally you should get a signal any time the child process terminates, stops or continues. you can use the macro WIFSIGNALED(status) to determine if the child was terminated by a signal, where status is the second parameter to waitpid().

No signal at all.
I figured out how to detect killed processes otherwise when polling. That works fine.
Whenever I get a signal, I simply loop through all the processes and figure out which ones have terminated, just as I would when polling. Only I do when I get a signal instead of all the time.
Although I do tend to block the signals until it is appropriate to do the polling (to avoid interrupting sys calls and all that).
It works fine when the child exits normally, though, as I mentioned.

is it possible that your child process calls fork(), and then terminates? that would leave its child orphaned, and it would not be a child of your original process, and you would not get any signals from it, although I can't see that being a real possibility, given the behavior you mentioned. post some code?

No, I explicitly test this by starting a child process that does nothing but sleep, and then killing it with kill.

Code:

---

#ifdef SIGNALDETECTION
void child_status_change_handler(int signum)
{
        puts("Signal recieved!");
        signum = signum; // Eliminate unused warning
        check_for_terminated_processes();
}
#endif

int main()
{
        char buf[2048];

        signal(SIGCHLD, &child_status_change_handler);

        for (;;)
        {
                sighold(SIGCHLD);
                printf("Ready>");
                fgets(buf, sizeof(buf), stdin);
                sigrelse(SIGCHLD);

                const char* cmd;
                const char* arg[5];
                timeval begin;

                sighold(SIGCHLD);
                if (!get_command_and_args(buf, &cmd, arg)) goto Error;
                bool failure = (!handle_command(cmd, arg, &begin));
                sigrelse(SIGCHLD);
        }
}

---

I'll start with this. This is not the complete code, but a mini-version of it to provide an overview.
I may include check_for_terminated_processes later if deemed necessary.

I'm not sure I understand what's going on with your calls to sighold() and sigrelse(). after reading the reference for sigrelse(), it seems like calling sigrelse(SIGCHLD) would cause you to stop receiving notifications of that signal, but I could easily be misunderstanding. I've never used those functions before.

sighold will block the process from receiving signals (different from ignoring them).
sigrelse will remove this blocking, and the process will the immediately receive any signals waiting.
In other words, they just make the signal handler doesn't fire when inappropriate.

I guess that makes sense. it still doesn't make any sense why the signals wouldn't get passed when you kill the child, versus when the child terminates normally. I suspect it has to do with something you're doing in the handle_command() function, but I can't imagine what that might be.

Well, I can post more code. I just have to make you all aware that I am seeking help elsewhere (otherwise I would have been more noisy here).

OK, now I am confused. It seems I do not fully understand how signals work. Consider the example:

Code:

---

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

void child_status_change_handler(int signum)
{
        fprintf(stderr, "Signal recieved!\n");
}

int main()
{
        signal(SIGCHLD, &child_status_change_handler);
        if (fork() == 0)
                execlp("./idler", "idler", "5", NULL);
        if (fork() == 0)
                execlp("./idler", "idler", "10", NULL);

        char buf[1024];
        fprintf(stderr, "Press any key to quit...\n");
        while (fgets(buf, sizeof(buf), stdin) == NULL);
        printf("Terminating...\n");
}

---

I will receive only ONE signal. The other signal is lost in the void. Why?

Source for idler:

Code:

---

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv)
{
        fprintf(stderr, "Idler will idle for %s seconds...\n", argv[1]);
        sleep(strtol(argv[1], NULL, 10));
        fprintf(stderr, "Idler terminating...\n");
}

---

is it possible that one of the fork() calls is failing? you can check this by testing its return value < 0.

No, I get the output:

Press any key to quit...
Idler will idle for 5 seconds...
Idler will idle for 10 seconds...
Idler terminating...
Signal recieved!
Idler terminating...
gg
Terminating...

I think the received signal is canceling your request for console input. this is normal behavior for unix/linux systems. if you use sigaction() instead of signal(), you can specify that blocking system calls like that should resume instead of returning.

Imagine that!
Using sigaction instead of signal, the code now mysteriously works.
I simply changed

signal(SIGCHLD, &child_status_change_handler);

to

Code:

---

        typedef struct sigaction sigaction_t;
        sigaction_t sigdata;
        memset(&sigdata, sizeof(sigdata), 0);
        sigdata.sa_handler = &child_status_change_handler;
        sigdata.sa_flags = SA_NOCLDSTOP | SA_RESTART;

        sigaction(SIGCHLD, &sigdata, NULL);

---

What is even better is that fgets is resumed (or restarted?) after the signal, hence it keeps blocking.

I will now have to incorporate that into the main program and see what happens.

EDIT:
Wow! I couldn't ask for it to work more perfectly!

You may not have produced the solution, but you did tread me down on the right path. This saves me a lot of frustration! So thanks a million.
The ability to resume sys calls is also extremely useful!

the SA_RESTART flag means to restart any system calls in progress, which is more or less exactly what I told you :P

Yeah, which is one of the reasons I tried using it.

well I'm glad I could help. did it have the desired effect when you put it in your main program?

Yeah, it did. Hence my edit.

Auto-restart of syscalls is only useful in some very specific situations... Normally, you want a signal to abort any blocking syscall you might be inside, so that you can actually respond in some way to the signal. It's difficult to safely do very much inside a signal handler -- most functions are not async signal safe, and even for those that are, you need to remember that you are executing in an asynchronous context and must therefore interlock with the main execution. Signal handlers should ideally just set a flag and then return -- the main program does the heavy lifting. For this to work, the syscall MUST be interrupted by the signal, otherwise you'll just sit there blocked when you actually have something you should be responding to.

It's sort of a pain in the ass, but wrapper like the following can be helpful:

Code:

---

// auto-restarting wrapper around the 'foobar()' system call
int foobar_wrapper(int arg)
{
    int ret = foobar(arg);
    while (ret < 0)
    {
        if (errno == EINTR)
            HandlePendingSignals(); // take care of anything queued up by the sighandlers
        else
            break;
    }
    return ret;
}

---