Skip Menu |
 

This queue is for tickets about the File-NFSLock CPAN distribution.

Report information
The Basics
Id: 112723
Status: open
Priority: 0/
Queue: File-NFSLock

People
Owner: Nobody in particular
Requestors: pandrew [...] nvidia.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Possible RFE for Perl File::NFSLock
Date: Sat, 5 Mar 2016 20:08:02 +0000
To: "bug-File-NFSLock [...] rt.cpan.org" <bug-File-NFSLock [...] rt.cpan.org>
From: Phil Andrew <pandrew [...] nvidia.com>
Download (untitled) / with headers
text/plain 935b
Hi, Rob - Have you considered the possible enhancement to File::NFSLock of including the UID (or full domain name?) of the locker in the *.NFSLock file? In my usage of this module I would find that to be a useful addition to the lock file... Perhaps this info is not there thoughtfully, e.g. maybe there are security/privacy considerations that I'm overlooking - if so I'd be interested to hear about them. Thanks in advance for your response, +Phil ----------------------------------------------------------------------------------- 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. -----------------------------------------------------------------------------------
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!
Subject: RE: [rt.cpan.org #112723] Possible RFE for Perl File::NFSLock
Date: Sat, 5 Mar 2016 23:59:01 +0000
To: "bug-File-NFSLock [...] rt.cpan.org" <bug-File-NFSLock [...] rt.cpan.org>
From: Phil Andrew <pandrew [...] nvidia.com>
Download (untitled) / with headers
text/plain 2.4k
<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. Show quoted text
-----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. -----------------------------------------------------------------------------------
Subject: RE: [rt.cpan.org #112723] Possible RFE for Perl File::NFSLock
Date: Sun, 6 Mar 2016 00:13:55 +0000
To: "bug-File-NFSLock [...] rt.cpan.org" <bug-File-NFSLock [...] rt.cpan.org>
From: Phil Andrew <pandrew [...] nvidia.com>
Download (untitled) / with headers
text/plain 3.4k
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. -----------------------------------------------------------------------------------


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.