Bug 437507

Summary: DLM_LSFL_TIMEWARN does not appear to work.
Product: Red Hat Enterprise Linux 5 Reporter: Dean Jansa <djansa>
Component: cmanAssignee: David Teigland <teigland>
Status: CLOSED NOTABUG QA Contact: GFS Bugs <gfs-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 5.2CC: cluster-maint, edamato
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-24 17:18:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dean Jansa 2008-03-14 16:46:49 UTC 
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 20:53:47 UTC 
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.