Expect minijail to fork off wpa_supplicant
This fixes a bug where calling `restart wpasupplicant` appears to
not wait for wpa_supplicant to exit before attempting to start it up
again. This is a problem because wpa_supplicant owns a globally unique
DBus name which it needs to release before restarting.
The underlying cause of this behavior is that upstart is waiting for
minijail0 to exit since it is not expecting a fork. When upstart
attempts to stop the wpasupplicant job, it will send a SIGTERM to the
process group (including wpa_supplicant). Unfortunately, since upstart
is watching for minijail0's SIGCHLD, it starts spawning new
wpa_supplicant instances before wpa_supplicant exits.
In some cases, this can cause upstart to exhaust its pool of available
restarts for wpa_supplicant, since each attempt fails when trying to
register the DBus name.
Fix this behavior by:
1) Expecting a fork.
2) Adding a flag to minijail that causes minijail to surrender its init
responsibilities for the child process.
TEST=Called `restart wpasupplicant` before and after applying this patch
while watching log files. Before this patch, occationally see
wpa_supplicant attempting to start up before its predeccesor dies.
After this patch, found that this was not the case.
BUG=chromium:298341
CQ-DEPEND=CL:175600
Change-Id: I014f2dd4a86e6a959d76650e4eca15bab69b0c8b
Reviewed-on: https://chromium-review.googlesource.com/175592
Reviewed-by: Christopher Wiley <wiley@chromium.org>
Commit-Queue: Christopher Wiley <wiley@chromium.org>
Tested-by: Christopher Wiley <wiley@chromium.org>
1 file changed
