Skip Menu |

This queue is for tickets about the Unix-Lsof CPAN distribution.

Report information
The Basics
Id: 85881
Status: rejected
Priority: 0/
Queue: Unix-Lsof

People
Owner: MARCB [...] cpan.org
Requestors: baztorres [...] gmail.com
Cc:
AdminCc:

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



Subject: Unix::Lsof bug \ limitation
Date: Wed, 5 Jun 2013 11:51:53 +0100
To: bug-Unix-Lsof [...] rt.cpan.org
From: Sebastien Torres <baztorres [...] gmail.com>
Hi, I've noticed a couple of limitations in the Unix::Lsof module. 1. It seems to run in the directory that the script is called from, which is no major issue 2. it seems to only give the details of the user that ran the script Or, am I doing something wrong? Details of what I'm using: [user@host]# uname -a Linux lon24019 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux [user@host]# perl -v This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. Regards, Sebastien
Hi Sebastien, Am Mi 05. Jun 2013, 06:52:07, baztorres@gmail.com schrieb: Show quoted text
> 1. It seems to run in the directory that the script is called from, > which is no major issue
Could you explain how you feel that this is a limitation? What would you rather see instead? Show quoted text
> 2. it seems to only give the details of the user that ran the script
This is because the system permissions do not allow the display of other information. The lsof binary suffers from the same limitation (and quite correctly so, there are reasons why users should not be able to see the details of processes belonging to other users). You can test this by calling lsof directly on the command line instead of via Unix::Lsof, it should display the same information as Unix::Lsof. I'm rejecting this bug for now, please do not take that to mean that I do not value your further input. If I've understood something you said incorrectly, or if you'd like to expand further on the behaviour you'd like to see, please just reopen the bug by replying. Cheers, Marc
Subject: Re: [rt.cpan.org #85881] Unix::Lsof bug \ limitation
Date: Wed, 5 Jun 2013 19:36:14 +0100
To: bug-Unix-Lsof [...] rt.cpan.org
From: Sebastien Torres <baztorres [...] gmail.com>
Hi Marc, Thanks very much for the reply, I'll give you some decent output and details tomorrow. Sebastien On 5 Jun 2013 19:08, "MARCB via RT" <bug-Unix-Lsof@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=85881 > > > Hi Sebastien, > > Am Mi 05. Jun 2013, 06:52:07, baztorres@gmail.com schrieb:
> > 1. It seems to run in the directory that the script is called from, > > which is no major issue
> > Could you explain how you feel that this is a limitation? What would you > rather see instead? >
> > 2. it seems to only give the details of the user that ran the script
> > This is because the system permissions do not allow the display of other > information. The lsof binary suffers from the same limitation (and quite > correctly so, there are reasons why users should not be able to see the > details of processes belonging to other users). You can test this by > calling lsof directly on the command line instead of via Unix::Lsof, it > should display the same information as Unix::Lsof. > > I'm rejecting this bug for now, please do not take that to mean that I do > not value your further input. If I've understood something you said > incorrectly, or if you'd like to expand further on the behaviour you'd like > to see, please just reopen the bug by replying. > > Cheers, > > Marc >
Subject: Re: [rt.cpan.org #85881] Unix::Lsof bug \ limitation - SOLVED
Date: Fri, 7 Jun 2013 11:31:47 +0100
To: bug-Unix-Lsof [...] rt.cpan.org
From: Sebastien Torres <baztorres [...] gmail.com>
Hi Marc, We'll put this one down to coder error and lack of understanding...! I had taken code from an example somewhere on the net. The example had the lsof() function called as 'lsof("-p",$$)'. Removing those arguments give me what I wanted as raw data to work with. Because of the arguments to the function, the effect I had was that it would only show open files in the directory that the perl script was called from and also for the user calling it, which is fine for normal users however I was running the script as root and thus expecting to see more results. Thanks for writing this module :-D It's very useful. Regards, Sebastien On 5 June 2013 19:36, Sebastien Torres <baztorres@gmail.com> wrote: Show quoted text
> Hi Marc, > Thanks very much for the reply, I'll give you some decent output and > details tomorrow. > Sebastien > On 5 Jun 2013 19:08, "MARCB via RT" <bug-Unix-Lsof@rt.cpan.org> wrote: >
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=85881 > >> >> Hi Sebastien, >> >> Am Mi 05. Jun 2013, 06:52:07, baztorres@gmail.com schrieb:
>> > 1. It seems to run in the directory that the script is called from, >> > which is no major issue
>> >> Could you explain how you feel that this is a limitation? What would you >> rather see instead? >>
>> > 2. it seems to only give the details of the user that ran the script
>> >> This is because the system permissions do not allow the display of other >> information. The lsof binary suffers from the same limitation (and quite >> correctly so, there are reasons why users should not be able to see the >> details of processes belonging to other users). You can test this by >> calling lsof directly on the command line instead of via Unix::Lsof, it >> should display the same information as Unix::Lsof. >> >> I'm rejecting this bug for now, please do not take that to mean that I do >> not value your further input. If I've understood something you said >> incorrectly, or if you'd like to expand further on the behaviour you'd like >> to see, please just reopen the bug by replying. >> >> Cheers, >> >> Marc >>
>