Take the 2-minute tour ×

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?

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

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 as sh -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.

share|improve this answer
Although we still don't know what our problem is (it's probably caused by some subtlety of our platform), this answer contains some good info, so gets the tick this time. –  Dunnie Dec 3 '12 at 13:57
add comment

system() blocks until the called command has completed, so if the mount command never finishes then system() will never return.

share|improve this answer
That was my first thought, but system(NULL) never finishes, and I am able to perform the mount manually from the terminal whilst the application is in the blocked state. –  Dunnie Nov 27 '12 at 17:43
add comment

I guess if you run mount than you need root privileges, so maybe this is your case (excerpt from man system on Linux):

   execvp(3).  system() will not, in fact, work properly from programs with set-user-ID or set-group-ID privileges on systems  on
   this when invoked as sh.)
share|improve this answer
It's a good answer, but not the issue here: I definitely have root privileges. And besides, this call works 70% of the time. The remaining 30%, something beyond my understanding happens, which causes all manner of pain. –  Dunnie Nov 27 '12 at 17:49
add comment

Your Answer


