-------- Original Message --------
Subject: [rt.cpan.org #33303] Bug in Apache::SizeLimit
Date: Sat, 16 Feb 2008 11:11:50 -0500
From: [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: undisclosed-recipients:;
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


Sat Feb 16 11:11:48 2008: Request 33303 was acted upon.
Transaction: Ticket created by [EMAIL PROTECTED]
       Queue: mod_perl
     Subject: Bug in Apache::SizeLimit
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: [EMAIL PROTECTED]
      Status: new
 Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=33303 >


I have found a bug with Apache::SizeLimit (Note: I am not referring to
Apache2::SizeLimit -- although it may have the same problem).

PLATFORM BACKGROUND:
Mod_perl 1.29
Redhat EL5 (kernel 2.6.18)
Apache::SizeLimit version: $VERSION = '0.91-dev';
Perl version: 5.8.8

PROBLEM:
If I turn off USE_SMAPS (i.e. set Apache::SizeLimit::USE_SMAPS=0), I get an
error, specifically:

Can't call method "_linux_size_check" on an undefined value at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Apache/SizeLimit.pm
line 216.

SOLUTION:
 A diff with my fix is shown below:

************************

@@ -161,7 +163,10 @@
 }

 sub _check_size {
-    my ( $size, $share ) = _platform_check_size();
+    my $class = shift;
+
+    my ( $size, $share ) = $class->_platform_check_size();

     return ( $size, $share, $size - $share );
 }

*************************
ADDITIONAL INFORMATION/QUESTION:

I ran into the problem above because I couldn't get smaps to work.  I had
permission problems accessing the /proc/<pid>/smaps file.  It seems  that
this file (and all others in the /proc/<pid> directory) is owned by root.
While /proc/<pid>/statm is viewable by everyone, /proc/<pid>/smaps is
viewable only by root.  I don't know why.   The process itself is owned by
'web' -- the user that I have set to own apache child processes.  Perhaps
the reason for root ownership is that the Apache parent process is owned by
root and the child processes are only setuid to 'web'.  So, when the
proc/<pid>/ files are made, the child processes are still owned by root.
But that wouldn't account for why smaps in particular is readable only by
root.  Do you know of a way around this? Or if some kernel change in linux
fixes this?

Thanks,
Jeremy


I have found a bug with Apache::SizeLimit (Note: I am not referring to Apache2::SizeLimit -- although it may have the same problem).

PLATFORM BACKGROUND:
Mod_perl 1.29
Redhat EL5 (kernel 2.6.18)
Apache::SizeLimit version: $VERSION = '0.91-dev';
Perl version: 5.8.8

PROBLEM:
If I turn off USE_SMAPS (i.e. set Apache::SizeLimit::USE_SMAPS=0
), I get an error, specifically:

Can't call method "_linux_size_check" on an undefined value at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Apache/SizeLimit.pm line 216.

SOLUTION:
 A diff with my fix is shown below:

************************

@@ -161,7 +163,10 @@
 }

 sub _check_size {
-    my ( $size, $share ) = _platform_check_size();
+    my $class = shift;
+
+    my ( $size, $share ) = $class->_platform_check_size();

     return ( $size, $share, $size - $share );
 }

*************************
ADDITIONAL INFORMATION/QUESTION:

I ran into the problem above because I couldn't get smaps to work.  I had permission problems accessing the /proc/<pid>/smaps file.  It seems  that this file (and all others in the /proc/<pid> directory) is owned by root.  While /proc/<pid>/statm is viewable by everyone, /proc/<pid>/smaps is viewable only by root.  I don't know why.   The process itself is owned by 'web' -- the user that I have set to own apache child processes.  Perhaps the reason for root ownership is that the Apache parent process is owned by root and the child processes are only setuid to 'web'.  So, when the proc/<pid>/ files are made, the child processes are still owned by root.   But that wouldn't account for why smaps in particular is readable only by root.  Do you know of a way around this? Or if some kernel change in linux fixes this?

Thanks,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to