On 05/02/2015 09:08 AM, Atin Mukherjee wrote: > > > On 05/02/2015 08:54 AM, Emmanuel Dreyfus wrote: >> Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote: >> >>> Seems like glusterd failure from the looks of it: +glusterd folks. >>> >>> Running tests in file ./tests/basic/cdc.t >>> volume delete: patchy: failed: Another transaction is in progress for >>> patchy. Please try again after sometime. >>> [18:16:40] ./tests/basic/cdc.t .. >>> not ok 52 >> >> This is a volume stop that fails. Logs says a lock is held by an UUID >> which happeens to be the volume's own UUID. >> >> I tried git bisect and it seems to be related to >> http://review.gluster.org/9918 but I am not completely sure (I may have >> botched by git bisect) > > I'm looking into this. Looking at the logs, here is the findings: - gluster volume stop got timed out at cli because of which cmd_history.log didn't capture it. - glusterd acquired the volume lock in volume stop but didn't release it somehow as gluster v delete failed saying another transaction is in progress - For gluster volume stop transaction I could see glusterd_nfssvc_stop was triggered but after that it didn't log anything for almost two minutes, but catching point here is by this time volinfo->status should have been marked as stopped and persisted in the disk, but gluster v info didn't reflect the same. Is this reproducible in netbsd everytime, if yes I would need a VM to further debug it. I am guessing that the reason of other failure from tests/geo-rep/georep-setup.t is same. Is it a new regression failure ? ~Atin >> > -- ~Atin _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
