The current definition of system() does not define if the pthread_atfork() 
handlers are called. We ran into a scenario where this caused a problem and 
wanted to share it with the mailing list to better understand why those 
handlers are not required and get some advice on how best to proceed.

We are running Linux on an embedded system. The platform can change the IP 
address either according to a proprietary negotiation scheme or a manual 
setting. The application uses netlink to listen for IP address changes; when 
this occurs the application closes all of its sockets and re-opens them using 
the new address.

A problem can occur if the application is simultaneously fork/exec-ing a new 
process. The parent process attempts to bind a new socket to a port that it had 
previously bound to (before the IP address change), only to fail because the 
child process continues to hold a socket bound to that port.

The close-on-exec flag (SOCK_CLOEXEC / FD_CLOEXEC) seems like it would help 
here, but does not because the child process has not called exec() yet.

Our solution was to use a pthread_atfork() handler to lock a mutex and wait for 
the child process to close all of its sockets (as signaled through an eventfd) 
before the parent attempts to create them again.

This doesn't work if the application uses system() anywhere (the version of 
glibc we use does not invoke pthread_atfork() handlers). We changed all calls 
to system() to instead use fork()/exec(), but are still concerned about 
third-party libraries.

This seems like a scenario where you would want system() to require 
pthread_atfork() handlers to be called. Aside from that, it seems somewhat 
contradictory that system() "shall behave as if a child process were created 
using fork()..." but it is undefined if pthread_atfork() handlers are called.

Any feedback would be much appreciated.




CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of 
the intended recipient(s) and contain information that may be Garmin 
confidential and/or Garmin legally privileged. If you have received this email 
in error, please notify the sender by reply email and delete the message. Any 
disclosure, copying, distribution or use of this communication (including 
attachments) by someone other than the intended recipient is prohibited. Thank 

Reply via email to