[mp2] Apache2::SizeLimit should be using $s->rss, not $s->size for Linux::Smaps
All of my processes kept exiting with a report that they had a 300M
unshared size, which was clearly untrue, even from looking at top. After
some investigation, I discovered that Apache2::SizeLimit was calling
$s->size on the Linux::Smaps object, when instead it should be returning
$s->rss as the process size.
Attached is a one-line patch to fix the issue.
Also, if you're interested in proof that this is right, I've attached a
short .cgi file that you can load under mod_perl, with Linux::Smaps
installed, to see process sizes and the return values of all of the
Smaps accessors.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
--- Apache2/SizeLimit.pm.old2010-02-02 15:53:22.0 -0600
+++ Apache2/SizeLimit.pm2010-02-02 15:50:11.0 -0600
@@ -111,7 +111,7 @@
sub linux_smaps_size_check {
my $s = Linux::Smaps->new($$)->all;
-return ($s->size, $s->shared_clean + $s->shared_dirty);
+return ($s->rss, $s->shared_clean + $s->shared_dirty);
}
# return process size (in KB)
#!/usr/bin/perl -wT
use strict;
use warnings;
use Linux::Smaps;
my $s = Linux::Smaps->new($$)->all;
print "Content-type: text/plain\n\n";
print "SIZE: " . $s->size, "\n";
print "CLEAN: ", $s->shared_clean, " DIRTY: ", $s->shared_dirty, "\n";
print "PRIVATE CLEAN: ", $s->private_clean, " PRIVATE DIRTY: ",
$s->private_dirty, "\n";
print "RSS: ", $s->rss, "\n";
Re: [mp2] Apache2::SizeLimit should be using $s->rss, not $s->size for Linux::Smaps
On 02/03/2010 04:57 AM, Torsten Förtsch wrote:
> Well, I tend to disagree. (Fred, Adam please read on.)
Okay. Have you looked at the actual output of test.cgi?
Here's an example of these values just on my local machine, for my bash
interpreter:
[mka...@es-compy ~]$ cat /proc/self/statm
21045 125 107 13 0 65 0
[mka...@es-compy ~]$ cat /proc/self/status | grep Vm
VmPeak:84180 kB
VmSize:84180 kB
VmLck: 0 kB
VmHWM: 496 kB
VmRSS: 496 kB
VmData: 176 kB
VmStk:84 kB
VmExe:52 kB
VmLib: 1548 kB
VmPTE:48 kB
Would you consider that bash is taking up 84MB, or would you consider
it's taking up 496KB? I have 2GB in physical RAM and 2GB in swap. So,
theoretically, I should only be able to open 48 terminals before I OOM.
With 60 terminals open, here's the result of "free":
total used free
Mem: 1990 1855134
-/+ buffers/cache: 1140850
Swap: 1999212 1787
If I were simply to add up the "Virt" column of the top 15 processes in
"top" on my machine, I'd be using somewhere in the vicinity of 20GB of RAM.
> So, either the far older statm technique is also wrong or the patch is wrong.
I would suspect that if you're using column 0 as the size, then statm
is also indeed wrong.
> =item * Apache2::SizeLimit->set_max_process_size($size)
>
> This sets the maximum size of the process, including both shared and
> unshared memory.
Ahh, but look at the output of both the "shared" and "private"
accessors, and they do not add up to VmSize. They add up to RSS.
> Perhaps Apache2::SizeLimit::Core should read:
>
> sub _check_size {
> my $class = shift;
>
> my ($size, $share, $unshared) = $class->_platform_check_size();
>
> return ($size, $share, defined $unshared ? $unshared : $size - $share);
That would certainly help (because then you would get a more accurate
count of the current private RSS), although I'd argue that VmSize is
still meaningless. I can imagine few instances where you'd want to know
the total size of the address space of a process, even if most of it had
never been mapped to an actual memory page.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Re: mod_perl "instability" on Ubuntu 10.04 server platform
On 10/28/2010 03:22 AM, Vanja Hrustic wrote: > So, I just made 1 million requests to a Debian box, and had no > problems and no failed requests. Are both the Debian and the Ubuntu box using a worker MPM, or is one of them using prefork and the other using worker? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Re: [mp2] Apache2::SizeLimit should be using $s->rss, not $s->size for Linux::Smaps
So, I just recently installed the very latest release of SizeLimit, and
this is still a problem. SizeLimit **definitely** returns the wrong
unshared size for processes on any modern Linux system.
-Max
On 02/03/2010 12:05 PM, Max Kanat-Alexander wrote:
> On 02/03/2010 04:57 AM, Torsten Förtsch wrote:
>> Well, I tend to disagree. (Fred, Adam please read on.)
>
> Okay. Have you looked at the actual output of test.cgi?
>
> Here's an example of these values just on my local machine, for my bash
> interpreter:
>
> [mkanat@es-compy ~]$ cat /proc/self/statm
> 21045 125 107 13 0 65 0
> [mkanat@es-compy ~]$ cat /proc/self/status | grep Vm
> VmPeak: 84180 kB
> VmSize: 84180 kB
> VmLck: 0 kB
> VmHWM: 496 kB
> VmRSS: 496 kB
> VmData:176 kB
> VmStk: 84 kB
> VmExe: 52 kB
> VmLib:1548 kB
> VmPTE: 48 kB
>
> Would you consider that bash is taking up 84MB, or would you consider
> it's taking up 496KB? I have 2GB in physical RAM and 2GB in swap. So,
> theoretically, I should only be able to open 48 terminals before I OOM.
> With 60 terminals open, here's the result of "free":
>
> total used free
> Mem: 1990 1855134
> -/+ buffers/cache: 1140850
> Swap: 1999212 1787
>
> If I were simply to add up the "Virt" column of the top 15 processes in
> "top" on my machine, I'd be using somewhere in the vicinity of 20GB of RAM.
>
>> So, either the far older statm technique is also wrong or the patch is wrong.
>
> I would suspect that if you're using column 0 as the size, then statm
> is also indeed wrong.
>
>> =item * Apache2::SizeLimit->set_max_process_size($size)
>>
>> This sets the maximum size of the process, including both shared and
>> unshared memory.
>
> Ahh, but look at the output of both the "shared" and "private"
> accessors, and they do not add up to VmSize. They add up to RSS.
>
>> Perhaps Apache2::SizeLimit::Core should read:
>>
>> sub _check_size {
>> my $class = shift;
>>
>> my ($size, $share, $unshared) = $class->_platform_check_size();
>>
>> return ($size, $share, defined $unshared ? $unshared : $size - $share);
>
> That would certainly help (because then you would get a more accurate
> count of the current private RSS), although I'd argue that VmSize is
> still meaningless. I can imagine few instances where you'd want to know
> the total size of the address space of a process, even if most of it had
> never been mapped to an actual memory page.
>
> -Max
--
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services
Re: [mp2] Apache2::SizeLimit should be using $s->rss, not $s->size for Linux::Smaps
On 02/02/2010 02:19 PM, Fred Moyer wrote:
> Can you submit these patches inline?
Here is the patch inline:
Index: lib/Apache/SizeLimit/Core.pm
===
--- lib/Apache/SizeLimit/Core.pm(revision 905815)
+++ lib/Apache/SizeLimit/Core.pm(working copy)
@@ -175,7 +175,7 @@
return $class->_linux_size_check() unless $USE_SMAPS;
my $s = Linux::Smaps->new($$)->all;
-return ($s->size, $s->shared_clean + $s->shared_dirty);
+return ($s->rss, $s->shared_clean + $s->shared_dirty);
}
sub _linux_size_check {
Re: On memory consumption - request for comments
On 02/11/2011 06:26 AM, Torsten Förtsch wrote: > Now, if an administrator turns off swapping (swapoff /dev/...) the part of > notpresent that has been there becomes present. So, we can expect shared to > grow considerably. unshared will shrink by the same amount. > > But if an administrator turns off swapping now a part of notpresent will be > added to unshared. unshared may suddenly jump over the limit in all apache > children. Hey Torsten. First of all, wow, thank you for this awesome write-up. That was probably the best overview of copy-on-write and page types I've ever read. I think that if an administrator turns off the swap, they would in fact *want* ASL to behave such that it killed httpds that were taking up too much physical RAM, even if that happened suddenly. The space for mapping pages to has suddenly decreased drastically, so it makes sense to suddenly be much more aggressive about killing processes. > There are a few other status fields that can be possibly used: > > - "Swap" in /proc/$PID/smaps > don't know for sure what that means but sounds good. Need to inspect the > kernel code Hmm, if that does actually count the size of mapped swap pages, then we could possibly do rss + swap as the "size". -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Re: On memory consumption - request for comments
Hey Fred. So given the discussion that we've had on this, do you think that the next version of SizeLimit could change its Linux behavior to return the more appropriate rss size? -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Re: On memory consumption - request for comments
On 02/23/2011 11:40 PM, Torsten Förtsch wrote: > On Thursday, February 24, 2011 07:45:29 Max Kanat-Alexander wrote: >> Hey Fred. So given the discussion that we've had on this, do you think >> that the next version of SizeLimit could change its Linux behavior to >> return the more appropriate rss size? > > yes Awesome, thank you. :-) -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Factoring out Apache::SizeLimit::Core?
Hey folks. Would it be possible to factor the memory-sizing code in Apache::SizeLimit::Core into a separate module (or is there already a separate module that does something similar)? I'd love a module that can just reliably tell me how much memory a process is using across all platforms. -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Re: On memory consumption - request for comments
On 02/24/2011 12:41 AM, Torsten Förtsch wrote: > Max, could you please check if the following patch does what you want and try > it out in your environment? Hey Torsten. Yes, I tested it and it works. Thank you so much! :-) -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Re: Factoring out Apache::SizeLimit::Core?
On 02/24/2011 05:47 AM, Perrin Harkins wrote: > Oh, maybe Proc::Processtable is what you want. Ah, no, it doesn't work on Win32 as far as I can tell. (Working on Win32 is one of my requirements.) SizeLimit is the only module I've been able to find that can reliably determine process size across platforms. -Max -- http://www.bugzillasource.com/ Competent, Friendly Bugzilla, Perl, and IT Services
Re: How do you use mod_perl for your web application?
On 06/15/2011 09:01 PM, Fred Moyer wrote: > I'm interested in hearing about what application frameworks (Catalyst, > CGI::App, Mojolicious) are used here with mod_perl. Given the number > of emerging Perl based webservers on CPAN (in addition to Nginx, > lighty, etc), it seems like there are many more Perl web application > and webservers out there now than there were five years ago. There are probably several thousand installations of our application running under mod_perl. (We guess that there are roughly 10,000 installations of Bugzilla, some large number of which are running under mod_perl.) We don't really have a web framework (unless you count CGI.pm, which I don't), we just have a bunch of raw CGI files. The application dates originally from 1998 and is developed on an entirely volunteer basis, so we have a legacy from that era. The exact same code also runs under mod_cgi for users who have trouble installing mod_perl (or want to run multiple installations on one machine with different code). We require only mod_perl 1.999022, but nowadays also require Apache2::SizeLimit 0.93, which may raise the effective minimum mod_perl requirement. The performance and configuration ease of mod_perl have been generally excellent for us--our only serious problems have been with people having their servers' memory exhausted (which is why I frequently talk/ask about SizeLimit on this list) and the occasional problem with a CPAN module that doesn't work right in mod_perl. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/
Re: Apache2::SizeLimit and x64_86
On 05/12/11 16:15, Fred Moyer wrote: There has not been any feedback on the release candidate from this thread, and as such there is no projected release date. http://www.gossamer-threads.com/lists/modperl/dev/102778 Hey Fred & list. I just tested this release and it works perfectly and does exactly what I would have liked it to do. My test environment was mod_perl 2.0.4 and Apache 2.2.14 on Ubuntu Lucid. -Max -- Max Kanat-Alexander Chief Architect, Community Lead, and Release Manager Bugzilla Project http://www.bugzilla.org/
[QUESTION] pnotes, Template-Toolkit, and a memory leak
Hi. I'm working on making Bugzilla support mod_perl.
I have a very strange memory leak.
Bugzilla uses the Template Toolkit (TT2).
We're using MP2. In particular, 1.999022 (aka 2.0.0-RC5). I've also
tested the below on 2.0.1, with the same results.
I have httpd-2.0.52-22 from RHEL4 (Red Hat Enterprise Linux 4) for my
Apache. My perl is also 5.8.5, from RHEL4. (The server is a RHEL4
server.)
All my testing was in a single-process prefork server, running as
"httpd -X".
I store a Template object inside of $r->pnotes().
I call ->process() on that Template object, with a particular template,
and throw away the output.
The script ends.
I reload the script, it uses an additional 512K of RAM.
Every time I reload the script, the process uses an *additional* 512K
of RAM, forever, on and on, until my server runs out of memory.
HOWEVER: If I "delete $r->pnotes->{template}" before the script ends,
there's no memory leak.
So clearly, mod_perl's RequestRec cleanup is doing something different
than delete is doing, and mod_perl is missing cleaning up certain
references.
We have a bug on this in our system, you can see it at:
https://bugzilla.mozilla.org/show_bug.cgi?id=343166
Any ideas on how I could fix this in Bugzilla?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: [QUESTION] pnotes, Template-Toolkit, and a memory leak
On Fri, 2006-06-30 at 00:37 -0400, Perrin Harkins wrote:
> > HOWEVER: If I "delete $r->pnotes->{template}" before the script ends,
> > there's no memory leak.
>
> It sounds like a problem with the DESTROY method in Template::Provider.
> Can you add some logging to that method to see if it gets called?
Hey Perrin. You are indeed exactly correct. I tested it, and the
DESTROY method in Template::Provider never gets called. However, when I
manually do the delete on the hash key, DESTROY does get called.
So, is there anything I can do about this in my code? Would this be a
bug in mod_perl or in the Template Toolkit?
This is TT 2.15, FWIW.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: [QUESTION] pnotes, Template-Toolkit, and a memory leak
On Fri, 2006-06-30 at 18:49 -0400, Jonathan Vanasco wrote: > I think its more likely that the bug is in the way Bugzilla uses TT > -- a some reference to the template object is getting stored > persistently ( i think everyone has made a similar mistake ). I've > never had a problem with a pnote living on after a request, and your > issue is either the pnote is still around or the object the pnote > references is linked elsewhere. Yeah, I suspected that too, but it couldn't be--because the cleanup happens correctly if I delete that *one* reference, and it doesn't happen correctly if I don't delete that *one* reference. So it doesn't have anything to do with anything else holding on to a reference. > I think the easiest fix, for now, would be to toss in a cleanup > handler that just undefs the pnote if its defined. if you're only > using the pnote within a single handler stage, i'd just undef it at > the end of the handler after all the output is generated. i do tons > of 'just in case' cleanup things. Okay. Yeah, that's probably what I'll do, is just call delete on all the pnote keys. But one way or another, this does seem like a bug. That DESTROY handler ought to get called. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: [offtopic] perl newbie frustrated
On Thu, 2006-07-13 at 16:51 -0500, Matthew wrote: > If anyone could please explain what I missed on the differences between > ( ) array's and [ ] array's, I'd appreciate it. () is an array [] is a reference to an array, also known as a "pointer" to an array. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Startup script throwing error about $r when it shouldn't
When I start Apache, I get this:
Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin
httpd.conf at /var/www/html/mod_perl/Bugzilla.pm line 316.
Okay...that's from my startup script (I cut out most of the error
message to make things clearer.)
But here's that line:
sub request_cache {
if ($ENV{MOD_PERL}) {
require Apache2::RequestUtil;
316:my $request = Apache2::RequestUtil->request;
my $cache = $request->pnotes();
It's inside a subroutine! And it's called dynamically! And that
subroutine is never called at compile time!
So why in the world is mod_perl complaining?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
ModPerl::RegistryLoader doesn't compile from the command line
From any command line, try: perl -MModPerl::RegistryLoader At least in 2.0.1, that causes this error: Bareword "Apache2::ServerUtil::server_root" not allowed while "strict subs" in use at /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/ModPerl/RegistryLoader.pm line 74. However, the script properly uses Apache2::ServerUtil, which does indeed have a subroutine called server_root. This is not a problem when Apache uses the module, only when you try to compile a command-line script that uses ModPerl::RegistryLoader. Why would I want to do that, you ask? Well, we have a test suite that makes sure all our scripts compile. One of those scripts is our mod_perl startup script, which uses ModPerl::RegistryLoader. So, it would be nice if it would compile from the command line. There's no reason for it *not* to compile--I can't figure out why it's failing. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services
Re: ModPerl::RegistryLoader doesn't compile from the command line
On Fri, 2006-08-18 at 14:03 -0400, Perrin Harkins wrote: > You can't do that. These are APIs to apache internals. They don't work > without the httpd environment. Ah, okay. Thanks for the explanation. Changing it to Apache2::ServerUtil->server_root would probably at least make it work at compile-time, I suppose, though. > You need to use Apache-Test for the mod_perl bits if you want to do > that. Okay, good to know. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services
Re: opinions of mod_perl users on MIME email sending
On Mon, 18 Jun 2007 16:51:18 +0100 John ORourke <[EMAIL PROTECTED]> wrote: > I'm wondering what modules people use for sending email? We usually use the Email:: modules. (We use Email::Send for sending messages.) The API is really simple, and the maintainer is very responsive. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: [mod_perl2] PerlSwitches having no effect?
On Wed, 18 Jul 2007 07:14:54 -0700 (PDT) "Kevin Field" <[EMAIL PROTECTED]> wrote: > PerlSwitches -wT > LoadFile "C:\Perl\bin\perl58.dll" > LoadModule perl_module modules/mod_perl.so I don't know too much about Apache configuration, but you've put "PerlSwitches", which is defined in mod_perl.so, before you even load mod_perl.so. PerlSwitches should be set before the Perl *interpreter* is loaded, not before the module is loaded. Also, my PerlSwitches looks like: PerlSwitches -w -T I forget, but they may have to be separate. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Apache2::SizeLimit & Linux::Smaps on x86_64
I have an x86_64 machine running RHEL5 but with the mod_perl
2.0.3 from Fedora 7.
Without Linux::Smaps installed, Apache2::SizeLimit thinks my
processes are taking up 300MB and terminates them after every hit.
("top" thinks so too, but "free -m" quickly proves that's untrue.)
With Linux::Smaps, Apache2::SizeLimit simply doesn't work at
all, because Linux::Smaps apparently doesn't work under x86_64.
See this RT bug I filed against Linux::Smaps:
http://rt.cpan.org//Ticket/Display.html?id=29803
I do have a kernel that supports smaps, 2.6.18.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Sat, 6 Oct 2007 00:39:42 -0400 "Perrin Harkins" <[EMAIL PROTECTED]> wrote: > If top can't figure out how much memory a process is using, I don't > see how SizeLimit is going to. Is it possible they really are using > that much, but a lot of it is shared via copy-on-write? Yes, they really are using that much but nearly all of it is shared via copy-on-write, as far as I can tell. SizeLimit is supposed to be able to detect that situation on modern kernels if you have Linux::Smaps installed, according to its docs. (I have only MAX_UNSHARED_SIZE set.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Sun, 07 Oct 2007 21:14:23 +0200 Clinton Gormley <[EMAIL PROTECTED]> wrote: > Max - try using this script to see where your memory is being used: > > http://www.contrib.andrew.cmu.edu/~bmaurer/memory/smem.pl Hrm, okay. I've attached the output of your smem script, which curiously seemed to work just fine, even without any patch, though it does throw those warnings with -w. With the patch, it doesn't throw the "portable" warnings. (Of course.) So it looks like it works fine for what smem is doing, but it somehow doesn't work right for Apache2::SizeLimit. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. VMSIZE: 338044 kb RSS: 44856 kb total 44536 kb shared 0 kb private clean 320 kb private dirty PRIVATE MAPPINGS vmsize rss clean rss dirty file 40676 kb0 kb 180 kb 88 kb0 kb 28 kb [stack] 20 kb0 kb 16 kb 16 kb0 kb 12 kb /usr/sbin/httpd 8 kb0 kb8 kb /usr/lib64/libaprutil-1.so.0.2.7 12 kb0 kb8 kb 16 kb0 kb8 kb 4 kb0 kb4 kb /lib64/ld-2.5.so 8 kb0 kb4 kb 4 kb0 kb4 kb 4 kb0 kb4 kb /usr/lib64/libapr-1.so.0.2.7 4 kb0 kb4 kb /lib64/libpthread-2.5.so 16 kb0 kb4 kb 4 kb0 kb4 kb 4 kb0 kb4 kb /lib64/libc-2.5.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_log_config.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_status.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_rewrite.so 8 kb0 kb4 kb /usr/lib64/httpd/modules/mod_proxy.so 20 kb0 kb4 kb /usr/lib64/httpd/modules/mod_python.so 4 kb0 kb4 kb /lib64/libnss_files-2.5.so 12 kb0 kb4 kb SHARED MAPPINGS vmsize rss clean rss dirty file 40676 kb0 kb40172 kb 456 kb0 kb 452 kb 1296 kb 384 kb0 kb /lib64/libc-2.5.so 260 kb0 kb 256 kb 444 kb0 kb 216 kb /usr/lib64/httpd/modules/libphp5.so 308 kb 208 kb0 kb /usr/sbin/httpd 196 kb0 kb 196 kb 260 kb0 kb 188 kb 260 kb0 kb 188 kb 184 kb0 kb 160 kb /usr/lib64/libpython2.4.so.1.0 124 kb0 kb 124 kb /lib64/libcrypto.so.0.9.8b 152 kb 112 kb0 kb /usr/lib64/libapr-1.so.0.2.7 112 kb 68 kb0 kb /usr/lib64/libaprutil-1.so.0.2.7 84 kb 52 kb0 kb /lib64/libpthread-2.5.so 212 kb 52 kb0 kb /usr/lib64/httpd/modules/mod_perl.so 52 kb0 kb 48 kb 56 kb 44 kb0 kb /usr/lib64/httpd/modules/mod_rewrite.so 1196 kb 44 kb0 kb /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl 104 kb 40 kb0 kb /lib64/ld-2.5.so 64 kb 40 kb0 kb /usr/lib64/httpd/modules/mod_proxy.so 108 kb 36 kb0 kb /lib64/libpcre.so.0.0.1 36 kb0 kb 36 kb /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl 36 kb0 kb 36 kb /usr/lib64/libxml2.so.2.6.26 1024 kb 36 kb0 kb /usr/lib64/libpython2.4.so.1.0 32 kb0 kb 32 kb 88 kb0 kb 32 kb [stack] 28 kb0 kb 28 kb /usr/lib64/libaspell.so.15.1.3 156 kb 28 kb0 kb /usr/lib64/httpd/modules/mod_ssl.so 24 kb0 kb 24 kb /lib64/libssl.so.0.9.8b 24 kb0 kb 24 kb /usr/lib64/libstdc++.so.6.0.8 40 kb 24 kb0 kb /lib64/libnss_files-2.5.so 20 kb0 kb 20 kb /lib64/libdb-4.3.so 24 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_auth_digest.so 24 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_proxy_http.so 96 kb 20 kb0 kb /usr/lib64/httpd/modules/mod_python.so 16 kb0 kb 16 kb /lib64/libc-2.5.so 20 kb0 kb 16 kb 16 kb0 kb 16 kb /usr/lib64/libkrb5.so.3.2 16 kb0 kb 16 kb /usr/lib64/httpd/modules/mod_perl.so 20 kb0 kb 16 kb /usr/lib64/httpd/modules/mod_python.so 964 kb 12 kb0 kb /lib64/libdb-4.3.so 12 kb0 kb 12 kb /lib64/libexpat.so.0.5.0 20 kb 12 kb0 kb /usr/lib64/httpd/modules/mod_log_config.so 28 kb 12 kb0 kb /usr/lib64/httpd/modules/mod_negotiation.so 16 kb 12 kb0 kb /usr/lib64/httpd/modules/mod_pro
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Sun, 7 Oct 2007 14:29:30 -0700 Max Kanat-Alexander <[EMAIL PROTECTED]> wrote: > Hrm, okay. I've attached the output of your smem script, > [snip] And in case it helps, here's the gzipped output of smaps for the same process. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. httpd-smaps.gz Description: GNU Zip compressed data
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Mon, 8 Oct 2007 08:26:51 +0200 Torsten Foertsch <[EMAIL PROTECTED]> wrote: > In your modperl environment "use warnings FATAL=>qw/all/" is active. > Hence, the portable warning is turned into a portable error. That's > all. No, because it still doesn't work, even with the patch. I don't even see the warning. The error I get from SizeLimit is: Can't call method "all" on an undefined value at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Apache2/SizeLimit.pm line 113. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Mon, 8 Oct 2007 09:45:58 +0200 Torsten Foertsch <[EMAIL PROTECTED]> wrote: > Is it possible that your httpd cannot access /proc/self/smaps? Yes, that seems to be the problem. It can stat it, but not read it. In order to find this out, I had to make Linux::Smaps::update return $I when it fails, and check ->lasterror inside SizeLimit. I suspect SELinux, at the moment. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Mon, 8 Oct 2007 01:35:02 -0700 Max Kanat-Alexander <[EMAIL PROTECTED]> wrote: > I suspect SELinux, at the moment. Okay, it's not SELinux. For some reason, smaps is set root:root 400 for all processes, even though /proc/$$/ is properly owned by the "apache" user. I'll have to investigate how to change that, I suppose. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Apache2::SizeLimit & Linux::Smaps on x86_64
On Mon, 8 Oct 2007 01:38:23 -0700 Max Kanat-Alexander <[EMAIL PROTECTED]> wrote: > Okay, it's not SELinux. For some reason, smaps is set > root:root 400 for all processes, even though /proc/$$/ is properly > owned by the "apache" user. I'll have to investigate how to change > that, I suppose. Okay, it seems to be a bug or intentional security modification in RHEL. I've filed a bug against RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=322881 Thanks for all your help, Torsten. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
Re: Fwd: CPAN Upload: O/OP/OPI/Linux-Smaps-0.04.tar.gz
On Mon, 8 Oct 2007 17:52:46 +0200 Torsten Foertsch <[EMAIL PROTECTED]> wrote: > this version mainly disables the portable warning. Further the > constructor now throws an exception if the smaps file cannot be read. > Also a short note in the docs about swapped pages and mlockall(2) was > added. Great, thanks. :-) And it looks like Red Hat may take a look at the bug that prevents it from working on RHEL. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.
