Bug 966088 - [sanlock] Return information about the current owner(s) of a resource
Summary: [sanlock] Return information about the current owner(s) of a resource
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sanlock
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: Leonid Natapov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-22 12:49 UTC by Federico Simoncelli
Modified: 2013-11-21 11:49 UTC (History)
2 users (show)

Fixed In Version: sanlock-2.8-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 11:49:10 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1632 normal SHIPPED_LIVE sanlock bug fix and enhancement update 2013-11-21 01:32:25 UTC

Description Federico Simoncelli 2013-05-22 12:49:00 UTC
Description of problem:
Sanlock should provide an API to gather information about the owner of a resource.

Additional info:
After speaking with David we agreed on sanlock_check_resource which should behave as:
1. if the resource is hold by the local host: return the local host id and (eventually) the process id owning the resource
2. if the resource is free: return that the resource is free (no hosts)
3. if the resource is hold by a remote host: return the remote host id if it's alive or failing, return free if the host is dead
4. if the resource is shared: mark the resource as shared and return a list of hosts holding the resource

Comment 4 Aharon Canan 2013-08-01 12:01:14 UTC
Leonid, 

please work with Federico and check how to test it/verify it.

Comment 5 Leonid Natapov 2013-08-27 12:58:00 UTC
(In reply to Aharon Canan from comment #4)
> Leonid, 
> 
> please work with Federico and check how to test it/verify it.

David,how can we test it ?

Comment 6 David Teigland 2013-08-27 15:16:58 UTC
Sorry there's no test for this "built in" to sanlock itself.

You can use the test that I use by downloading:
https://git.fedorahosted.org/cgit/sanlock.git/plain/tests/sanlk_testr.c?id=sanlock-2.8

And you'll probably need to install the sanlock-devel rpm to compile it:
gcc sanlk_testr.c -lsanlock -o sanlk_testr

Then run the following sequence of commands:

truncate -s 1G /root/leasefile
chown sanlock.sanlock /root/leasefile

sanlock client init -s L:0:/root/leasefile:0
sanlock client init -r L:R:/root/leasefile:1048576
sanlock add_lockspace -s L:1:/root/leasefile:0

sanlock client command -r L:R:/root/leasefile:1048576 -c /bin/sleep 100 &

sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
owner 1 gen 1
test_flags 1

(Correct result is test_flags 1 because resource lease is held by /bin/sleep.)

killall -9 sleep

sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
test_flags 0

(Correct result is test_flags 0 because resource lease is not held.)

Comment 7 Leonid Natapov 2013-10-02 08:44:56 UTC
sanlock-2.8-1.el6.x86_64.

tested according David's instructions:
[root@nott-vds1 tmp]# ./sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
owner 1 gen 1
test_flags 1
[root@nott-vds1 tmp]# killall -9 sleep
[1]+  Killed                  sanlock client command -r L:R:/root/leasefile:1048576 -c /bin/sleep 100
[root@nott-vds1 tmp]# 
[root@nott-vds1 tmp]# 
[root@nott-vds1 tmp]# ./sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
test_flags 0

Comment 9 errata-xmlrpc 2013-11-21 11:49:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1632.html


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