[Gluster-users] Pending fcntl locks found!

[Stas Oskin]

Hi.

Try the split approach - I didn't notice this here on RC4, during my
testing.

Regards.

2009/3/18 Keith Freedman <freedman at freeformit.com>

> I rolled back to RC2, and no longer have this problem.
> i don't see these error messages, and processes that were hanging before
> are not hanging now?
>
> I'm using single process AFR.  should I split it out and try RC4, or does
> it not seem logical that this should be a problem?
>
> Keith
>
>
> At 09:57 AM 3/16/2009, Keith Freedman wrote:
>
>> Also, I'm wondering if this is related to the fact that I have single
>> process client/server.
>> which used to be the recommended method and now is not.
>>
>> if I split those out, will that solve my problem?
>>
>> At 09:50 AM 3/16/2009, Keith Freedman wrote:
>>
>>> At 04:06 AM 3/16/2009, Vikas Gorur wrote:
>>>
>>>> 2009/3/14 Keith Freedman <freedman at freeformit.com>:
>>>> > all of a sudden, I'm getting messages such as this:
>>>> >
>>>> > 2009-03-13 23:14:06 C [posix.c:709:pl_forget] posix-locks-home1:
>>>> Pending
>>>> > fcntl locks found!
>>>> >
>>>> > and some processes are hanging waiting presumably for the locks?
>>>> > any way to find out what files are being locked and unlock them.
>>>> > restarting gluster doesn't seem to solve the problem.
>>>>
>>>> Are you using any applications that hold POSIX fcntl locks? Try
>>>> running the server in debug mode --- then you can find out which files
>>>> are being locked/not unlocked, etc.
>>>>
>>>
>>> well, I'm sure I am, I've no idea really, there are some php scripts
>>> which seem to hang and some python programs.
>>>
>>> however, this problem only manifested itself when I upgraded to rc4 and
>>> the new fuse-2.7.4glfs11
>>>
>>> so something must be significantly different about how those (or that
>>> combination) handles locks.
>>>
>>>
>>> Also, debug mode wont really solve the problem, cause knowing what exact
>>> file is the problem, isn't going to help because that wont really tell me
>>> how to prevent this from happening.  Clearly one side should get the lock
>>> and one should wait, rather than both servers in the replicate pair just
>>> hanging on the same file?
>>>
>>> in addition, ERROR mode logging should log enough related information to
>>> know this stuff (this is an enhancement request :) )
>>>
>>>
>>>  Vikas
>>>> --
>>>> Engineer - Z Research
>>>> http://gluster.com/
>>>>
>>>
>>>
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>>>
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090318/d110714e/attachment.html>