PiBox » piboxd

The system() call is synchronous which means we wait for it to finish. A better way to handle this is to fork the request and have a reaper thread deal with it so piboxd is not stuck waiting for the restart to complete. This may require a general purpose child launcher/reaper mechanism for piboxd. It's possible the existing threads could handle it, however, using internal message formats such as MT_INTERNAL_xxx (i.e. not public ones used by piboxMsg) that are dropped by the msgProcessor if they're received from outside clients.

Additionally the call should be a popen() instead of system() to capture errors for logging.

Additionally there should be a retry loop of at least 3 attempts for the specified interface. This can be done with getifaddr or an ioctl on the interface itself.

The retry loop assumes the caller asks for a specific interface. The message format for MT_NET/MA_RESTART should allow for specifying the interface name, no name if any interface can be allowed to satisfy network availability or NONE if we don't care if the network comes back up. These can be added as subtypes:

• MS_NONE: no payload
• MS_ANY: no payload
• MS_IF: the payload is the IF name