I'm calling:
FILE *fp = popen(cmd,"r");
...
fprintf(stderr,"%d\n",pclose(fp));
I am calling this from a CGI script.
This used to work, but recently the command being run has started to mysteriously fail, so I added the fprintf to see what status code pclose() is returning, and I was surprised to see it is 32512, which corresponds to an exit code os 127. I have verified that the command is not actually being run, and the return value corresponds to exit status 127.
I tried running otool -L on the binary being run, and everything looks fine. I am invoking the command with the full path to the command, so there is no change it isn't finding the executable. I have printed the current directory to make sure I'm where I think I am, and have verified that the binary is visible.
If I run the exact same command logged in as the same user as the CGI runs as it works fine. If I run the exact same command by passing it to system() it works there also! It only fails when I try to run it via popen().
What the command is doesn't even seem to matter! I replaced it with other commands such as ls and I still get this weird exit code.
I am running out of things to try. What else could it be?
In case anybody runs into this issue in the future, here is how I resolved it. There was a previous call to popen() in the code and a review of the code showed that it was mistakenly closed with fclose() instead of pclose(). Because the previous popen call was closed improperly, it prevented future invocations from working properly.