Description of problem: In the current runner framework we always return the pid i.e ret value of the waitpid, as said above it is not the exit value of the child process Version-Release number of selected component (if applicable): mainline Actual results: returning the ret value of waitpid() Expected results: extract the exit code and return the actual exit status of the child process
REVIEW: http://review.gluster.org/14042 (runner: extract and return actual exit status of child) posted (#1) for review on master by Prasanna Kumar Kalever (pkalever)
COMMIT: http://review.gluster.org/14042 committed in master by Jeff Darcy (jdarcy) ------ commit 19fd9a371fff4ece2c617f1e7194ffcee039f21e Author: Prasanna Kumar Kalever <prasanna.kalever> Date: Thu Apr 21 14:38:16 2016 +0530 runner: extract and return actual exit status of child Intro: pid_t waitpid(pid_t pid, int *status, int options); The waitpid() system call suspends execution of the calling process until a child specified by pid argument has changed state. Here the ret (pid) value is not equal to the exit status of the child process. Check manpages for more info on this. Problem: In the current runner framework we always return the pid i.e ret value of the waitpid, as said above it is not the exit value of the child process Solution: Extract the actual exit code/status in case if the child terminated normally, that is, by calling exit(3) or _exit(2), or by returning from main() Change-Id: Iffae99a43e540af66917b3745f21ea3c2a5a3c2d BUG: 1329129 Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever> Reviewed-on: http://review.gluster.org/14042 Tested-by: Prasanna Kumar Kalever <pkalever> Reviewed-by: Kaleb KEITHLEY <kkeithle> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> Smoke: Gluster Build System <jenkins.com> Reviewed-by: Jeff Darcy <jdarcy>
will be tracked under 1322306
sorry updated it by mistake, taking my comments back It is just modified in master
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user