<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 5, 2017 at 6:39 PM, Atin Mukherjee <span dir="ltr">&lt;<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>OK, so the log just hints to the following:<br><br>[2017-07-05 15:04:07.178204] E [MSGID: 106123] [glusterd-mgmt.c:1532:<wbr>glusterd_mgmt_v3_commit] 0-management: Commit failed for operation Reset Brick on local node <br>[2017-07-05 15:04:07.178214] E [MSGID: 106123] [glusterd-replace-brick.c:649:<wbr>glusterd_mgmt_v3_initiate_<wbr>replace_brick_cmd_phases] 0-management: Commit Op Failed<br><br></div>While going through the code, glusterd_op_reset_brick () failed resulting into these logs. Now I don&#39;t see any error logs generated from glusterd_op_reset_brick () which makes me thing that have we failed from a place where we log the failure in debug mode. Would you be able to restart glusterd service with debug log mode and reran this test and share the log?<br><br></div></div></blockquote><div><br>What&#39;s the best way to set glusterd in debug mode?<br>Can I set this volume, and work on it even if it is now compromised?<br><br>I ask because I have tried this:<br><br>[root@ovirt01 ~]# gluster volume get export diagnostics.brick-log-level<br>Option                                  Value                                   <br>------                                  -----                                   <br>diagnostics.brick-log-level             INFO            <br><br><br>[root@ovirt01 ~]# gluster volume set export diagnostics.brick-log-level DEBUG<br>volume set: failed: Error, Validation Failed<br>[root@ovirt01 ~]# <br><br>While on another volume that is in good state, I can run<br><br>[root@ovirt01 ~]# gluster volume set iso diagnostics.brick-log-level DEBUG<br>volume set: success<br>[root@ovirt01 ~]# <br><br>[root@ovirt01 ~]# gluster volume get iso diagnostics.brick-log-level<br>Option                                  Value                                   <br>------                                  -----                                   <br>diagnostics.brick-log-level             DEBUG         <br>                          <br>[root@ovirt01 ~]# gluster volume set iso diagnostics.brick-log-level INFO<br>volume set: success<br>[root@ovirt01 ~]# <br><br> [root@ovirt01 ~]# gluster volume get iso diagnostics.brick-log-level<br>Option                                  Value                                   <br>------                                  -----                                   <br>diagnostics.brick-log-level             INFO                                    <br>[root@ovirt01 ~]# <br><br></div><div>Do you mean to run the reset-brick command for another volume or for the same? Can I run it against this &quot;now broken&quot; volume?<br><br></div></div>Or perhaps can I modify /usr/lib/systemd/system/glusterd.service and change in [service] section<br><br>from<br>Environment=&quot;LOG_LEVEL=INFO&quot;<br><br></div><div class="gmail_extra">to<br>Environment=&quot;LOG_LEVEL=DEBUG&quot;<br><br></div><div class="gmail_extra">and then <br>systemctl daemon-reload<br></div><div class="gmail_extra">systemctl restart glusterd<br><br></div><div class="gmail_extra">I think it would be better to keep gluster in debug mode the less time possible, as there are other volumes active right now, and I want to prevent fill the log files file system<br></div><div class="gmail_extra">Best to put only some components in debug mode if possible as in the example commands above.<br><br></div><div class="gmail_extra">Let me know,<br></div><div class="gmail_extra">thanks<br></div><div class="gmail_extra"><br></div></div>