Description of problem: when there are large number of volumes in my case 100 volumes, gluster v status --xml command fails Version-Release number of selected component (if applicable): mainline How reproducible: 100% Steps to Reproduce: 1. create & start 100 volume 2. execure gluster v status --xml Actual results: [root@dhcp46-22 ~]# gluster v status all clients --xml [root@dhcp46-22 ~]# echo $? 92 Command fails without giving proper xml Expected results: gluster v status --xml should xml output of command
REVIEW: https://review.gluster.org/17702 (cli/xml: fix return handling) posted (#1) for review on master by Atin Mukherjee (amukherj)
COMMIT: https://review.gluster.org/17702 committed in master by Atin Mukherjee (amukherj) ------ commit c7efdb834772ddd8f6b07214d3eb2d26425cb79b Author: Atin Mukherjee <amukherj> Date: Wed Jul 5 14:58:50 2017 +0530 cli/xml: fix return handling The return code of xmlTextWriter* APIs says it returns either the bytes written (may be 0 because of buffering) or -1 in case of error. Now if the volume of the xml data payload is not huge then most of the time the data to be written gets buffered, however when this grows sometimes this APIs will return the total number of bytes written and then it becomes absolutely mandatory that every such call is followed by XML_RET_CHECK_AND_GOTO otherwise we may end up returning a non zero ret code which would result into the overall xml generation to fail. Change-Id: I02ee7076e1d8c26cf654d3dc3e77b1eb17cbdab0 BUG: 1467841 Signed-off-by: Atin Mukherjee <amukherj> Reviewed-on: https://review.gluster.org/17702 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Amar Tumballi <amarts> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Gaurav Yadav <gyadav>
Atin, I encountered this very issue on a Gluster 3.10.3 cluster in production and can see the problematic code in 3.8 too. Could you please backport this fix?
What I forgot to mention is that the cluster in question has only 16 volumes: # gluster volume list | wc -l 16 The failing command is "gluster --mode=script --xml volume status all".
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.12.0, please open a new bug report. glusterfs-3.12.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://lists.gluster.org/pipermail/announce/2017-September/000082.html [2] https://www.gluster.org/pipermail/gluster-users/