Releasing an independent Apache::SizeLimit to CPAN?
Apache::SizeLimit has a long-standing bug on Linux where it never actually kills a child, because of Perl's caching of ppid info internally, and the way this interacts with Apache's forking. See this thread for details: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/[EMAIL PROTECTED] At $DAYJOB, we have a hacked version that works around this problem. I'd like to release a version with a less hack-y fix to CPAN so we can stop maintaining a forked version in-house. Are there any objections to me doing this? I'd need someone with maintainer privs for mod_perl1 to give me co-maintainership of that module for it to get indexed, obviously. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Dave Rolsky wrote: Apache::SizeLimit has a long-standing bug on Linux where it never actually kills a child, because of Perl's caching of ppid info internally, and the way this interacts with Apache's forking. See this thread for details: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/[EMAIL PROTECTED] At $DAYJOB, we have a hacked version that works around this problem. I'd like to release a version with a less hack-y fix to CPAN so we can stop maintaining a forked version in-house. Are there any objections to me doing this? uh, yeah. how about you submit the patch here and we incorporate it? just uploading modules to CPAN that collide with the namespace of existing modules that are part of a distrubution isn't the way things typically work. I mean, you wouldn't ask this of p5p for a module like, say, Storable, would you? --Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Dave Rolsky wrote: Apache::SizeLimit has a long-standing bug on Linux where it never actually kills a child, because of Perl's caching of ppid info internally, and the way this interacts with Apache's forking. See this thread for details: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/[EMAIL PROTECTED] You're saying that it always thinks it is in the main process even though it's actually in a child? I haven't seen this behavior. Is it specific to certain versions of Perl or Linux? - Perrin
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Fri, 16 Jun 2006, Geoffrey Young wrote: Dave Rolsky wrote: Apache::SizeLimit has a long-standing bug on Linux where it never actually kills a child, because of Perl's caching of ppid info internally, and the way this interacts with Apache's forking. See this thread for details: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/[EMAIL PROTECTED] At $DAYJOB, we have a hacked version that works around this problem. I'd like to release a version with a less hack-y fix to CPAN so we can stop maintaining a forked version in-house. Are there any objections to me doing this? uh, yeah. how about you submit the patch here and we incorporate it? just uploading modules to CPAN that collide with the namespace of existing modules that are part of a distrubution isn't the way things typically work. I mean, you wouldn't ask this of p5p for a module like, say, Storable, would you? Yes, I would. In fact, Storable _is_ on CPAN separate from the Perl core _right now_, and has been for a really long time. It's called dual-lifing a module in p5p-speak. But I wasn't saying I'm going to release it, screw you. I was saying I'd like to release a bug-fixed version, because I have no idea when mod_perl 1.30 will come out, if ever, but I can fix this bug and release Apache::SizeLimit 0.04 right now. There's no good reason for Apache::SizeLimit to only be available as part of the whole big mod_perl bundle. It's basically just another handler like many other modules and CPAN, and having it be possible to update it separately from mod_perl is a _good_ thing. It de-couples two things which are only coupled for historical reasons. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Fri, 16 Jun 2006, Perrin Harkins wrote: Dave Rolsky wrote: Apache::SizeLimit has a long-standing bug on Linux where it never actually kills a child, because of Perl's caching of ppid info internally, and the way this interacts with Apache's forking. See this thread for details: http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/[EMAIL PROTECTED] You're saying that it always thinks it is in the main process even though it's actually in a child? I haven't seen this behavior. Is it specific to certain versions of Perl or Linux? We saw this with Perl 5.8.4 on Ubuntu Hoary. I think it's specific to Linux from reading the thread. My plan was to just use Linux::Pid on Linux systems, because from my testing it's version of getppid does the right thing. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Fri, 16 Jun 2006, Dave Rolsky wrote: But I wasn't saying I'm going to release it, screw you. I was saying I'd like to release a bug-fixed version, because I have no idea when mod_perl 1.30 will come out, if ever, but I can fix this bug and release Apache::SizeLimit 0.04 right now. I should also note that part of the whole dual-lifing thing is that the person who maintains the CPAN version provides patches back to p5p. In this case, I could provide a patch for mod_perl1 if there is any plans to actually release another version of it. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Apache2::Log Filename(line) behaviour
Hi folks, Is there a way to log a debug-level message without Apache2::Log writing the filename and line number of the caller? Could I override something in Apache2::Log? This behaviour is documented in man Apache2::Log. I'm using Log4perl, so every debug-level message comes out with ApacheLog.pm(95) in it, not very useful! John
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Friday 16 June 2006 17:23, Perrin Harkins wrote:
Dave Rolsky wrote:
Apache::SizeLimit has a long-standing bug on Linux where it never
actually kills a child, because of Perl's caching of ppid info
internally, and the way this interacts with Apache's forking.
See this thread for details:
http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3C51EE
[EMAIL PROTECTED]
You're saying that it always thinks it is in the main process even
though it's actually in a child? I haven't seen this behavior. Is it
specific to certain versions of Perl or Linux?
Yes, since 5.8.1. The problem is that the now old linux-threads implementation
returns different values for getpid() and getppid() for different threads.
Hence Perl decides better to cache these values and update the cache on
fork() to make it more compatible with other thread implementations. Since
Apache does its own fork the cache is not updated. Mp2 contains code that
handles the situation but mp1 does not.
For more information see also
http://www.gossamer-threads.com/lists/perl/porters/193162
http://www.gossamer-threads.com/lists/perl/porters/175806
Dave, have you tried the proposed approach from the thread you mentioned?
PerlModule Perl::AfterFork
PerlModule Apache::Constants
PerlInitHandler sub {Perl::AfterFork::reinit(); return Apache::OK;}
or
PerlModule Perl::AfterFork
PerlInitHandler sub {Perl::AfterFork::reinit();}
If you are working on Apache::SizeLimit maybe you could incorporate also
Linux::Smaps for newer kernels. Also the problem of counting out of core
pages could be addressed at least in the docs, see
http://www.gossamer-threads.com/lists/modperl/dev/84375
Torsten
pgp09H0VNlyeb.pgp
Description: PGP signature
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Fri, 16 Jun 2006, Torsten Foertsch wrote: Yes, since 5.8.1. The problem is that the now old linux-threads implementation returns different values for getpid() and getppid() for different threads. Hence Perl decides better to cache these values and update the cache on fork() to make it more compatible with other thread implementations. Since Apache does its own fork the cache is not updated. Mp2 contains code that handles the situation but mp1 does not. For more information see also http://www.gossamer-threads.com/lists/perl/porters/193162 http://www.gossamer-threads.com/lists/perl/porters/175806 Dave, have you tried the proposed approach from the thread you mentioned? Requiring syscall.ph seems like a nasty hack to me. That _is_ what we've done with our local version here at Socialtext, but I was planning to use Linux::Pid for a CPAN version, since it seems cleaners. If you are working on Apache::SizeLimit maybe you could incorporate also Linux::Smaps for newer kernels. Also the problem of counting out of core pages could be addressed at least in the docs, see http://www.gossamer-threads.com/lists/modperl/dev/84375 Yeah, I noticed that Apache2::SizeLimit had a bunch of changes. I was thinking I could incorporate those too. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Are there any objections to me doing this? uh, yeah. how about you submit the patch here and we incorporate it? just uploading modules to CPAN that collide with the namespace of existing modules that are part of a distrubution isn't the way things typically work. I mean, you wouldn't ask this of p5p for a module like, say, Storable, would you? Yes, I would. In fact, Storable _is_ on CPAN separate from the Perl core _right now_, and has been for a really long time. It's called dual-lifing a module in p5p-speak. yeah, I know all about those. I just chose a poor example. pick any non-dual one you like, the principle is the same. But I wasn't saying I'm going to release it, screw you. sure sounded that way, but ok. I was saying I'd like to release a bug-fixed version, because I have no idea when mod_perl 1.30 will come out, if ever, but I can fix this bug and release Apache::SizeLimit 0.04 right now. still, you think that would fly on p5p? the change list on mp1 is very small, which is why there hasn't been a release in a while. and you're certainly capable of posting a patch and using CVS instead of maintaining a separate fork. There's no good reason for Apache::SizeLimit to only be available as part of the whole big mod_perl bundle. except that it is. so you're asking to change that. fine, but it needs to be decided on by the maintainers (mainly perrin) whether this separation is, in fact, a good thing, whether we want to pull in the CPAN version on future releases, or drop it and confuse our userbase who thought they would be getting an update on the next release, etc. It's basically just another handler like many other modules and CPAN, and having it be possible to update it separately from mod_perl is a _good_ thing. perhaps. It de-couples two things which are only coupled for historical reasons. sure. but like I said, it's just a bit more complex when you consider what this will mean for users and the complexity of future mod_perl releases. so, to that end, I'd suggest starting up a hey, what do we do with Apache::SizeLimit and other modules that might benefit from a separate life on CPAN? personally, it doesn't matter to me what the outcome is so long as the main people responsible for managing releases agree. one thing for sure, though, I'd really prefer to see both mp1 and mp2 supported in a single release if Apache::SizeLimit does have a new, separate life on CPAN... --Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
supported in a single release if Apache::SizeLimit does have a new, separate life on CPAN... I'm not sure thats easily possibly with one module because its Apache::SizeLimit AND Apache2::SizeLimit. If you put Apache::SizeLimit on CPAN which supported both, we'd probably have to remove the one from modperl2-svn and any existing modperl 2 installations would need to go back and change there httpd.conf/startup.pl to use it again. By doing so, that would be directly the opposite of what our API rename readme said to do. I'd actually rather just see mod_perl1.30 get released. So what if the change set it small it should really only be bugfix/security anyway at this point. So what if 1.31 only has 1 change over 1.30. Isn't that how maintenance releases work best ? At least according to the docs Stas wrote, I think he was hoping Apache::GtopLimit would obsolete Apache(2)::SizeLimit once it ran on enough architectures. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F It takes a minute to have a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone...
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Fri, 16 Jun 2006, Geoffrey Young wrote: But I wasn't saying I'm going to release it, screw you. sure sounded that way, but ok. I apologize. Note the question mark in the title of this thread. I thought I was offering to help the mod_perl project, honestly. I was saying I'd like to release a bug-fixed version, because I have no idea when mod_perl 1.30 will come out, if ever, but I can fix this bug and release Apache::SizeLimit 0.04 right now. still, you think that would fly on p5p? the change list on mp1 is very Yes, it would fly on p5p. I did it with Time::Local, for example. In fact, p5p is very much in favor of dual-lifing modules, from what I can tell. Making something dual-life from the Perl core is relatively matter-of-fact these days. Heck, even very internal-y things like Threads.pm have been dual-lifed. small, which is why there hasn't been a release in a while. and you're certainly capable of posting a patch and using CVS instead of maintaining a separate fork. The reason I want to release this is because we use Apache::SizeLimit at my day job. We're planning to open source our code eventually, and we don't want to release a forked Apache::SizeLimit, obviously. That means either getting a fixed version on CPAN or renaming our version to Socialtext::Apache::SizeLimit. I think the former is better since it benefits all mod_perl 1.x users. Waiting for mod_perl 1.30 is really not an option. We can't have much impact over when that will come out, and I don't think we'd want to make that a prereq anyway. 1.29 is 2.5 years old, so pretty much every modern distro has it available as package. 1.30, even if it came out tomorrow, would be too new to make a prereq. Telling people who go to install our app that they need to install Apache::SizeLimit plus some random patch on our servers would be pretty user-unfriendly. That's not how you make a nice install process for folks. We want to say you need mod_perl 1.29 plus Apache::SizeLimit 0.04, and have them be able to get that stuff via packages and/or CPAN, just like everything else. separation is, in fact, a good thing, whether we want to pull in the CPAN version on future releases, or drop it and confuse our userbase who thought they would be getting an update on the next release, etc. Like I said, I'd be happy to provide patches back to the mod_perl folks against what's in your tree. If a 1.30 is planned, I'd work with the maintainer to make sure that Apache::SizeLimit in the tree was up to date with what's on CPAN. Frankly, I'm kind of insulted you'd think I'd make this a lot of work for the maintainer. I think I have a pretty good history of being a good free software citizen, especially in the Perl and mod_perl worlds. Please give me some credit here. so, to that end, I'd suggest starting up a hey, what do we do with Apache::SizeLimit and other modules that might benefit from a separate life on CPAN? personally, it doesn't matter to me what the outcome is No, let's not start that thread, please. I'm not proposing to maintain any other modules, and I don't want to have an Apache::SizeLimit release gate on a decision about every other module. I'm proposing something small, simple, and doable in a short time frame. If I do this and it inspires other people to come along and dual-life something else, that'd be great, I think. so long as the main people responsible for managing releases agree. one thing for sure, though, I'd really prefer to see both mp1 and mp2 supported in a single release if Apache::SizeLimit does have a new, separate life on CPAN... What Philip said ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Releasing an independent Apache::SizeLimit to CPAN?
Philip M. Gollucci wrote: supported in a single release if Apache::SizeLimit does have a new, separate life on CPAN... I'm not sure thats easily possibly with one module because its Apache::SizeLimit AND Apache2::SizeLimit. so. it's just a namespace - Apache2::SizeLimit could simply be a thin wrapper around Apache::SizeLimit, throwing a nice critical log message to change to the real Apache::SizeLimit, please. If you put Apache::SizeLimit on CPAN which supported both, we'd probably have to remove the one from modperl2-svn and any existing modperl 2 installations would need to go back and change there httpd.conf/startup.pl to use it again. there are ways around that that won't hurt so bad, like the above. By doing so, that would be directly the opposite of what our API rename readme said to do. that's fine. _someone_ is going to have to change, be it mp1 or mp2 users if we roll this out to CPAN. or we will, by including a cpan pull when we roll a release. I'd actually rather just see mod_perl1.30 get released. So what if the change set it small it should really only be bugfix/security anyway at this point. So what if 1.31 only has 1 change over 1.30. Isn't that how maintenance releases work best ? I wasn't against a release. I was just saying there's a reason it hasn't been released lately :) At least according to the docs Stas wrote, I think he was hoping Apache::GtopLimit would obsolete Apache(2)::SizeLimit once it ran on enough architectures. well, first things first :) look, if we release Apache::SizeLimit to cpan then we're essentially giving up control of it in mod_perl core. that's fine, so long as we let users know. but I'm bothered that we'd have something on CPAN that is 99% the same between mp1 and mp2, leaving us core maintainers with extra work keeping them in sync, which is much harder when one is outside our control and in the CPAN wild. let's just get them working together in the same distribution, put in on cpan, and pull it into each mod_perl release as they happen... --Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
I apologize. Note the question mark in the title of this thread. I thought I was offering to help the mod_perl project, honestly. my last comment was meant to be an understanding as well, but it didn't come off that way. sorry. if we didn't know eachother in person then I might have spent more time trying to iron out the wrinkles in everything I write... so, ok, we're cool. I'll buy you some thai in portland. moving on :) --Geoff
Re: Releasing an independent Apache::SizeLimit to CPAN?
Geoffrey Young wrote: let's just get them working together in the same distribution, put in on cpan, and pull it into each mod_perl release as they happen... +1 here. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F It takes a minute to have a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone...
Serious mod_perl-2 test issues
I'm compiling Apache-2.2.2 with mod_perl-2 on OpenBSD 3.9 as well as a with a manually compiled perl-5.8.8. The issues I'm having is at the mod_perl test suite, these are the results: ~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! ~!~!~!~!~!~!~!~!~!~!~ Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/content_length_header.t 271 3.70% 17 t/api/status.t 62 33.33% 4-5 t/apr-ext/base64.t 011 36 200.00% 1-3 t/apr-ext/brigade.t 2 512?? ?? % ?? t/apr-ext/bucket.t 2 512?? ?? % ?? t/apr-ext/date.t01114 28 200.00% 1-14 t/apr-ext/finfo.t 2 512?? ?? % ?? t/apr-ext/pool.t2 512?? ?? % ?? t/apr-ext/string.t 011 5 10 200.00% 1-5 t/apr-ext/table.t 2 512?? ?? % ?? t/apr-ext/threadmutex.t 2 512?? ?? % ?? t/apr-ext/uri.t 2 512?? ?? % ?? t/apr-ext/util.t011 48 200.00% 1-4 t/apr-ext/uuid.t011 34 133.33% 2-3 8 tests skipped. Failed 14/231 test scripts, 93.94% okay. 31/2048 subtests failed, 98.49% okay. [warning] server localhost.rutski89.com:8529 shutdown [ error] error running tests (please examine t/logs/error_log) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ *** Error code 1 Stop in /opt/kit/mod_perl-2.0.2 (line 1098 of Makefile). ~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! ~!~!~!~!~!~!~!~!~!~!~ I looked into t/api/status.t and t/apache/content_length_header.t, and the errors there are not to game breaking, so I'll let them slide. What I am worried about however are all the failed t/apr-ext tests. Here is a snippet showing how these t/apr-ext tests fail because of this strange undefined symbol issues. ~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! ~!~!~!~!~!~!~!~!~!~!~ t/apr-ext/brigade.../opt/perl/bin/perl:/opt/kit/ mod_perl-2.0.2/blib/arch/auto/APR/Pool/Pool.so: undefined symbol 'apr_pool_cleanup_null' Can't load '/opt/kit/mod_perl-2.0.2/blib/arch/auto/APR/Pool/Pool.so' for module APR::Pool: Cannot load specified object at /opt/perl/lib/ 5.8.8/OpenBSD.i386-openbsd/DynaLoader.pm line 230. at /opt/kit/mod_perl-2.0.2/blib/lib/APR/XSLoader.pm line 30 Compilation failed in require at /opt/kit/mod_perl-2.0.2/t/lib/ TestAPRlib/brigade.pm line 14. BEGIN failed--compilation aborted at /opt/kit/mod_perl-2.0.2/t/lib/ TestAPRlib/brigade.pm line 14. Compilation failed in require at t/apr-ext/brigade.t line 7. BEGIN failed--compilation aborted at t/apr-ext/brigade.t line 7. ~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! ~!~!~!~!~!~!~!~!~!~!~ I get the same types of errors for each other t/apr-ext/ test as well, but I didn't feel the need to post them all. The test t/apr-ext/uuid.t says: # XXX: only when apr-config is found APR will be linked against # libapr/libaprutil, probably need a more intuitive method for this # prerequisite # also need to check whether we build against the source tree, in # which case we APR.so won't be linked against libapr/libaprutil After reading this I ran an ldd on /opt/apache2/httpd (my manually compiled version of apache) and saw that it was liking against the system's APR, and not it's own. AHAH! I thought. I thought the solution would be to build apr and apr-util from source as dictated in the apr/apr-util = 1.2 section in these docs: http:// httpd.apache.org/docs/2.2/install.html So I did, and then I configured and built and tested mod_perl-2 with: perl Makefile.PL MP_APXS=/opt/apache2/bin/apxs MP_APR_CONFIG=/opt/apr/ bin/apr-1-config make make test But alas, I got the same unresolved symbol errors on the make test part. What in the world am I supposed to do to fix this? I'm totally at a loss :-( Patrick R.
ssl functions ?
this is a longshot... i need to generate rsa pairs in my mod-perl app i tried the cpan modules, and they're all slowslowslow so then i thought 'ok, i'll just pipe to openssl'. that works. but then i'm out the door just now to get a drink and play some buck hunt and i think- shit. could i access the ssl stuff through apache? could i compile apache with ssl support, then just access those internal functions through modperl ? its a longshot, but i figured it would save me a ton of overhead if the implementation is already there anyone know if i'm onto something or have the expertise with the modssl / mp core code to know that i'm waaay waaay off? | - - - - - - - - - - - - - - - - - - - - | RoadSound.com / Indie-Rock.net | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - -
