Hi Tim, On Tue, Nov 14, 2017 at 08:20:25PM +0100, Tim Düsterhus wrote: > William, > > Am 14.11.2017 um 15:03 schrieb William Lallemand: > > Well, in my opinion the return value does not need to be checked because we > > should never reach the code after the exec, that means that the code after > > the > > exec is only reached during an exec error. But we could at least display the > > error code of exec and return afterwards. > > Displaying the error code basically would imply "checking the return > value" for me. > I did not mean to say that some recovery should be performed if `exec` > fails. I am only saying that the error message should not be > misleadingly claim that we "Cannot allocate memory" when e.g. the > haproxy binary was deleted instead. > > Personally I was confused whether I misconfigured the Docker container > with a broken memory limit, when the actual issue was the bug this patch > fixed. While *this* bug has been fixed `execvp` could possibly fail for > other reasons in the future. >
These problems have been fixed in the master with the following commits: 75ea0a06b BUG/MEDIUM: mworker: does not close inherited FD fade49d8f BUG/MEDIUM: mworker: does not deinit anymore 2f8b31c2c BUG/MEDIUM: mworker: wait again for signals when execvp fail 722d4ca0d MINOR: mworker: display an accurate error when the reexec fail The master worker should be able to behave correctly on a execvp failure now :-) Thanks for the report. Cheers, -- William Lallemand
