I have a program reading from stdin and whilst doing this it sometimes need to fork() and execute a command asynchronously. Sometimes shortly after this fork (probably whilst the command is running), the parent seems to lose data read from stdin. If only a single byte is lost, the program will never recover.
The man page for fork() says that the child inherits copies of the parent's set of open file descriptors, but trying close(STDIN_FILENO) just after fork() and before execvp() doesn't help.
My program basically does:
if (we_need_to_run_a_command_asynchronously) {
if (!fork()) {
close(STDIN_FILENO);
char *args[] = { "command", "arg", "etc", 0 };
setpriority(PRIO_PROCESS, 0, -19);
execvp("command", args);
exit(0); // Ignore errors
}
}
How can I be sure that the child cannot interfere with the parent's stdin (or anything else belonging to the parent)? The command executed is typically a shell script.
I don't know exactly what goes wrong in my program, but it runs fine as long as it doesn't run any commands. Only sometimes (not always) just after it runs a command, the data that it reads from stdin somehow gets corrupted, which is why I suspect that the problem is related to stdin after fork().
I think I've fixed the problem. It turned out that in a rarely taken path of my program which also executed the command I had forgot to do anything with stdin in the child after fork(). This code indeed works:
So, my mistake, but perhaps my question may still serve as an important reminder that it's usually necessary to do something with stdin/stdout/stderr when forking to execute a command which should run separately from the parent process. I think the above way is a clean way to do it.