6

I need to be able to:

  1. fork a process and make it execvp (I did that)
  2. check if the child process execvp was successful (don't know how)
  3. check if the child process finished (having problems)

I'm forking a process and I don't have any way to check if the childs's execvp worked or failed. If it failed I need to be able to know that it failed. Currently I'm using

-1 != waitpid( pid, &status, WNOHANG )

But it seems that if the execv of the pid process fails the waitpid does not return -1.

How could I check that? I read the waitpid man page, but it isn't clear to me; maybe my English isn't good enough.

EDIT: in order to explain more:
I'm building my own terminal for a Home Work. I need to get as an input a command string, lets say "ls" and then I have to execute the command.
After the child forks, the child calls execvp in order to execute the command ( after I parse the string ), and the parent need to check whether there was a '&' at the end of the command or not.
if the sign '&' does not exist at the end of the command then the parent need to wait for the child to execute.

so I need to know if the execvp failed. If it didn't failed then the parent use waitpid to wait for the child to finish it execution. If it failed then the parent will not wait for the child.

m1o2
  • 1,549
  • 2
  • 17
  • 27
  • 10
    best question title ever. – valentinas Nov 20 '12 at 21:26
  • 1
    There are a couple of factors that might influence your solution here: What are you `execvp`ing your process into? Do you have the ability to edit _that_? Is it okay to not know whether the execvp failed until the child exits? If you post a more detailed problem statement, we might be able to give better advice. – FrankieTheKneeMan Nov 20 '12 at 21:33
  • 1
    Can't you send a signal from the child to the parent in case of said failure? – Mahmoud Al-Qudsi Nov 20 '12 at 22:09
  • 1
    In this situation, you don't actually need to know if the execvp is successful. All you need to do is decide wether to use `WNOHANG` for `waitpid`. If there is a &, then use it. Otherwise, use some structure to monitor background tasks. – FrankieTheKneeMan Nov 20 '12 at 23:14
  • 1
    Actually, check out the answer I gave to http://stackoverflow.com/questions/12824848/placing-a-process-in-the-background-in-c/12824911#12824911 - it gives a pretty decent bit of code solutions. – FrankieTheKneeMan Nov 20 '12 at 23:16
  • @FrankieTheKneeMan thanks! But now I'm having another problem. I need to implement fg and bg ( Foreground and Background ) jobs. when I execute a command without a & at the end, it is a foreground job and therefor the parent waits for the child to finish. I need to be able to return the execution to the parent if SIGTSP is signaled, in other words after a ctrl+z is pressed. well, I'm able to stop the foreground process but I'm not able to return the execution to the parent and I don't know why. is there something I need to do ? – m1o2 Nov 20 '12 at 23:52
  • That depends on your implementation, and your system. I might be able to help, but it seems like a 'new question' sort of situation. – FrankieTheKneeMan Nov 21 '12 at 00:56
  • @FrankieTheKneeMan thanks for you help, I posted a new questions :http://stackoverflow.com/questions/13485462/linux-fork-execvp-waitpid-and-sigtsp. Thanks! – m1o2 Nov 21 '12 at 02:30

2 Answers2

7

A common solution to #2 is to open a pipe prior to the fork(), then write to it in the child following the exec. In the parent, a successful read means the exec failed; an unsuccessful read means the exec succeeded and the write never took place.

// ignoring all errors except from execvp...
int execpipe[2];
pipe(execpipe);
fcntl(execpipe[1], F_SETFD, fcntl(execpipe[1], F_GETFD) | FD_CLOEXEC);
if(fork() == 0)
{
    close(execpipe[0]);
    execvp(...); // on success, never returns
    write(execpipe[1], &errno, sizeof(errno));
    // doesn't matter what you exit with
    _exit(0);
}
else
{
    close(execpipe[1]);
    int childErrno;
    if(read(execpipe[0], &childErrno, sizeof(childErrno)) == sizeof(childErrno))
    {
        // exec failed, now we have the child's errno value
        // e.g. ENOENT
    }
}

This lets the parent unambiguously know whether the exec was successful, and as a byproduct what the errno value was if unsuccessful.

If the exec was successful, the child process may still fail with an exit code, and examining the status with the WEXITSTATUS macro give you that condition as well.

NOTE: Calling waitpid with the WNOHANG flag is nonblocking, and you may need to poll the process until a valid pid is returned.

Ryan Calhoun
  • 2,343
  • 22
  • 26
  • @Ryan-Callhoun, thanks, but the read will block the parent, isn't it ? if the execvp succeed I need the parent to not wait. I edited my post to clarify. thanks! – m1o2 Nov 20 '12 at 22:52
  • 3
    @m1o2: Note the `FD_CLOEXEC`. The pipe is closed on the child when `execv*` succeeds. A read will return 0 for EOF. – ninjalj Nov 20 '12 at 23:17
  • 2
    If available, use `pipe2` with `O_CLOEXEC` instead of `pipe` followed by `fcntl`. It's not just more efficient, but also sets the close-on-exec flag atomically with opening the pipe, so it's safe for multi-threaded use where other threads might be running external commands too. As of now, `pipe2` is an extension, but it's already been accepted for inclusion in the next version of POSIX. – R.. GitHub STOP HELPING ICE Nov 21 '12 at 02:30
4

An exec call shouldn't return at all if it succeeds, because it replaces the current process image with another one, so if it does it means an error has occurred:

execvp(...);
/* exec failed and you should exit the
   child process here with an error */
exit(errno);

To let the parent process know if exec failed you should read the status of the child process:

waitpid(pid, &status, WNOHANG);

And then use the WEXITSTATUS(status) macro, from the man page:

WEXITSTATUS(status) returns the exit status of the child. This consists of the least significant 8 bits of the status argument that the child specified in a call to exit(3) or _exit(2) or as the argument for a return statement in main()

Note the last statement means if exec succeeds and runs the command you will get the exit status of the main() function of that command, in other words you can't reliably tell the difference between a failed exec and a failed command this way, so it depends if that matters to you.

Another issue:

if the sign '&' does not exist at the end of the command then the parent need to wait for the child to execute.

You need to call wait() on the child process at some point in your program, regardless of the & to avoid leaving the child process in a zombie state,

Note: When you use the WNOHANG it means that waitpid() will return immediately if no process has changed its state, i.e. it will not block, I assume you know that, otherwise use wait() or call waitpid() as part of your main loop.

iabdalkader
  • 17,009
  • 4
  • 47
  • 74
  • I think the hard part of this problem is letting the _parent_ process know that the execvp failed. – FrankieTheKneeMan Nov 20 '12 at 21:35
  • Since OP isn't around to clarify, I'll play devil's advocate: What if I need to make sure that the child has properly `execvp`ed before I send it signals or other control information, and thus cannot wait for it to actually exit? – FrankieTheKneeMan Nov 20 '12 at 21:47
  • Oh, and if your `waitpid` executes and returns before the `execvp` fails, it will yeild a false positive. – FrankieTheKneeMan Nov 20 '12 at 21:48
  • @FrankieTheKneeMan but OP's third question is check if it finished, which means he's waiting for the child process and doesn't want to talk to it :) – iabdalkader Nov 20 '12 at 21:51
  • @FrankieTheKneeMan and `waitpid` doesn't return unless a child's state changes – iabdalkader Nov 20 '12 at 21:52
  • Not necessarily - they could be separate: `fork`, `exec`, Check `exec` success, Send information, wait for finish. – FrankieTheKneeMan Nov 20 '12 at 21:52
  • @FrankieTheKneeMan possibly, anyway, just to be clear, I'm not arguing that it's a catch all solution, it's just a solution :) an *easy* one. – iabdalkader Nov 20 '12 at 21:54
  • Normally, yes, but you used `WNOHANG`, which causes wait functions to "return immediately if no child has exited". And a solution that doesn't handle edge cases, especially in parallel processing, isn't really a solution. I'm not trying to be mean, I'm just trying to ensure that OPs Question is properly answered. – FrankieTheKneeMan Nov 20 '12 at 21:56
  • @FrankieTheKneeMan how do you know waitpid with `WNOHANG` is not called in a loop ? – iabdalkader Nov 20 '12 at 21:58
  • Well, in your solution, because you don't mention it. You don't even mention the incompleteness of your response. Don't get defensive, we're on the same side here. We're just trying to help people. – FrankieTheKneeMan Nov 20 '12 at 22:01
  • @FrankieTheKneeMan I assumed the OP knew why he choose waitpid with`WNOHANG` than the obvious wait, but anyway I will update that – iabdalkader Nov 20 '12 at 22:02
  • @FrankieTheKneeMan and mux thank you! I edited my post to clarify the question. – m1o2 Nov 20 '12 at 22:58
  • @FrankieTheKneeMan I updated the answer with some notes, hope it's more clear now, I didn't mind the discussion just fell asleep :) please let me know if you have more comments – iabdalkader Nov 21 '12 at 14:44
  • @mux thanks for your help, #FrankieTheKneeMan helped my yesterday and I solved my problem. Thanks for both of u! – m1o2 Nov 22 '12 at 00:20
  • @mux If i use WNOHANG should i keep checking the return value in my Parent main loop and check when it changes? – Ayman Salah Mar 30 '15 at 01:53