<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 3:47 AM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jul 5, 2017 at 6:39 PM, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>></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:glusterd<wbr>_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_repl<wbr>ace_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'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></span><div><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 "now broken" volume?<br><br></div></div>Or perhaps can I modify /usr/lib/systemd/system/<wbr>glusterd.service and change in [service] section<br><br>from<br>Environment="LOG_LEVEL=INFO"<br><br></div><div class="gmail_extra">to<br>Environment="LOG_LEVEL=DEBUG"<br><br></div><div class="gmail_extra">and then <br>systemctl daemon-reload<br></div><div class="gmail_extra">systemctl restart glusterd<br></div></div></blockquote><div><br></div><div>Yes, that's how you can run glusterd in debug log mode. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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></div></div></blockquote><div><br></div><div>You can switch back to info mode the moment this is hit one more time with the debug log enabled. What I'd need here is the glusterd log (with debug mode) to figure out the exact cause of the failure.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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>
</blockquote></div><br></div></div>