Greetings, 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. Thanks, Nate ________________________________ 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 you.
