summaryrefslogtreecommitdiffstats
path: root/xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c
diff options
context:
space:
mode:
authorPoornima G <pgurusid@redhat.com>2016-07-25 10:26:58 +0530
committerJeff Darcy <jdarcy@redhat.com>2016-07-27 09:29:29 -0700
commit4e1ad2c96ea692e49fb82ce533cdc26818277e8d (patch)
treece03c12f473cc26aa76a4d42a314c504d5496a59 /xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c
parent6e78a0dda9343d75674a12b7e1a1e8e59e17c78c (diff)
tests: Fix the spurious failure in libgfapi-fini-hang.t
RCA: After running libgfapi-fini-hang, there is a EXPECT_WITHIN which waits for PROCESS_UP_TIMEOUT(20s), for the process libgfapi-fini-hang to die. Currently EXPECT_WITHIN is returning success even if the process libgfapi-fini-hang is alive. This is because "pgrep libgfapi-fini-hang" in check_process() is returning 1(no process alive) even if the process is alive. Man page of pgrep says "The process name used for matching is limited to the 15 characters". Hence changing the name of executable from libgfapi-fini-hang to gfapi-hang, so that it falls within the limit. As explained the failure is not because there was a hang(logs show that glfs_set_volfile_server was still executing), but because EXPECT_WITHIN was not really waiting. And hence there was a race between the execution of the process libgfapi-fini-hang and the kill. Change-Id: I257715865e0d3e5a14f83d1e235c01899e1cae68 BUG: 1358594 Signed-off-by: Poornima G <pgurusid@redhat.com> Reviewed-on: http://review.gluster.org/14997 Smoke: Gluster Build System <jenkins@build.gluster.org> CentOS-regression: Gluster Build System <jenkins@build.gluster.org> Reviewed-by: Raghavendra Talur <rtalur@redhat.com> Reviewed-by: Niels de Vos <ndevos@redhat.com> NetBSD-regression: NetBSD Build System <jenkins@build.gluster.org> Tested-by: Gluster Build System <jenkins@build.gluster.org>
Diffstat (limited to 'xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c')
0 files changed, 0 insertions, 0 deletions