We have a multithreaded embedded application which, due to hardware constraints too mundane to discuss here, must remount its filesystem to be RW whenever it outputs to a file.
We are currently doing this via a system() call, and running the mount command. However, from time to time, this call blocks, and causes the application to go into deadlock.
During my debugging, I have placed system(NULL) prior to the original system() call, and this seems to sometimes block also.
Generally speaking, under what circumstances might system() block for all eternity?
Is this Linux? In glibc on Linux, system() blocks SIGCHLD, changes a couple of signal handlers, forks, waits for the child to die, then fixes what it did to the signal mask. In the child process, it undoes the signal mask changes and exec’s the shell to run your command.
This even happens when you call
system(NULL)— the only difference is that the called shell is called assh -c exit 0.In sum, you’re spawning a process, loading the shell (and all its associated libraries), and waiting for the shell to die. You’re probably getting bitten by loading the shell.