Bug 437507 - DLM_LSFL_TIMEWARN does not appear to work.
DLM_LSFL_TIMEWARN does not appear to work.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cman (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: David Teigland
GFS Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-14 12:46 EDT by Dean Jansa
Modified: 2009-04-16 19:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-24 13:18:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dean Jansa 2008-03-14 12:46:49 EDT
Description of problem:

I created a new lockspace "timewarn" with the DLM_LSFL_TIMEWARN flag set and
attempted to get a lock which I knew would be placed on the wait queue with the
timeout value set to 100 using dlm_ls_lockx() interface.

I'm still waiting for the ast for that lock...

If I watch the dlm_tool lockdump output I see both locks there:

[root@marathon-01 dlm]# dlm_tool lockdump timeout
id 00080001 gr EX rq NL pid 3284 master 0 "timeouttest"
id 02440001 gr IV rq EX pid 3284 master 0 "timeouttest"

I was expecting an ast for lock 02440001 to be sent with an sb_status of
something other than 0.  That ast is never sent.


Version-Release number of selected component (if applicable):
cman-2.0.80-1.el5
cman-devel-2.0.80-1.el5
Comment 1 Dean Jansa 2008-03-14 16:53:47 EDT
Not a bug -- Needed to use the LKF_TIMEOUT in the dlm_lockx() flags.  The
example in the 'Programming Locking Applications' showed the flags == 0.

This works as expected if LKF_TIMEOUT is set.

Note You need to log in before you can comment on or make changes to this bug.