I couldn't figure out how to create a separate thread to ask you about this.
One other thing I noticed, regarding the 'stale_lock_timeout' -- when specifying both non-zero 'blocking_timeout' and 'stale_lock_timeout', I expected it to work like this:
1. If no lockfile, obviously, create lockfile and return SUCCESS
2. If lockfile exists but it's older than 'stale_lock_timeout', overwrite lockfile and return SUCCESS
3. If lockfile exists and for the *entire* duraction of 'blocking_timeout' it's younger than 'stale_lock_timeout', return FAILURE
4. If lockfile exists and *during the 'blocking_timeout' wait* the 'stale_lock_timeout' threshold is crossed, overwrite lockfile and return SUCCESS
I think #1, #2, and #3 are the current behavior, but I could not make #4 work as I expected it to...
Show quoted text-----Original Message-----
From: Phil Andrew
Sent: Saturday, March 05, 2016 3:59 PM
To: 'bug-File-NFSLock@rt.cpan.org'
Subject: RE: [rt.cpan.org #112723] Possible RFE for Perl File::NFSLock
<URL:
https://rt.cpan.org/Ticket/Display.html?id=112723 >
I created a pull request,
https://github.com/gedarling/File-NFSLock/pull/1
It's my first time using this feature, so I don't know if I did it correctly -- I apologize if I did not.
BTW, when I said "or full domain name", I was actually talking about the fully-qualified username, not hostname (although I do agree that FDQN on the hostname would be useful as well). But I guess having both would be redundant, since if you have the FQDN on the hostname, you can assume that the UID is on the same domain as the host...
So going with UID + HOST@FQDN in the lockfile seems eminently reasonable.
-----Original Message-----
From: Rob Brown via RT [mailto:bug-File-NFSLock@rt.cpan.org]
Sent: Saturday, March 05, 2016 3:22 PM
To: Phil Andrew
Subject: [rt.cpan.org #112723] Possible RFE for Perl File::NFSLock
<URL:
https://rt.cpan.org/Ticket/Display.html?id=112723 >
Yes, it already includes the hostname within the lock_file:
File-NFSLock/lib/File/NFSLock.pm:110: $HOSTNAME = Sys::Hostname::hostname();
File-NFSLock/lib/File/NFSLock.pm:311: $self->{lock_line} ||= "$HOSTNAME $self->{lock_pid} ".time()." ".int(rand()*10000)."\n";
We've always set the `hostname` to be the fully qualified hostname. Always expanding the hostname to include the fqdn might help reduce chances of conflicting similar hostnames with different suffixes on those system with a short hostname as the system hostname.
And it uses kill 0 to test if the process is running on the same host. It was assumed that the same user would be reading or writing to the same file. But including the UID might help reduce the chances of falsely removing sibling users that still have a live lock that are running on the same machine.
So I think your suggestion is appropriate.
Can you provide a pull request to include both of these improvements, for the FQDN and for the UID?
https://github.com/hookbot/File-NFSLock
Thanks!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
