Re: installation problems
Chris wrote: >>will wrote: >> >>>I am trying to install mod perl as part of Apache-ASP and am stuck at >>>the following error: >>> >>> >>> >>>>Apache.exe -k start >>> >>are you mixing Apache 2.0 with mod_perl 1.0? -k is an Apache 2.0 option > > > um ... I use: > > c:\apache\apache.exe -k start > > all the time under Apache 1.3.22 for Win32. Oops, that must be win specific in 1.3. In 2.0 it's on all platforms. So much for guessing things that reports should include. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: installation problems
will wrote: > I am trying to install mod perl as part of Apache-ASP and am stuck at the > following error: > > >>Apache.exe -k start are you mixing Apache 2.0 with mod_perl 1.0? -k is an Apache 2.0 option whenever reporting problems you have to tell us what you are doing and what versions you are using see: http://perl.apache.org/release/docs/1.0/guide/help.html#How_to_Report_Problems http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems > Can't locate Cwd.pm in @INC (@INC contains: .) at (eval 1) line 1. > > I've searched the web and haven't found any solutions. > I have checked the perl @INC using 'perl -V' and the path to Cwd.pm is > there: > > @INC: > C:/Perl/lib > C:/Perl/site/lib > . > > but it only seems to actually be looking at the current directory. Not sure > what to do next, or where to change these paths. I'm wondering if I need \s > instead of /s? > > thanks for any help? > > will -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Bill O'Hanlon wrote: > (Apologies if you see this twice -- I sent it from an unsubscribed > email address first.) > > > Hi folks, > > I just ran down a problem that was somewhat hard to find, and I didn't see any > mention of anything like it in the archives anywhere. I thought it might be > helpful to mention the details in case someone else is ever in the same > situation. > > I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working > installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd > get it running under Apache::Registry in mod_perl. To my surprise, the Apache > daemons would dump core whenever I tried to log in with manage.cgi. > > It turns out that the current FreeBSD port of Apache uses it's own internal > version of "expat", which is an XML library of some kind. This internal > version doesn't connect up well with the version that XML::Parser is expecting > to find. Turning this off in the Apache build fixed the problem, and the > OpenSRS code runs very nicely under mod_perl now. At this point, I don't > understand what functionality I've lost by not having the expat code built into > the Apache binary. > > The configure option to leave out expat is "--disable-rule=EXPAT". In the > FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the > Makefile. > > I don't know if this applies to any other platform. My guess is that it could, > since I think the default for Apache is to use the internal version of expat. > > Hope this helps someone! Thanks for this contribution Bill, but it has been documented for a long time in the guide: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#Segfaults_when_using_XML__Parser __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache Error Log
steve wrote: > Hey people.. > > Wondering if someone could help me with this... Please do not repost your question 3 times! > I recently started using modperl2/apache2. Everything seems to work ok > except for Apache's error logging. > I don't seem to get my apache stderr untill I shutdown/restart the > server. Then it prints out the whole > thing in one big batch. I read somewhere that modperl possibly takes > over the logging handler for apache > but I tried a PerlOptions -Log in the conf file and that doesn't seem to > help. '-' turns options off, not the other way around. http://perl.apache.org/release/docs/2.0/user/config/config.html#PerlOptions_Directive And it's +Log by default. > I posted my configuration along with this.. i don't really know what I'm > doing when it comes to modperl2 > so any help is appreciated.. thanks Are you talking about warn() and similar calls? You have to post a short code that we can reproduce the problem with and your build as explained here: http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems Also check: http://perl.apache.org/release/docs/2.0/api/mod_perl-2.0/Apache/Log.html __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [OT] mod_perl obfuscation / T-shirt ?
>> I was thinking about doing a mod_perl Obfuscation for some time, and >> today I >> found some time and wrote up something .. It's not that much obfusacated, >> but it looks nice (mod_perl in ASCII art) and works (see the POD after >> the >> code..) > tres cool. yes, very cool Thomas, looks like a good idea for the new modperl site's obfuscation section :) ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl_Tstack_sp_ptr
could this be a version of freebsd with broken threads support? i've
> heard many cases of that. chances are if you rebuild perl without
> -Dusethreads and apache with the prefork mpm, this problem won't be
there.
so the problem that I see on linux is unrelated?
this tested with prefork Apache cvs and perl built as:
./Configure -des -Dprefix=/home/stas/perl/5.6.1-ithread \
-Dusethreads -Doptimize='-g' -Duseshrplib -Dusedevel
Stas Bekman wrote:
> Paul G. Weiss wrote:
>
>> Sorry if this has been covered - I searched to no avail.
>>
>> I'm getting the following error when trying to start
>> an Apache 2.0.36 with ModPerl::Registry:
>>
>> /usr/libexec/ld-elf.so.1:
>> /usr/lib/perl5/site_perl/5.6.1/i386-freebsd-thread-multi/auto/Apache/Request
>>
>> Rec/RequestRec.so: Undefined symbol "Perl_Tstack_sp_ptr"
>>
>> All relevant build info is below. Has anyone seen and conquered this?
>
>
> Confirmed, I've a similar problem on linux with 5.6.1
>
> /home/stas/httpd/prefork/bin/httpd: relocation error:
>
>/home/stas/apache.org/mp-5.6.1-prefork/ModPerl-Registry/t/../../blib/arch/Apache2/auto/Apache/RequestIO/RequestIO.so:
>
> undefined symbol: Perl_sv_2pv
>
> it happens when I run the test suite in:
>
> ModPerl-Registry:
>
> and I've traced it down to:
> print exists $ENV{QUERY_STRING} && $ENV{QUERY_STRING};
>
> Though I don't understand why there is relocation error, the libperl.so
> lib includes the symbol:
> nm
> /home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
> | grep Perl_sv_2pv
> 0009ae10 T Perl_sv_2pv
>
> and mod_perl is linked against it:
> ldd src/modules/perl/mod_perl.so
> libperl.so =>
> /home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
> (0x40023000)
>
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: sub init() ... does this have any special purpose?
Mark Korey wrote: > I was once told that in order for mod_perl CGI code to > work properly all functionality/logic needed to reside > in a function named "init()". Now that I'm pouring over > mod_perl documentation & getting things running, I haven't > found any mention of this. > > So ... is there any special purpose w/in mod_perl for "sub init"? > or is it just a common naming convention? > or is it baloney? There is nothing special about init(). Are you talking about initializing globals? or the closure effect with registry? That's two possible issues people may talk about a sub whose name can be init() or else. In your example there is no need for init(). ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl_Tstack_sp_ptr
Paul G. Weiss wrote:
> Sorry if this has been covered - I searched to no avail.
>
> I'm getting the following error when trying to start
> an Apache 2.0.36 with ModPerl::Registry:
>
> /usr/libexec/ld-elf.so.1:
> /usr/lib/perl5/site_perl/5.6.1/i386-freebsd-thread-multi/auto/Apache/Request
> Rec/RequestRec.so: Undefined symbol "Perl_Tstack_sp_ptr"
>
> All relevant build info is below. Has anyone seen and conquered this?
Confirmed, I've a similar problem on linux with 5.6.1
/home/stas/httpd/prefork/bin/httpd: relocation error:
/home/stas/apache.org/mp-5.6.1-prefork/ModPerl-Registry/t/../../blib/arch/Apache2/auto/Apache/RequestIO/RequestIO.so:
undefined symbol: Perl_sv_2pv
it happens when I run the test suite in:
ModPerl-Registry:
and I've traced it down to:
print exists $ENV{QUERY_STRING} && $ENV{QUERY_STRING};
Though I don't understand why there is relocation error, the libperl.so
lib includes the symbol:
nm
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
| grep Perl_sv_2pv
0009ae10 T Perl_sv_2pv
and mod_perl is linked against it:
ldd src/modules/perl/mod_perl.so
libperl.so =>
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
(0x40023000)
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: OSC early bird and mod_perl T-Shirts
Leon Brocard wrote: > Stas sent the following bits through the ether: > > SB> 2. We want T-Shirts. Is there some kind company to sponsor the > SB> mod_perl T-Shirts this year? > > I've just convinced my company (http://www.fotango.com/) to sponsor 50 > tshirts with the mod_perl logo on. Once we get it all sorted out, > we'll print them in the UK and fly them over with us to OSCON. I guess > they will be allocated in a first-come first-served order. More > details when I get it sorted out. That's fantastic Leon! Thanks for convincing your company to do that for us. To those who want to print mod_perl T-Shirts for themselves we need a nice design which can then be put on the site. So if you know a designer willing to help us here, please do that! And of course if other companies can contribute too, that would be great. I doubt 50 T-shirts will satify everybody :) ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: libapreq: could not create/open temp file
Jean-Denis Girard wrote:
> Hi,
>
> Has anybody already seen this error ???
>
> The problem happens on a web site which has been online for the last 2
> years without trouble.
> We are using the proxied Apache_1.3.20 / mod_perl-1.24, behind a light
> front end Apache_1.3.20 / mod_ssl / mod_proxy_add_forward, on a Linux
> server.
>
> Last week we upgraded most components of the system (kernel,
> libraries...) including Perl (5.6.0 to 5.6.1), then recompiled Apache,
> mod_ssl, mod_perl, libapreq-0.33, and rebooted (Apache, mod_ssl,
> mod_perl upgrade was planned for this month).
>
> Everything worked flawlesly, the web site was still working, but after a
> few days, visitors started to complain that uplaods didn't work.
> mod_perl dies with the message:
> [libapreq] could not create/open temp file
> What is really funny, is that it works after rebooting the system, and
> the error shows up later.
> I upgraded libapreq to 1.0, which didn't solve the problem. Next step
> will be to upgrade APache, mod_perl, etc. but I would like some help.
Let's try to change apreq to give the real system error message, that
should help. Try the patch at the end. Also apreq has its own list,
[EMAIL PROTECTED]
Index: c/apache_request.c
===
RCS file: /home/cvs/httpd-apreq/c/apache_request.c,v
retrieving revision 1.20
diff -u -r1.20 apache_request.c
--- c/apache_request.c 18 Feb 2002 16:48:27 - 1.20
+++ c/apache_request.c 8 Jun 2002 04:41:08 -
@@ -359,7 +359,9 @@
}
if ( tries == 0 || (fp = ap_pfdopen(r->pool, fd, "w+" "b") ) ==
NULL ) {
-
ap_log_rerror(REQ_ERROR, "[libapreq] could not create/open temp file");
+
ap_log_rerror(REQ_ERROR,
+ "[libapreq] could not create/open temp file: %s",
+ strerror(errno));
if ( fd >= 0 ) { remove(name); free(name); }
return NULL;
}
Index: c/apache_request.h
===
RCS file: /home/cvs/httpd-apreq/c/apache_request.h,v
retrieving revision 1.8
diff -u -r1.8 apache_request.h
--- c/apache_request.h 26 Jun 2001 10:58:29 - 1.8
+++ c/apache_request.h 8 Jun 2002 04:41:08 -
@@ -9,6 +9,7 @@
#include "http_main.h"
#include "http_protocol.h"
#include "util_script.h"
+#include
#ifdef SFIO
#include "sfio.h"
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
patch
Description: application/java-vm
Re: open_basedir
Benjamin Blazke wrote: > Hello, > > is there a possibility to limit mod_perl users in the > same way as the PHP 'open_basedir' option does? > > Quoting from the PHP manual: > --- > open_basedir - Limit the files that can be opened by > PHP to the specified directory-tree. > > When a script tries to open a file with, for example, > fopen or gzopen, the location of the file is checked. > When the file is outside the specified directory-tree, > PHP will refuse to open it. All symbolic links are > resolved, so it's not possible to avoid this > restriction with a symlink. > --- patching the open() implementation :) You can override CORE::GLOBAL::open, but users can still use directly CORE::open. But seriously, this won't work in Perl. Your only solution is to use a chroot jail: http://perl.apache.org/release/docs/general/multiuser.html#ISPs_providing_mod_perl_services___a_fantasy_or_a_reality chroot/jail links here: http://perl.apache.org/release/docs/offsite/other.html#Apache ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
OSC early bird and mod_perl T-Shirts
1. http://use.perl.org/article.pl?sid=02/06/06/1810253 gnat writes "Early registration for the Open Source Convention (which includes The Perl Conference) ends June 10. You can save up to $750 if you register before then." 2. We want T-Shirts. Is there some kind company to sponsor the mod_perl T-Shirts this year? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: File-upload problem with netscape and Internet-Explorer
[EMAIL PROTECTED] wrote:
> Hello,
> I build a simple File-Upload form:
>
>
>
>
>
>
> and a script test_upload, which is called from the form:
> <%perl>
> my $file = $r->upload;
> my $ftype = $file->info->{'Content-Type'};
> my $fsize = $file->size;
> my $fname = $file->filename;
> $m->out("$ftype : $fsize : $fname");
>
> <%ARGS>
> $Tfile => undef
>
> With netscape this works well, but with opera and internet-explorer
> (tested with 6.0), $r->upload isnt defined? What am i doing wrong here?
> Bye, Olaf
Try:
http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_with_Apache__Request
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Slava Bizyayev wrote: > It's going to be something like "Features of Content Compression for > Different Web Clients" for Part IV: Client side facts and bugs. We'll be > able to discuss details next week. Sounds great, looking forward to it. Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl 5.6.1 INIT blocks
D.J. Miller II wrote: > Howdy, > > I'm trying to find out if Perl 5.6.1 INIT blocks are supported by > mod_perl. By "supported," I mean that the INIT blocks are executed each > time the scripts containing them are run under mod_perl, not just at > compilation time like BEGIN blocks. In fact they aren't supported at all, when you try to run them from inside requests -- you will get an error: Too late to run INIT block at ... > In the "ToDo" file of the mod_perl 1.26 distribution I find: > > --- > POSSIBLE NEW FEATURES > --- > > - require +ExecCGI for in .htaccess, etc. > > [...] > > - CHECK blocks? [Michael J Schout <[EMAIL PROTECTED]>] > INIT blocks? [T.J. Mather <[EMAIL PROTECTED]>] > > In the 1.27 distribution there's no "ToDo" file, but no mention of INIT > or CHECK block support in the "Changes" file, either. ToDo has moved into the STATUS file. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI Bug
> t/REPORT don't print any problem Udlei, please read the info at the URL I gave to you again. It says: Whenever you send a bug report make sure to include the information about your system by doing the following: % cd modperl-2.0 % t/REPORT > mybugreport Also it explains how to get the backtrace (which is very essential): http://perl.apache.org/release/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: RPM for apache/mod_perl/mod_ssl
Fran Fabrizio wrote: > > We're currently struggling for an easy way to distribute our > apache/mod_perl/mod_ssl-based application to our data center folks who > are in a different state and whom we must presume know nothing about > apache, mod_perl or mod_ssl and are capable of nothing more complicated > than using RPM to install/update a package. > As such, does there exist such a thing as an RPM that installs apache > with mod_perl AND mod_ssl enabled? I presume this would also have to > include openssl. I can only imagine what a pain it would be to create > this beast, but if it's been done, I'd like to give it a try. > > I have used my limited experience with RPM to try to build this kind of > thing, but so far the closest I've gotten is to have an RPM that > includes the four tarballs with a shell script to compile them on the > target machine. Of course this really isn't in the spirit of RPM and > also, fails miserably when the target machine is a hardened machine with > no compiler, for example. :-) > > Does such a thing exist, and what are some pros and cons of going this > route? > > Personally, I would hate to have to rely on an RPM like this, not least > because I'd have to learn how to modify it if it doesn't meet our needs, > but we need to make the application install as easy as possible for the > data center folks. Thoughts? Take an existing src RPM (.spec) and adjust it the way you want. Here are some RPMs: http://perl.apache.org/release/download/binaries.html#RedHat_Linux __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
tutorials (was: Re: rfc Apache::Dynagzip)
Per Einar Ellefsen wrote: > At 15:36 05.06.2002, Valerio_Valdez Paolini wrote: > >> On Tue, 4 Jun 2002, Slava Bizyayev wrote: >> >> > I don't know should it be a kitchen of every system administrator, or >> > somebody could volunteer to serve the public web site about the current >> > conditions of different web clients and recommended masks?.. I can't >> host it >> > on my devl4, because it is a development machine. That would be >> better to >> > find some stable place, like mod_perl, or apache project ;-). >> >> Can you provide a compatibility list? I think that the new mod_perl site >> is looking for new articles, may be the first part of Apache::Dynagzip >> man page is a good candidate... You could add also known bugs and >> features. But I cannot decide what goes on mod_perl site :) > > > Just like I would have said it myself :-) We're clearly looking for > information, and I was especially watching this thread for possible > inclusion. We have a nice place to do this, it's in our "Browser bugs" > section. Depending on the size of the document, it might go there or in > its own doc. Anyway, we welcome any submissions. Format is standard Pod. > See > >http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&content-type=text/vnd.viewcvs-markup > > for style information, but don't worry too much about that, we'll fix > that as we go. I just want to add some clarifications to Per Einar comment. Are we looking for not strictly mod_perl but closely related material, which matters to the majority of mod_perl programmers? The short answer: Tutorials -> yes manpages -> no articles -> take23.org The long answer: Tutorials cover some interesting topics using several implementations. Tutorials are pretty much static and don't require much maintenance. We heartly welcome these. The ongoing discission of MVC is a good example of a tutorial candidate, templating comparison and *generic* tips and tricks are other ones. Manpages, which aren't the core module are not very welcome at this moment, as they usually require high level of maintenance, and we have hardly resources to cope with perl.apache.org. So at least for now, manpages aren't welcome. If you have feature tutorials, either submit those to take23.org or any other online zine. perl.com is looking for such articles. so does apacheweek.com. probable there are others. The new perl.apache.org is not a dump place for docs. The more irrelevant stuff we throw there the less added value the site will have, the harder it'll be to find something and the whole idea of expanding docs will do more bad than good. So new tutorials are definitely welcome, but re-read the first para to see the definition of a good candidate and so the existing tutorials at: http://perl.apache.org/release/docs/tutorials/index.html before submitting your tutorial. If your idea of tutorial doesn't fit into perl.apache.org's tutorial's idea, we will gladly link to it. --- Now back to the topic. If you can submit to us known problems with browsers and solutions that would be great. But please don't submit the Apache::Dynagzip manpage. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache->server_root_relative(); not found
m31 wrote: > I think we've narrowed it down to three choices, but why would my @INC > list one thing from the terminal and another from mod_perl? Are they two > seperate @INC's? mod_perl adds a few dirs to @INC on its own, but I still cannot understand what is your problem. Let's say you want to add '/Library/www/lib' to @INC. So inside startup.pl you do: use lib qw(/Library/www/lib); and that's it! Remember that you cannot affect @INC for the whole server from your handlers/scripts, as it gets reset after each request to the value it had after startup, so you can only change it during startup. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: DBI Bug
Perrin Harkins wrote: > Udlei Nattis wrote: > >> hi, sorry my english ;) >> >> when i add this line in httpd.conf >> >> PerlModule DBI >> >> or >> >> use DBI(); in startup.conf >> >> apache dont start, i receive this error: >> >> /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation >> fault $HTTPD >> /usr/local/apache-2.0/bin/apachectl start: httpd could not be started >> >> i test it in >> Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03 >> Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03 >> Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03 >> Apache 2.0-cvs/All Perls/All Modperls > > > It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1 combo. > Maybe someone else can verify that they've run DBI under mod_perl 2? Works for me with 1.99, but see below. > You might need to use the pre-fork MPM when using DBI, depending on how > well your database driver works with threads. You should also make sure > you compile all of these with the same compiler, to ensure compatibility > between libraries. Folks, when you see a question like this, don't waste your time guessing in the dark without having the so needed details posted first. Just point them here: http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems You don't have to search for this item, it's in the shortcuts menu on the left. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache.pm failed to load!
[Please make sure to reply to the list on follow-ups, and not to the person who has answered your question. Thank you!] James Kirkland wrote: > Hi, > > Thanks for replying. I continue to get the errors when adding that line to > httpd.conf. Is there any specific point in the file to place it? When do you get this error >>James Kirkland wrote: >> >>>Hi, >>> >>>I am getting the "Apache.pm failed to load!" error. I need help to >>>resolve: >>> >>>[root@fisher mysql]# perl -MApache -e 1 >> >> >>You shouldn't be testing mod_perl modules from the command line. it >>won't work. >> >>If it happens under mod_perl, see: >> > > >http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache.pm failed to load!
James Kirkland wrote: > > Hi, > > I am getting the "Apache.pm failed to load!" error. I need help to > resolve: > > [root@fisher mysql]# perl -MApache -e 1 You shouldn't be testing mod_perl modules from the command line. it won't work. If it happens under mod_perl, see: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache->server_root_relative(); not found
m31 wrote: > Thank you all for your help. You are correct, I didn't dawn on me that > my ServerRoot is somewhat different than my document root. I was > expecting it to return my documenrt root. > (embarasment...hence SERVER_ROOT_relative()) > Well, I printed out my @INC to screen, and now I have directories that > do not exist in it from putting the wrong path in the > server_root_relative method, can any-one tell me how to remove this dir > from @INC? I treid a few ways but to no sucess. Please be more specific. What have you done to @INC so it includes non-existing dirs? You must have added them. A *short* code fragment is the best so we can reproduce the problem. > Please be patient with idiocracy, I'm just a student trying to get ahead. Don't worry :) Just try to provide more details in first place, so there will be less ping-pong emails here. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache->server_root_relative(); not found
On Mon, 3 Jun 2002, m31 wrote:
> Yes, I'm running it under mod_perl/1.27 which I compiled as a DSO with
> apxs. This also gave me errors under 1.25, I just pushed @INC to solve
> it but I would like to use server_root_relative. I have it in a startup
> script, the one from the eagle book. It goes like:
> #! /usr/bin/perl
>
> BEGIN {
> use Apache ();
> use lib Apache->server_root_relative('lib/perl');
> }
>
> use Apache::Registry ();
> use Apache::Constants ();
> use CGI qw(-compile :all);
> use CGI::Carp ();
> use DBI ();
> 1;
>
> Which I had it to change to: push(@INC, '/Library/www/lib/perl');
> because the server_root_relative gave me errors. I read some where that
> in order to test with startup scripts you need to use the
> Apache::FakeRequest? Even if so, if I ignore the errors and just restart
> apache, it wont find 'lib/perl', so I have to push @INC manually then do
> a graceful restart for it to work. I am running OSX 10.1.4/Darwin. Dont
> think that has anything to do with it though.
There are two separate issues here:
1. you try to test perl code which only runs under mod_perl. but according
to your report you don't have a problem calling server_root_relative()
when you start the server. So this is not a problem, right?
2. your problem is that Apache->server_root_relative('lib/perl') doesn't
return what you expect. Is your ServerRoot set to '/Library/www'?
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache->server_root_relative(); not found
m31 wrote:
> HI, sorry if this is the wrong place, I am new to the mailing list.
This is the right place. If you are new to mod_perl, you probably want
to read the docs first. See: http://perl.apache.org/release/docs/
> I have apache/1.3.23 and mod_perl/1.27 (I just upgraded) and perl/5.6.0
>
> When I try:
>
> BEGIN {
>use Apache ();
>use lib Apache->server_root_relative('lib/perl');
> }
>
> I get compilation errors saying that it can't locate object method
> "server_root_relative" via pachage "Apache". BEGIN failed.
>
> Can any-one help me out or point me in the right direction?
Are you sure you are testing this under mod_perl? Also please be more
specific, where did you put this code: in a startup file, a script or a
handler?
You cannot test code including Apache API without running under mod_perl.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
5.8.0 RC1 has been released; please help testing it
s to half an hour is quite normal, but a slow system may easily take an hour or more. If all tests are successful, "make test" will say "All tests successful" (unsurprisingly). If all tests are not successful, you may get a more detailed report by changing to the t/ subdirectory and running the "harness" script, something like this cd t ./perl harness You may need to set up your dynamic library path before that (the final message of "make test" should tell all the needed details). The more detailed report will be very useful when your report problems. Knowing your exact configuration is essential, too: usually running the "myconfig" script from the build directory produces this information. Note that some systems or configurations have known problems, see perldelta for details, no need to report them. In case you still see errors, please document them via the perlbug system, as detailed in the "INSTALL" file, section "Reporting Problems". Finally note that if you happen to have a "less common" platform, like some of the rarer UNIXes, or something even more exotic, we will be glad to hear even of successes, not just about possible problems. =head2 Installing Once you are happy with the test results of Perl itself (or you are just feeling extraordinarily brave), you may consider installing it. The Perl development team has tried to guarantee that popular Perl applications like CGI, LWP, mod_perl and DBI/DBD work with 5.8.0. Note "work", not necessarily "work without warnings": for example DBD::Oracle works, but during compilation and testing you may see various warnings. Also in some cases not all the functionality of the modules may be available (yet). However... THIS IS A REAL NEW PERL RELEASE THAT IS BINARY INCOMPATIBLE WITH ANY PREVIOUS PERL RELEASE. THIS MEANS THAT YOUR OLD EXTENSIONS (.xs code, those Perl modules requiring a C compiler) WILL NOT WORK AND WILL HAVE TO BE RECOMPILED. (Pure Perl modules should continue working.) INSTALLING THIS PERL RELEASE WILL OVERWRITE YOUR CURRENT PERL RELEASE. (For example, /usr/bin/perl will become Perl 5.8.0.) DO NOT INSTALL THIS INTO PRODUCTION USE UNLESS YOU REALLY MEAN IT. If you still feel like installing this, you can do so by "make install". If you want to install this, but want to install it into some less dangerous place (and not overwrite your current installation), do the following make clean sh Configure -des -Dprefix=/test/perl580 -Uinstallusrbinperl make all make test and then the "make install". The -Dprefix will place the Perl installation at the said directory (the Perl executable will be /test/perl580/bin/perl), and the -Uinstallusrbinperl will avoid overwriting /usr/bin/perl with a copy of the Perl 5.8.0 executable. =head1 Testing The Perl Installation You should test both your own code, and other code that you use. =head2 Testing Your Own Code Test your own code with perl 5.8.0, but in case of surprises read the perldelta.pod carefully before judging something as a bug. In some cases the behaviour of Perl has changed. =head2 Testing Perl Modules You should try reinstalling your favourite CPAN modules to guarantee that they will continue working under Perl 5.8. Note that if you find some module either failing its tests or you see the tests emitting warning messages, please first and foremost report these problems to the author of the module. Advise him/her about the impending 5.8.0 release and where to get the RC1 (you might for example point the author to this very message). Since there are hundreds of modules available, the Perl 5 developer team is not qualified to be experts on all of them; it is much faster if the module author resolves any problems. In some cases you may also consider contacting some mailing lists to ask for help (and to spread awareness of the upcoming 5.8.0), for example if your operating system or the modules have mailing lists of their own. =head2 That's it. =head1 AUTHOR Jarkko Hietaniemi on behalf of the Perl 5 developer team =cut __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PERL Internals access
Burton, Craig wrote: > If anyone there can give me some pointers to how to access the syntax > tree for an executing Perl program, _from within that program_, I would > be very grateful. I suspect this may not be possible. The O::Backend > system seems to require the Perl program execute with overloaded Ops > (example : Terse) and so the "normal" execution of the code is forfeited. > > I have fiddled with Devel::OpProf to get at what internal opcodes have > executed, but really want to have my perl program somehow obtain the > same large text dump created by a -MO=Terse printing, as part of my > program's execution. I don't want to call Terse over the source .pl > file either... sorry! Is something like B::Generate is what you are looking for? e.g. see: http://www.perl.com/pub/a/2002/05/07/optree.html Simon had an interesting paper in the last OSC's proceeding paper. I don't know if it's available online. It was called: B::Generate + Source Filters = use Python; In any case you probably want to move this discussion to some other perl specific list/forum, unless it has something to do with mod_perl. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: separating C from V in MVC
I think it'll be great to present the current discussion as a tutorial, so others can make a better use of the ideas thrown here, rather digging in archives. This could be a great addition to our growing tutorials section for the new site we are working on: http://perl.apache.org/release/docs/tutorials/index.html Any takers? While we are at it, if you are interested in writing tutorials on all kinds of topics related to mod_perl but don't fit into modperl docs (dbi, sql, caching, high availability, cool tricks, world domination, etc.) let us know at the docs-dev mailing list (or contact me) and we will help you with the details. Thanks! __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Confusion: Perl/mod_perl ????
Doug Silver wrote: > On Thu, 30 May 2002, Jeff McLean wrote: >> >>I have been programming in Perl for about 3 weeks now, and I just >>started doing some Perl CGI. I have Apache 2 installed on my linux >>system, but and my perl scripts work fine, but I don't knwo whether or >>not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up >>untill recently that Apache has it's own version of Perl that it uses >>for CGI scripts (mod_perl) but I am now having doubts. Could someone >>please tell me exactly what the difference is between Perl and >>mod_perl, and how exactly mod_perl is used (.i.e. is it just for >>writing apache modules or is it just for CGI, or what) I'm >>big-time confuesd here. > > First go to the http://perl.apache.org/ site to get the full story. In > short, think of mod_perl as a module that you start up with Apache that > allows all of the perl scripts to run faster because the server doesn't > have to launch a subprocess because mod_perl is in a sense Apache's > version of perl. There are a lot of options/etc (this *is* perl we're > talking about), so keep that in mind as you read through the documentation > for what is applicable to your website. Actually the new site (which should be released realy soon now) has a nice and easy intro to mod_perl (thanks to Bill Moseley and others who helped): http://perl.apache.org/release/start/index.html So Jeff, you may want to start from this URL first. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Chip Turner wrote: > Subject pretty much says it all. What are the requisite 5.8 compile > options, besudes ithreads, for proper functioning with either mod_perl > branch? Or ones that should be avoided? it may be different on your OS (read the INSTALL doc), but on linux 2.4 I compile with all the defaults (-des): ./Configure -des -Dprefix=/home/stas/perl/ithread \ -Dusethreads -Duseshrplib and I add: -Doptimize='-g' so I can debug problems (don't put it in for production use) -Duseshrplib builds a shared libperl Also you don't need -Dusethreads (which is a bit slower) if you don't plan on using perl threads and threaded Apache mpms (i.e. when you use prefork) ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Invoke PHP scripts?
Ryan Thompson wrote: > Thomas Klausner wrote to [EMAIL PROTECTED]: > > >>Hi! >> >>On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote: >> >> >>>I'm developing a large-ish web site in which I would like to use a >>>combination of mod_perl (90%) and PHP (10%). I have run into a >>>roadblock trying to include the output of a PHP script from a >>>mod_perl script. How about using notes()? http://perl.apache.org/release/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reloading Modules
Ted Prah wrote:
> Thanks for the input Stats. I found your debugging methodology
> to be very informative and especially useful in a mod_perl environment.
>
> I tried your suggestion of commenting out
> require $key;
> in Reload.pm, but it did not work for me. I'd be happy to try
> any other suggestions you might have.
But did you debug whether the module was reloaded from test.pl with the
modified Reload.pm? If so was the import() called? If not, try to have
it as a separate call:
require My::Test;
My::Test->import(':subs');
> Your code to work around Exporter worked fine. However,
> I think I'll stick with using Exporter so that I can make use
> of the export tags.
But it doesn't seem to work? You can easily extend the import() function
I've suggested to suppport tags.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Fwd: ApacheCon session submissions: deadline is this Friday!
Original Message Subject: ApacheCon session submissions: deadline is this Friday! Date: Tue, 28 May 2002 13:15:57 -0400 From: Rodent of Unusual Size <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: The Apache Software Foundation To: ASF members <[EMAIL PROTECTED]> Please make sure that all the appropriate project lists get a copy.. -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Greetings! Just a reminder: this Friday is the deadline for presentation proposals for the ApacheCon 2002 US conference in Las Vegas in November 2002.. To submit a proposal, visit http://ApacheCon.Com/html/cfp.html>. If you're not sure about a topic, or how well it might be received, you can ask other ApacheCon attendees by posting a message on the conference discussion list (see the Web page with the list details at http://ApacheCon.Com/html/lists.html>). Similarly, if you plan (or want) to attend the conference and want to request a particular topic, join the discussion list and say so. Not only will the planners then know, but you might trigger someone into proposing your ideal session! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBPPO5sprNPMCpn3XdAQEsDAP/QCP8kv5WtiKCj+5Maof2qkwrJ8/LBkVi 4gJvuEgZQda2m2HzUfcAr7+mtSEEV3p8aispEes/bDCVLKWyPbnbc5PCTeLhN99c SXbjtTNzZf7lQeb36M/QLlrHgnP8ovUqln3w2P3AGETnl1gbiPnpA52cXW/L3vRH tZr55PXOY3I= =kib0 -END PGP SIGNATURE- --- End Message ---
Re: Reloading Modules
Ted Prah wrote:
> Hi again,
>
> I'm having trouble seeing module changes when I reload
> a script that uses it.
That's because Reload.pm doesn't re-exports the symbols when reloading
the module and test.pl doesn't call import() because it sees the module
in %INC, therefore it still sees the old sub till the moment it gets
recompiled. Below you will find a complete analysis.
> I'm using Apache::Reload and my test
> script/module is as follows:
>
>
> test.pl
>
> #!/usr/local/bin/perl
> use strict;
> use warnings;
>
> use My::Test qw(:subs);
>
> print "Content-type: text/plain\r\n\r\n";
> &test1();
>
>
>
> Test.pm
>
> package My::Test;
> use strict;
> use warnings;
>
> BEGIN {
> use Exporter ();
>
> our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
>
> @ISA = qw(Exporter);
> @EXPORT= qw();
> @EXPORT_OK = qw();
>
> %EXPORT_TAGS = (
> subs => [qw(test1)],
>);
>
> Exporter::export_ok_tags('subs');
>
> }
>
> sub test1 { print "In test1 func\n"; }
>
> 1;
>
adjust the test.pl to do:
test1(); print \&test1, "\n";
#test2(); print \&test2, "\n";
and My::Test.pm to:
...
warn "test1:", \&test1, "\n";
#warn "test2:", \&test2, "\n";
sub test1 { print "In test1 func\n"; }
#sub test2 { print "In test2 func\n"; }
...
The first time you run the script you will see:
output:
In test1 func
CODE(0x85ad38c)
error_log:
test1:CODE(0x85ad38c)
you can see that both test1 and My::Test::test1 point to the same sub.
> When I modify sub test1, and I reload - no changes appear
> in the browser. The following gets printed to error_log:
> Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line 22.
output:
In test1 func
CODE(0x85ad38c)
error_log:
test1:CODE(0x84ee110)
as you see the test1 is not the same as My::Test::test1
> When I touch test.pl - the changes appear. The following gets printed
> to error_log:
> Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line 5
output:
In test11 func
CODE(0x84ee110)
now it points to the recent My::Test::test1
In that way you can debug any "mysteries" in Perl code.
Now, how to solve this problem. For example comment out
require $key;
in Reload.pm
that way, test.pl will see that My::Test is not in %INC, and require it
+ call its import() method.
Tell if this worked and we may adjust Reload.pm to have a special mode
where it makes Perl forget about modified modules and let the code that
loaded them in first place do the loading (and therefore the importing).
> Finally, if I add a new subroutine test2 to Test.pm, export it, and
> update the test.pl script to call test2, the script fails with an
> Internal
> Server Error. The following gets printed to error_log:
> "test2" is not exported by the My::Test module at
> /export/home/httpd/cgi-bin/My/test.pl line 5
> [Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
>
> /export/home/httpd/cgi-bin/My/test.pl line 5
> BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
> My/test.pl line 5.
>
> Then, when I restart the server, the script runs fine.
Hmm, this one is different. Seems like a bug in Exporter.
if you remove Reload.pm from the setup, so it won't confuse you and
adjust the code to do:
do "My/Test.pm";
My::Test->import(':subs');
you will see that it fails as well. This code acts like Reload.pm, but
always reloads the module. So it's not Reload.pm's fault.
Is anybody else familiar with this Exporter's (mis)behavior?
The solution that I see is to use something like this:
package My::Test;
use strict;
use warnings;
sub import {
my $package = shift;
no strict 'refs';
for (@_) {
*{ (caller)[0] . "::$_" } = \&{$_};
}
}
sub test1 { print "In test1 func\n"; }
sub test2 { print "In test2 func\n"; }
1;
If somebody else can see the problem with Exporter may be we need to run
it through p5p.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Carp interaction with mod_perl
Christian Gilmore wrote: > How does the Carp module interact with mod_perl? Is there a built-in catch > for croak or does it actually kill the child process, for instance? seems not to have any effect, i.e. it doesn't kill the process __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: "back-tracking"
Lucas M. Saud wrote: > hi, > > i'm writting a module to highlighting of Perl syntactical structures, but the >current code is very slow... :( > > i need some help to implementing a method of "back-tracking" or one way to revising >a token that has already been formatted without reformatting the entire string? it's >possible? > > if anyone interess, contact-me and i will send the source code... I fail to see what this has to do with the mod_perl list :( This kind of questions is *not* welcome here. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Configuring mod_perl on Debian
Ian D. Stewart wrote:
> On 2002.05.27 12:57 Andrew McNaughton wrote:
>
>>
>> Sounds to me like you're not setting your content-type correctly for
>> some
>> reason. Have a look at the headers being sent out. It's either not
>> sending this header, or it's sending something the browser doesn't
>> know
>> what to do with.
>
>
> This is the content of test.pl
>
> BEGIN-SCRIPT
> --
> #!/usr/bin/perl
>
> # your httpd.conf should have something like this:
>
> # Alias /perl/ /real/path/to/perl-scripts/
>
> #
> # SetHandler perl-script
> # PerlHandler Apache::Registry
> # PerlSendHeader On
> # Options +ExecCGI
> #
>
> print "Content-type: text/html\n\n";
>
> print "Date: ", scalar localtime, "\n";
>
> print "%ENV: \n", map { "$_ = $ENV{$_} \n" } keys %ENV;
> --
> END-SCRIPT
>
> Based on this, I would expect the content to be set to text/html and the
> page to be displayed to be a listing of the current environment.
>
> Galeon identifies the content type as application/x-perl. This would
> seem to indicate to me that Apache is serving the script directly
> instead of executing the script and serving the output. According to
> the mod_perl Guide, the ExecCGI option (which I have set for Location
> /perl) is supposed to avoid this situation.
issue a request from the command line and look at the saved response.
Use lwp's GET, or 'lynx -dump' or any other favorite downloading utility.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: compile time errors
m31 wrote: > Jie Gao wrote: > >> On Tue, 21 May 2002, m31 wrote: >> >>> I'm sorry (i wass in a rush), the errors come up when I run make test, >>> the `perl Makefile.pl` works fine. (on OSX 10.1.4 (Darwin 5.4), >>> Perl/5.6.0, mod_perl/1.25, apache/1.3.23) >>> >>> $ make test >>> ...some more stuff >>> >>> /usr/bin/perl t/TEST 0 >>> Can't locate object method "new" via package "URI::URL" at >>> ../blib/lib/Apache/test.pm line 252. >>> make: *** [run_tests] Error 255 >>> >> >> http://groups.yahoo.com/group/modperl/message/42895 >> >> >> >> >> Jie >> >> > Thankx, I added use URI::URL and I get past that but now it tells me: > > /httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & > zsh: no such file or directory: /httpd do you pay attention to the printouts? See above. > httpd listening on port 8529 > will write error_log to: t/logs/error_log > letting apache warm up...\c > done > /usr/bin/perl t/TEST 0 > still waiting for server to warm up...not ok > server failed to start! (please examine t/logs/error_log) at t/TEST line > 95. > make: *** [run_tests] Error 22 > > I check t/log/.. and there's nothing in there, I have a full working > vers of apache running, so I'm asuming its trying to make a fake request > for testing. Any ideas? > -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: GTop
Gregory Matthews wrote: > When trying to install GTop, I received the following > > Note (probably harmless): No library found for -lgtop > Note (probably harmless): No library found for -lgtop_sysdeps > Note (probably harmless): No library found for -lgtop_common > Note (probably harmless): No library found for -lglib > Can't exec "glib-config": No such file or directory at (eval 18) line 12. > Note (probably harmless): No library found for -lgtop > Note (probably harmless): No library found for -lgtop_sysdeps > Note (probably harmless): No library found for -lgtop_common > Note (probably harmless): No library found for -lglib You have to install first the development libraries (including glib-config). Either fetch them from http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop if you on linux, or try the source: ftp://ftp.gnome.org/pub/GNOME/stable/sources/gtop/ ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GTopLimit
Perrin Harkins wrote: > Stas Bekman wrote: > >> Perrin Harkins wrote: >> >>> Stas Bekman wrote: >>> >>>> What you are saying is that when the server is started afresh, the >>>> newly started child processes share more memory with the parent, >>>> than newly started child processes some time later. Am I correct? >> Any ideas why? > > > Not really. I thought maybe it was because of something changing in the > parent process, but that doesn't seem possible. > > There was a long thread a little while back about turning swap off and > on again to solve this. I've never tried that. I think restarting > every 24 hours is a good idea anyway, because I've seen strange things > happen now and then when a server is up for a long time. But that's unrelated to whether you kill the processes or not. Has anyone seen a similar behavior as described at the top of this post, when you have no swapping at all? > I think restarting > every 24 hours is a good idea anyway, because I've seen strange things > happen now and then when a server is up for a long time. It probably depends on what you do. I've restarted my production servers once in a few months, when something was going wrong. But as I said it depends on what do you do with mod_perl. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GTopLimit
Gregory Matthews wrote: > Stas: > > Since you wrote the script, do you recommend some good default settings > in GTopLimit to start with, i.e., Not really. It all depends on how many modules do you use and how big they are when compiled. I repeat many times in the guide, that all the examples are only examples. pretty much each setup is unique and there is no one-fit all setting. > use Apache::GTopLimit; > > Apache::GTopLimit->set_max_size(1); > Apache::GTopLimit->set_min_shared_size(4000); > Apache::GTopLimit->set_max_unshared_size(6000); Use Apache::VMonitor and it'll give you a good idea what are the settings that you want. Since it shows you the shared and max sizes. > $Apache::GTopLimit::CHECK_EVERY_N_REQUESTS = 2; This one is easy. If your processes are losing the shared memory slowly, raise this number, so less checks will be made. Otherwise keep it small. Again work with Apache::VMonitor and you will figure out the perfect setup. > I would like to start with recommended defaults and tweak if necessary > from there. See above. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GTopLimit
Perrin Harkins wrote: > Stas Bekman wrote: > >> What you are saying is that when the server is started afresh, the >> newly started child processes share more memory with the parent, than >> newly started child processes some time later. Am I correct? > > Yes, exactly. Any ideas why? I always do a full restart, so I've never noticed the problem. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GTopLimit
Perrin Harkins wrote: > Stas Bekman wrote: > >> Hmm, when a new process starts it shares *everything* with the parent. >> Why do you say that it's not? > > > It doesn't share everything with the parent. As soon as it forks there > is unshared memory, and after the first request it handles there is > usually more. > > Over time, the average amount of shared memory among child processes > seems to gradually decrease. Restarting fixes this. What you are saying is that when the server is started afresh, the newly started child processes share more memory with the parent, than newly started child processes some time later. Am I correct? ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GTopLimit
Perrin Harkins wrote: >>Does using the Apache::GTopLimit module have the same net effect as >>restarting the server itself by simply killing off the actual > > processes > >>which are growing beyond the set threshold, and thereby causing new >>processes to be born? > > > It does kill off processes that are getting too big, and you definitely > should use either GtopLimit or SizeLimit to get the most out of your > server. However, it's not quite the same thing as a restart. Over > time, some of the shared memory from the parent process appears to > become unshared, and new processes that are spawned start out with less > shared memory because of this. Hmm, when a new process starts it shares *everything* with the parent. Why do you say that it's not? It doesn't matter if the process gets killed because of MaxRequestPerChild or FooLimit thresholds. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Monitoring the processes
Gregory Matthews wrote: > Thanks to everyone for the great input on Memory Leaks. Now that I have > a good starting point for tracking down the problem, when I TEST for > leaks, or simply check for a continued increase in server memory usage, > how do I go about monitoring the processes growth? > > For example, is there a command line tool to use that will allow me to > see the process growth upon request reload? I know that I should run > the server with httpd -X, but I don't know how to actually see the > memory being used/increased/decreased when the prog is being executed. > As I understand it, this is a good indication that there might be a > problem. Apache::VMonitor is great! (well, I wrote it :) Gregory, before you continue asking more questions... it's all the guide: http://perl.apache.org/release/docs/1.0/guide/performance.html#Measuring_the_Memory_of_the_Process so before you ask, check the guide. Use the search if you don't know where to look. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory Leaks
Gregory Matthews wrote: > Does using the Apache::GTopLimit module have the same net effect as > restarting the server itself by simply killing off the actual processes > which are growing beyond the set threshold, and thereby causing new > processes to be born? It's not the exactly the same, since it won't pick up any changes in Perl modules on the disk. And that's one of the main reasons for doing restarts. Otherwise yes. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory Leaks
Per Einar Ellefsen wrote: > At 23:54 20.05.2002, Allen Day wrote: > >> I've noticed that if I restart apache while I'm in the middle of a >> download (MP3 stream), after the buffer in my MP3 player runs out, it >> skips to the next track -- presumably because the connection was closed. >> >> This might cause a problem for you if your users are downloading big >> files. They might have to restart from the beginning if they didn't >> cache >> the partial download somewhere. > > > Hmm, if you are serving big files off of mod_perl, memory leaks are the > least of your problems :) Well, you can serve big files without reading them into a memory at once. Why there would be memory leaks? > That doesn't apply to Apache::MP3 of course, > for which it's normal, but in no case should your mod_perl server be > serving your big files. The reason for not serving big files with mod_perl, is that you don't want to tie heavy and snappy mod_perl servers to wait indefinitely for the client to grab their data. If you have plenty of memory or you have just a few clients (intranet?) that's just fine. This is all discussed here: http://perl.apache.org/release/docs/1.0/guide/strategy.html#Adding_a_Proxy_Server_in_http_Accelerator_Mode __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: undef Upload object
Geoffrey Young wrote: > > > Mike Melillo wrote: > >> I am trying to have a user upload an image and I am getting an undef >> $apr->upload object. > we have a working example that may be able to help you some: > > http://www.modperlcookbook.org/code/ch03/Cookbook/PrintUploads.pm also see the new addition contributed by Rich Bowen: http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_with_Apache__Request ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reloading Library Files
Ted Prah wrote: > That explains the library files not reloading - Thanks! Great! >>I suppose if you want to use the cheap workaround, you have to >>s/require/do/. Remember that the guide suggests the lib.pl trick as a >>workaround, not a solution you go with during the normal development. > > > I didn't realize that using the library wrapper was a cheap workaround > to the nested subroutine problem. The effects of the nested subroutine > problem is my biggest concern with writing code for mod_perl. What > I liked about the lib.pl trick is that it completely eliminates this problem. > I won't lose sleep wondering if somehow the code went into production > with a nested subroutine. I realize that there are other ways to eliminate > the nested subroutine problem, but what are the preferred techniques > used by mod_perl developers? Check the error_log file for problems > and fix as needed? The majority are discussed here: http://perl.apache.org/release/docs/general/perl_reference.html#Remedies_for_Inner_Subroutines Declaring the package in your libs is a good idea. Because if you don't, most likely you are going to encounter this problem: http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs The solutions are discussed there as well. > Check the error_log file for problems and fix as needed? Ted, this is not an option, this is a must thing to do. If you don't monitor constantly the error_log file while developing you are looking for a trouble. http://perl.apache.org/release/docs/1.0/guide/debug.html#Warning_and_Errors_Explained __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: New mod_perl website [Was Re: Modifying @INC via startup.pl]
Drew Taylor wrote: > This is a little OT, but I really love the new look of the website you > mention below. Major kudos to all those who helped put together the new > look-n-feel & content. Thanks Drew, but please hold off on any comments, since we are still tuning the design to work better in various browsers. Once we are satisfied with it, we will make an announcement and then ask you to check if you have any problems with your favorite browsers. Meanwhile if you are willing to help or want to comment on things, please join the [EMAIL PROTECTED] list. We do need your help. BTW, the final site will be at http://perl.apache.org/. The http://perl.apache.org/release/ URL is only temporary. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reloading Library Files
Ted Prah wrote: >>do you test only this script alone? What happens if you add the package >>declaration and then call it using the full name? e.g.: >> > > > Yes, this is the only script (and corresponding library file) that I use > for this test. When I use the package declaration and make the call > using the full name, the reloads work fine. > > The reason I am using the library file is to follow your recommendation > in the mod_perl guide where a script is split into two files to avoid > the nested subroutine problem. Out of curiosity I tested the sample > code (counter.pl and mylib.pl) and they too did not reload properly > when mylib.pl was modified. Does the reloading of a modification > of mylib.pl work for you? I would prefer to use the library file > approach as opposed to the package approach as a lot of our code > uses libraries that are not in packages, but will move to packages if > that is a necessity. Well, that explains everything. When you require() a library without that doesn't declare a package for the first time from the registry script, all its global symbols (subs, vars, etc) get imported into the namespace of the caller, i.e. the registry script (APACHE::ROOT::...). When Apache::Reload require()s that library that doesn't declare a package, all the global symbols end up in the Apache::Reload namespace! So the library does get reloaded and you see the compile time errors if there are any, but the symbols don't get imported to the right namespace. So the old code is running. Moreover this leads to a pollution of the Apache::Reload namespace, which may cause to problems if you happen to overwrite some of its symbols (subs, vars, etc). I suppose if you want to use the cheap workaround, you have to s/require/do/. Remember that the guide suggests the lib.pl trick as a workaround, not a solution you go with during the normal development. Was this explanation clear enough? We need to add it to the Apache::Reload manpage to avoid this kind of questions in the future. Funny though, that it's the first time this problem has been reported. Which shows that most of the people don't use workarounds when they do real developments :) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: sending CGI ouput through a handler
Allen Day wrote: >>>My::Handler takes the requested file and adds some markup to it with >> >>the >> >>>Template Toolkit if the MIMEtype of the file is text/html. I want to >> >>be >> >>>able to use the same handler to also add markup to the output of >> >>executed >> >>>CGI. What is the best way to do this? >> >>You can't feed the output of mod_cgi to mod_perl, at least not in Apache >>1.x. The best thing to do (at least for performance) would be to >>rewrite the CGI so that you call it as a module from your handler. >>Another approach would be to use Apache::Filter to grab the output from >>PerlRun or Regsistry. You could also sublass PerlRun or Registry and >>add your handler code to it. > > > So what about in Apache 2.x ? Is there a way to address this? Yes, you will be able to, thanks to I/O filters. See the mod_perl 2.0 test suite under t/filter/. > I'm trying > to convert a site that has lots of independent CGI to one that contains > the output of said CGI in a set of templates. I'd rather not have to > make modifications to the existing CGI to bring them in. Run them under Apache::Registry or PerlRun. Then use Apache::Filter as Perrin has suggested. My suggestions of using stacked handlers may work too with a custom subclass of Apache::RegistryNG. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: sending CGI ouput through a handler
Allen Day wrote: > Okay, I realize this has probably been covered before, but I couldn't find > anything in the archive... > > I have a configuration like this: > > > SetHandler perl-script > PerlHandler My::Handler > > > My::Handler takes the requested file and adds some markup to it with the > Template Toolkit if the MIMEtype of the file is text/html. I want to be > able to use the same handler to also add markup to the output of executed > CGI. What is the best way to do this? > > Should I set up a separate location for the CGI (I'm doing this, > actually) ? Are there any extra directives needed? by CGI do you mean a script running under mod_cgi? If it's registry you should be able to use stacked handlers: http://perl.apache.org/release/docs/1.0/guide/config.html#Stacked_Handlers ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Leak
after Tue Feb 13 20:12:04 2001
@@ -5,7 +5,7 @@
'TYPE' => 'PV',
'LEN' => 5,
'ADDRESS' => '0x80572ec',
-'PV' => 'FooB',
+'PV' => 'FooC',
'CUR' => 4
}
}
We can see the leak again, since the value of C has changed again:
from I and I. And if we look at the second case:
file:leaktest4.pl
-
package LeakTest1;
use B::LexInfo ();
sub test { my ($string) = @_;}
my $lexi = B::LexInfo->new;
my $diff = $lexi->cvrundiff('LeakTest1::test', "a string");
$diff = $lexi->cvrundiff('LeakTest1::test', "a string");
print $$diff;
no output is produced, since there is no difference between the second
and the third run. All the data structures are allocated during the
first execution, so we are sure that no memory is leaking here.
C includes a C option which can show
you the internals of your code via C. See Chapter
[XREF=debug.pod].
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make test problem
Jie Gao wrote: > Just got one from cvs and 'make test' hangs on apr/util: please run in the verbose mode: t/TEST -v apr/util if it doesn't help to reveal the problem try to enable tracing: http://perl.apache.org/release/docs/2.0/user/config/config.html#General_directives or attach with gdb and send us the trace of where it hangs. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reloading Library Files
Ted Prah wrote:
> Thanks Drew, I tried that, but it did not work.
What happends if you add:
PerlWarn On
in httpd.conf
or
start the script with perl -w?
any warnings?
do you test only this script alone? What happens if you add the package
declaration and then call it using the full name? e.g.:
z.pl - test script which calls entry_point in z_lib.pl
---
#!/usr/local/bin/perl -w
use strict;
require '/home/cgi-bin/z_lib.pl';
My::Z::entry_point();
---
z_lib.pl
--
package My::Z;
use strict;
sub entry_point {
my $r = Apache->request;
$r->content_type('text/html');
$r->send_http_header;
print "HERE 1";
#print " HERE 2";
}
> Ted
>
> Drew Taylor wrote:
>
>
>>Have you tried moving the PerlInitHandler & PerlSetVar up and out of the
>> directive, making it global for the server? I'm not sure that
>>would fix it, but it's worth a try.
>>
>>Drew
>>
>>At 02:37 PM 5/17/02 -0400, Ted Prah wrote:
>>
>>>I have tried Apache::Reload as well, but I get the same results.
>>>
>>>Ted
>>>
>>>Drew Taylor wrote:
>>>
>>>
>>>>Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible,
>>>>but StatINC has been around a little longer. Both have worked well for me.
>>>>But be sure that you don't use these modules on a production server. :-)
>>>>
>>>>httpd.conf
>>>>==
>>>>PerlInitHandler Apache::Reload
>>>>
>>>>Drew
>>>>
>>>>At 01:38 PM 5/17/02 -0400, Ted Prah wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>I am new to mod_perl and am having problems seeing the
>>>>>changes made to library files. Must I restart the server every
>>>>>time I change a library file in order to see my changes? My
>>>>>test code and environment is below.
>>>>
>>==
>>Drew Taylor | Freelance web development using
>>http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI
>>mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com
>>--
>>Speakeasy.net: A DSL provider with a clue. Sign up today.
>>http://www.speakeasy.net/refer/29655
>>==
>
>
> --
> Ted Prah
> NetCasters, Inc.
> Phone: 978.887.2100 x44
> Fax: 978.887.6750
> [EMAIL PROTECTED]
>
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Scripts and passwd
[EMAIL PROTECTED] wrote: > Hello > > Thanks for the reply. Yes this server is running mod perl :) > > As for risky. Well the whole point of the script system is to add a pop mail > box for a user. But in order to do this i have to do the following: > > add user to the passwd/shadow file > add user to the virtusertable and genericstable > recompile the sendmail config files > > Then and only then is the new mailbox ready for use. This is the only way I > can think of to accomplish this via an automated web proccess. I dont even > know if you can do it any other way with out touching the passwd/shadow > files? You probably want this article: Safely Empowering Your CGI Scripts by Lincoln D. Stein http://www.samag.com/documents/s=1286/sam03020006/ ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Reloading Library Files
Ted Prah wrote: > Hi, > > I am new to mod_perl and am having problems seeing the > changes made to library files. Must I restart the server every > time I change a library file in order to see my changes? My > test code and environment is below. Hmm, I haven't used StatINC for a long time, any luck with Apache::Reload? http://perl.apache.org/guide/porting.html#Using_Apache_Reload ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DB
Gregory Matthews wrote: > Stas: > > Out of curiosity, what do YOU use to debug perl running under mod_perl? Apache::DB ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DB
[please don't forget that to CC the list!]
Gregory Matthews wrote:
> Stas:
>
> Thanks for your reply on my issue in the Mod_Perl list.
>
> Excuse my ignorance, but how do I do the following:
>
> before you try to build Apache::DB try to build test.c with the contents:
> #include
> int main(void){return 0;}
> and then compile it:
> % cc test.c
>
> If you could point me in the right direction, I can figure it out! I am
> running FreeBSD.
>
> Thanks.
>
> Gregory
>
create a file named test.c, put inside:
include
int main(void){return 0;}
now you need to compile it with:
cc test.c
if this doesn't work (i.e. you get compilation errors, you have to ask
for assistance on the FreeBSD mailing list(s) or elsewhere, since your
problem has nothing to do with mod_perl.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [OT] Refs don't work, like I want
Stas Bekman wrote: > I know I don't sound nice, but we try hard to keep a low Sound to Noise > Ratio here. of course I meant a *high* Sound to Noise Ratio. the heat and humidity shows :) p.s. sorry for adding to the noise. back to work on adding more sound. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [OT] Refs don't work, like I want
Viljo Marrandi wrote: > Sorry about non mod_perl question, but as I'm subscribed to this list and > I know I can get help from here, I ask my question here. Please do NOT do that in the future. This is the *modperl* list. There are hundreds of perl lists which will gladly help you out. perlmonks.org is one of these places. Folks, please refrain to reply to this kind of questions, but instead send those who ask to the other resources, *without* answering the question, no matter how simple it is. Don't encourage people to be lazier than they are already. I know I don't sound nice, but we try hard to keep a low Sound to Noise Ratio here. Please help to keep this list useful to those who seek mod_perl help and clean of noise for those who can help. p.s. I usually don't bash this kind of posts, but this one was saying: as I'm subscribed to this list and I know I can get help from here, I ask my question here. it's not very nice of you, Viljo. Please subscribe to other relevant lists and ask the questions there if they don't belong here. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: modperl idle timeout....
Jim Morrison [Mailinglists] wrote: > Anyhow... I was wondering... is there a simple way to set up a sort > of "idle timeout" to get each single httpd to restart itself if two > conditions are met: - 1 - It has compiled mod_perl - 2 - The mod_perl > aliases have not been accessed for 'x' minutes... > > What do you guys recon... is crontabbing a restart easier.. is it ill > advised? (Ofcourse the restart runs even when you are using > mod_perl.. which doesn't really help anyone.. cos then it has to go > through the restart lag.. ) > > > Oh well... would love to hear your thoughts, You can do this only with an external process, since child processes cannot communicate with each other. Though you have the scoreboard which is probably what you want. Look at Apache::Watchdog::RunAway, you can adjust it easily to do what you want. Though you pay the price of enabling the scoreboard extended updates on the live system, which adds a slight overhead to each request's response times. But using the crontab seems much simpler to me. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: compatibility problem
Jie Gao wrote: > Hi all, > > I've been trying to get httpd-2.0.35 + mod_perl-1.99_01 work with backward > compatibility. > > MY startupl.pl: > > #! /usr/bin/perl > use lib '/usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache2'; > use strict; > use Apache::compat (); > use Apache2 (); > use My::AuthCookieHandler; > 1; > > and this script won't run to finish with the error: > > unknown group `response' at /usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm >line 6. > BEGIN failed--compilation aborted at >/usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm line 6. > Compilation failed in require at ./startup.pl line 6. > BEGIN failed--compilation aborted at ./startup.pl line 6. > > And this is the line in question: > > use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT); > > If I take out response, it croaks at "REDIRECT". > > Any ideas why? Yes, it's not fully compatible :( in 2.0 we take all the Constants from APR and Apache, and they have changed. I guess we can manually do the adjustments in compat.pm. Currently there is no group :response in Apache::Const, these mainly reside in the new group :http and all the codes start with HTTP_ For now try to replace REDIRECT with HTTP_TEMPORARY_REDIRECT and whatever constants you need from :response by looking them up in xs/ModPerl/Const/modperl_constants.c (which is autogenerated when you build mod_perl). We will discuss this issue at the dev list and the compat docs will be updated appropriately. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DB
Gregory Matthews wrote:
> Hello All.
>
> I am trying to install Apache::DB and am getting the following error:
>
> +
>
> > make test
> cc -c-DVERSION=\"0.06\" -DXS_VERSION=\"0.06\" -DPIC -fpic
> -I/usr/libdata/perl/5.00503/mach/CORE DB.c
> In file included from /usr/include/sys/time.h:289,
> from /usr/include/sys/stat.h:50,
> from /usr/include/sys/mount.h:44,
> from /usr/libdata/perl/5.00503/mach/CORE/perl.h:376,
> from DB.xs:2:
> /usr/include/time.h:2: syntax error before `1989'
> /usr/include/time.h:26: empty character constant
> /usr/include/time.h:32: syntax error before `PROFITS'
> /usr/include/time.h:115: syntax error before `}'
> *** Error code 1
You have a corrupted /usr/include/time.h, reinstall the package that it
comes with or simply borrow this file from some other machine.
before you try to build Apache::DB try to build test.c with the contents:
#include
int main(void){return 0;}
and then compile it:
% cc test.c
once it works move onto Apache::DB
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: we need mod_perl banners
Mark Fowler wrote: > On Tue, 14 May 2002, Stas Bekman wrote: > > >>[ creating banners, etc ] > > > Do we have the source for those banners anywhere? Preferably vector, or > at least telling us what font the original was in. I don't think anyone > wants to work from bitmap. > > I seem to remember matts doing something with SVG a while back, but him > waiting on the correct font (my memory is a bit vague on this) Only the new mod_perl logo: http://wypug.digital-word.com/mod_perl/svg_version/ (the svg version will feature on the new site as well) ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
we need mod_perl banners
Nobody has volunteered to lead the modperl banners effort, so if you are an artist or know someone who is and willing to help please send the banners to me. The story: -- Some people want to advertise mod_perl on their sites. We need banners for that. Your help is appreciated. Approx Banner Spec: --- Format: PNG Dimensions: 468x60 and 150x40 (pixels) Size: about 10k. BTW, we still don't have a button derived from the winner logo! should be 88x31px or something like that. Ideas for banners: -- * world domination chapter 1 (only 20% achieved, see netcraft) * world domination chapter 2 (50% target) * include the 2.0 theme Try to re-use the new logo: --- http://wypug.digital-word.com/mod_perl/winner/ You can use Apache's feather: - http://apache.org/~stas/feather.gif http://apache.org/~stas/feather_transbg.gif And ORA's camel: http://perl.oreilly.com/usage/ and probably can cut images from http://wypug.digital-word.com/mod_perl/ Thanks. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote:
>>ok, next trace to the offending code.
> [Tue May 14 10:38:19 2002] [error] Can't call method "size" on unblessed
> reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line
> 94.
> B::AV::size(1, 'B::AV=SCALAR(0xa063444)') called at
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 438
I cannot reproduce the problem, but it seems that the problem is in
B/Size.pm:93my @vals = $sv->ARRAY;
which returns values which aren't references (at least one). You may
want to muck around this code and print what's inside @vals.
> B::TerseSize::PADLIST_size('B::CV=SCALAR(0xa0674a0)',
> 'B::CV=SCALAR(0xa0674a0)', 'B::CV=SCALAR(0xa0674a0)',
> 'B::CV=SCALAR(0xa0674a0)') called at
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 190
> B::TerseSize::CV_walk('slow', 'B::NULL::size', 'op_size') called
> at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 123
> B::TerseSize::package_size('B::NULL') called at
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 542
> B::TerseSize::apache_package_size('B::HV', 'B::Terse',
> 'B::SPECIAL', 'B::NULL') called at
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 563
> B::TerseSize::status_memory_usage('Apache=SCALAR(0x9e4ae5c)',
> 'CGI=HASH(0x9e4aa8c)') called at
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Status.pm line 66
> Apache::Status::handler('Apache=SCALAR(0x9e4ae5c)') called at
> /usr/lib/perl5/5.6.0/Carp.pm line 119
> require 0 called at /usr/lib/perl5/5.6.0/Carp.pm line 119
> I will see if I can borrow a testing machine tomorrow to try the
> upgrade.
Please check if the problem does go away with 5.6.1. if not please
provide a short script/module that reproduces the problem (via
Apache::Status of course)
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote:
>>[EMAIL PROTECTED] wrote:
>>
>>>Hope someone can give me a hand on this, I am having some problem using
>>>the Memory Usage option in the main menu of Apache::Status.
>>>
>>>It always return me a 500 with the following error.
>>>
>>>[Tue May 14 08:48:21 2002] [error] Can't call method "size" on unblessed
>>>reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line
>>>94.
> yes, I have both installed.
ok, next trace to the offending code. Put in your startup.pl:
use Carp;
$SIG{__DIE__} = \&Carp::confess;
hopefully nobody redefines $SIG{__DIE__}
>>Also 5.6.0 is *very* buggy, so upgrading to 5.6.1 is a very good idea.
>
>
>
> Would love to, but it's a production machine, so .. I can't upgrade it
> unless something major breaks. (^_^!)
This is a *major* reason for updating :)
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote: > Hope someone can give me a hand on this, I am having some problem using > the Memory Usage option in the main menu of Apache::Status. > > It always return me a 500 with the following error. > > [Tue May 14 08:48:21 2002] [error] Can't call method "size" on unblessed > reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line > 94. Do you have B::Size installed? perl -MB::Size -e1 Can you use TerseSize from the command line? perl -MO=TerseSize -e '1' Also 5.6.0 is *very* buggy, so upgrading to 5.6.1 is a very good idea. > This is the config I added to httpd.conf to enable the feature. > > > SetHandler perl-script > PerlModule Apache::Status > PerlModule B::TerseSize > PerlHandler Apache::Status > > PerlSetVar StatusOptionsAll On > PerlSetVar StatusTerse On > PerlSetVar StatusTerseSize On > PerlSetVar StatusTerseSizeMainSummary On > __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Moving from CGI to mod_perl
[Please make sure to post follow-ups to the list! Thanks!] Anton Permyakov wrote: > Hi, all. > > I have perl CGI-script, and i wanna run it as mod_perl script. > > Is it enought to correctly edit only httpd.conf, or i've to add something > special in my CGI-script? Maybe something like > > use Apache::Registry; > > or something else > > Also is it needed to write some special script like startup.pl or not? > > Thank you all, and sorry for this "easy question"... > In doc i could not find "How to migrate from CGI to mod_perl" - step by step > easy example. http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/getwet.html#Porting_Existing_CGI_Scripts_to_run_under_mod_perl __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to see /server-status when at MaxClients?
John E. Leon Guerrero wrote: > if a job hangs (due to database locking for instance), then a mod_perl child > will hang as well (absent some additional watchdog-type program.) if enough > jobs hang to the point that we hit MaxClients, then it is too late to use > /server-status to see what jobs hung. > > does anyone have a quick way to indentify the jobs that are currently > running? i thought of getting a core and using gdb but i was hoping to find > a faster way. it would be nice if we could reserve a couple of children for > administrative emergencies such as this. You probably want: Apache::Watchdog::RunAway ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PerlVINC and Can't locate Foo.pm in @INC ...
Aaron J Mackey wrote: > Banging my head against the wall a bit, 'cause this is just so simple, but > still not working: > > Versions: Apache 1.3.22, mod_perl 1.26, perl 5.6.1 > > relevant lines from httpd.conf: > > PerlWarn On > PerlModule Apache::PerlVINC > > > SetHandler perl-script > PerlHandler DAT::Client::WWW > > PerlINC /home/ajm6q/cvs/dat-head/lib > PerlFixupHandlerApache::PerlVINC > PerlVersion DAT/Client/WWW.pm > > > Error log when access is attempted (other standard directories edited out > for brevity): > > [Fri May 10 13:39:39 2002] [error] Can't locate DAT/Client/WWW.pm in @INC > (@INC contains: /home/ajm6q/cvs/dat-head/lib [... edited out ...]) at > /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/PerlVINC.pm line 55. > > The file is, of course, actually there: > > % ls -l /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm > -rwxrwxr-x1 ajm6qwebwork 394 May 10 12:40 >/home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm > > > What am I missing? Does it normally work? (without Apache::PerlVINC) It's possible that you have wrong permissions on one of the segments of /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm so it cannot read the final path. First test simply with: die $! unless -r /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with mod_perl installation(HELP!!!)
[Please make sure to reply back to the list! Thanks] Jose Ortiz wrote: > People : > > I had spent more than 2 months trying to make mode_perl on my RH 72. First I >tried with > > the RPMS but it didn't works. Then I tryied with the tar.gz and I can't neither. very unlikely that it doesn't work, try following the steps as explained in the guide: perl.apache.org/guide/install.html make sure that you get the latest apache-1.3.24 and mod_perl_1.24 when reporting bugs/problems, please follow the instructions here: http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl2: nmake test crashes apache
Alessandro Forghieri wrote: >>about combinatorial I think not only compat2 is involved here >>in test suites I have ran > Wow. this is great detective work you have done Pascal. Actually you didn't have to do the detective work. Apache::Test comes with a detective of its own. Just run t/SMOKE and it'll find all the combinations that fail. Though I cannot help you on WinFU :( Hopefully Randy or Doug will hear you. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [BUG?] PerlSetVar in .htaccess segfaults w/ register_cleanup()
D.Kreft wrote: ... > I am greeted with Netcape's "Document contains no data" error dialog > box, and a segfault notice in the error log: > >[Thu May 9 09:19:52 2002] [notice] child pid 25420 exit \ >signal Segmentation fault (11) ... > Does anyone have any ideas about what's going wrong here? Any help > would be greatly appreciated! Probably not, without a back trace (from the Segfault) unless someone has had a similar problem and solved it before. See http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems on how to retrieve the backtrace. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[Fwd: ApacheCon US 2002: Call for Participation]
FYI Original Message Subject: ApacheCon US 2002: Call for Participation Date: Mon, 06 May 2002 13:52:22 -0400 From: Rodent of Unusual Size <[EMAIL PROTECTED]> Organization: The Apache Software Foundation To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Newsgroups: comp.infosystems.www.servers.unix,comp.infosystems.www.servers.ms-windows,comp.infosystems.www.servers.misc,de.comm.infosystems.www.servers -BEGIN PGP SIGNED MESSAGE- Call for Participation: ApacheCon US 2002 = November 18-21, 2002, Las Vegas, Nevada, US SUBMISSION DEADLINE: Friday, 31 May 2002, 17:30 EDT Come share your knowledge of Apache software at this educational and fun-filled gathering of Apache users, vendors, and friends. Apache Software Foundation members are designing the technical program for ApacheCon US 2002 that will include over 40 sessions planned. We are particularly interested in session proposals covering: o Apache Web server topics (installation, compilation, configuration, migration, Version 2.0) o All Apache Software Foundation projects (Jakarta, mod_perl, Xerces, et cetera) o scripting languages and dynamic content (Java, PHP, Perl, TCL, Python, XML, XSL, etc.) o Security and eCommerce o Performance tuning, load balancing, high availability o tips for writing Apache Web server modules o Technical and non-technical case studies o new Web-related technologies Only educational sessions related to projects of the Apache Software Foundation or the Web in general will be considered (commercial sales or marketing presentation won't be accepted; please contact [EMAIL PROTECTED] should you be interested in giving a vendor presentation). If you would like to be a speaker at the ApacheCon US 2002 event, please go to the ApacheCon Web site, log in, and choose the 'Submit a CFP' option from the list there: http://ApacheCon.Com/html/login.html NOTE: If you were a speaker or delegate at a past ApacheCon, please log in using the email address you used before; this will remember your information and pre-load the CFP form for you. If this is your first time being involved with ApacheCon, please create a new account. - -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBPNbCv5rNPMCpn3XdAQEOIwQAoU7FRkqL7yNhzjtUcPlEeNE/+ezgsfyN tNbt9eVqLTm/1s0kO7LK1zKG1MAckHLXF7JYHXFlD4J9TTspMDtTUUkp5HThF6Ay C3hm7ZnrfSO+DWKbOMZ3hHZytv8rRC8MhZe2wY5Ps5qtFRt5o4QdGAja5FRNrUwM ozPV4l2Tk2s= =uj+B -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RFC] New Subject Tag for mod_perl 2.x postings
Thomas Klausner wrote: > Hi! > > As there are more and more mod_perl 2.x related questions on the mailing > list, it would be a good idea to introduce a new subject tag (as in > http://perl.apache.org/email-etiquette.html#Tags > ): > > Something like: > [mod_perl 2.x] > [mp2] > [2x] > [2.x] > ?? > > What do you think? That's a good idea. Any tag that will make it clear that the question is regarding 2.x is fine. Eventually when 2.0 is released and after a while most people will run 2.x, only those ancient [:)] 1x will need to be tagged in the subject line. > It would definitly keep my mailbox tidier... > > Stas, If we decide on something I could patch the new documentation to > include this new tag, but I don't know abot the old (i.e. current) one go ahead, add any tags that you prefer. [2.x] or sounds the shortest and the clearest. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl install from tarball
Boex,Matthew W. wrote: > i am trying to install mod_perl and apache from tarball. after untarring, i > created the makepl_args.mod_perl file in my home dir with my options. by > the way, i am building this on a rh7.1 machine with mod_perl already > installed. i am building this to learn. you are trying to install mod_perl 2.0-tobe, which works only with Apache 2.0, and most likely you want to download mod_perl 1.26 instead. > my goal is to install from scratch so i can learn more and to install with > the same directory structure, /usr/local/apache-mod_perl/ on my production > and dev machines. i want to be able to run a mod_perl or non-mod_perl > enabled web server. The detailed steps of how to do that are here: http://perl.apache.org/guide/install.html ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
mod_perl cookbook review at apacheweek.com
For those who still hesitate whether to purchase this great mod_perl recipes tome, here is Min Min Tsan's review of the mod_perl cookbook: http://www.apacheweek.com/features/book-mod_perlcookbook And lucky Robin Berjon and two other folks just won free copies of this book from apacheweek giveaway :) p.s. April 2002 Netcraft's mod_perl stats: 3.6M hosts 0.4M IPs. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
localizing $dbh attributes with Apache::DBI to minimize the numberof connections made
Recently 5.8.0-tobe has fixed the leak with localization of tied hash
values, so I'm fixing the following guide's section as follows. This is
an important update, since the guide didn't say anything about $dbh attr
changes affecting other handlers in the same process. Please review that
everything is correct and I'll replace the old section with this one.
=head3 Opening Connections with Different Parameters
When C receives a connection request, before it decides
to use an existing cached connection it insists that the new
connection be opened in exactly the same way as the cached
connection. If you have one script that sets C and one
that does not, C will make two different connections. So
if for example you have limited Apache to 40 servers at most, instead
of having a maximum of 40 open connections you may end up with 80.
So these two connect() calls will create two different connections:
my $dbh = DBI->connect
("DBI:mysql:test:localhost", '', '',
{
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 1, # don't commit executes immediately
}
) or die "Cannot connect to database: $DBI::errstr";
my $dbh = DBI->connect
("DBI:mysql:test:localhost", '', '',
{
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 0, # don't commit executes immediately
}
) or die "Cannot connect to database: $DBI::errstr";
Notice that the only difference is in the value of C.
However, you are free to modify the handle immediately after you get
it from the cache. So always initiate connections using the same
parameters and set C (or whatever) afterwards. Let's
rewrite the second connect call to do the right thing (not to create
a new connection):
my $dbh = DBI->connect
("DBI:mysql:test:localhost", '', '',
{
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 1, # commit executes immediately
}
) or die "Cannot connect to database: $DBI::errstr";
$dbh->{AutoCommit} = 0; # don't commit if not asked to
When you aren't sure whether you're doing the right thing, turn debug
mode on.
However, when the C<$dbh> attribute is altered after connect() it
affects all other handlers retrieving this database handle. Therefore
it's the best to restore the modified attributes to their original
value at the end of database handle usage. As of C
version 0.88 the caller has to do it manually. The simplest way to
handle this is to localize the attributes when modifying them:
my $dbh = DBI->connect(...) ...
{
local $dbh->{LongReadLen} = 40;
}
Here the C attribute overrides the value set in the
connect() call or its default value only within the enclosing block.
The problem with this approach is that prior to Perl version 5.8.0
this causes memory leaks. So the only clean alternative for older Perl
versions is to manually restore the C's values:
my @attrs = qw(LongReadLen PrintError);
my %orig = ();
my $dbh = DBI->connect(...) ...
# store the values away
$orig{$_} = $dbh->{$_} for @attrs;
# do local modifications
$dbh->{LongReadLen} = 40;
$dbh->{PrintError} = 1;
# do something with the filehandle
# ...
# now restore the values
$dbh->{$_} = $orig{$_} for @attrs;
Another thing to remember is that with some database servers it's
possible to access more than one database using the same database
connection. MySQL is one of those servers. It allows you to use a
fully qualified table specification notation. So if there is a
database I with a table I and database I with its own
table I, you can always use:
SELECT from foo.test ...
or:
SELECT from bar.test ...
So no matter what database you have used in the database name string
in the connect() call (e.g.: C) you can still
access both tables by using a fully qualified syntax.
Alternatively you can switch databases with C and C,
but this approach seems less convenient, and therefore error-prone.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Scope of Perl Special Variables
Bill Catlan wrote:
> Stas Bekman wrote:
>
>
>>This explains why by default %ENV is set for each request afresh.
>>http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
>
>
> Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
> the existing inctances' ENV is not clobbered.
>
> My guess is that a localized copy of the %ENV variable is created by the above
> referenced process, thus no clobbering of existing instances' %ENV occurs.
> Would that be correct?
Can you send a reproducable example of a problem? For example this code
does the right thing:
$r->send_http_header('text/plain');
print exists $ENV{FOO} ? "$ENV{FOO}\n" : "NONE\n";
local $ENV{FOO} = "BAR";
print exists $ENV{FOO} ? "$ENV{FOO}\n" : "NONE\n";
it'll always print:
NONE
BAR
Make sure that you test under httpd -X mode so you won't get mislead.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Scope of Perl Special Variables
Bill Catlan wrote:
> Hello,
>
> The online mod_perl guide
> (http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
> ml) states:
>
> "Special Perl variables like $| (buffering), $^T (script's start time), $^W
> (warnings mode), $/ (input record separator), $\ (output record separator) and
> many more are all true global variables; they do not belong to any particular
> package (not even main::) and are universally available. This means that if you
> change them, you change them anywhere across the entire program; furthermore you
> cannot scope them with my()."
>
> My question pertains the CGI %ENV hash. First, I'm assumong that this is a
> global variable in the sense of a Perl Special Variable, and not just a main::
> or other package global. My question is how is it the case that the %ENV
> variable script instance might be working with doesn't get clobbered or "reset"
> by the next incoming request. Are some variables, like %ENV treated differently
> by mod_perl?
>
> Also, how can special variables be reliably initialized? For example, if one
> request provides a certain attribute, such as HTTP_IDENT, but a subsequent
> request does not, how do I know that the value of $ENV{HTTP_IDENT} on the second
> request will indeed be undefined?
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Cheap and unique
David Jacobs wrote:
>
> Good morning.
>
> Ken is correct - I am not looking for random, I am looking for unique.
>
> Unique and sequenced would be ideal, but it's tricky because if I use
>
> $i++.$IP_address.$parameter.$PID
> {$i is global, $IP_address is the server address, $parameter is a
> parameter that was just passed in, $PID is the apache process ID.}
>
> That's a decent solution, but it's not quite sequential because one
> Apache process could handle far more many requests than another, and so
> a later request could have a lower $i.
>
> Are there any code examples out there that use mod_unique_id.c ? I am
> new to mod_perl and couldn't quite get that. Looking at the code, it
> looks like mod_unique_id does basically the same thing but with a shared
> counter between the different servers.
>
> Also what is the cheapest way to get a datestamp? (I'm assuming it's not
> `date %Y%M%D%H%S`)
>
> --
>
> I'm sorry to be such a noob, but when I've got a little more mod_perl
> under my belt I'll be answering questions up a storm!
It looks like you didn't see my replies to your post. Please read them
first.
http://marc.theaimsgroup.com/?l=apache-modperl&m=102022922719057&w=2
http://marc.theaimsgroup.com/?l=apache-modperl&m=102023259920560&w=2
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory explodes loading CSV into hash
Ernest Lergon wrote: > having a look at Apache::Status and playing around with your tips on > > http://www.apacheweek.com/features/mod_perl11 > > I found some interesting results and a compromising solution: Glad to hear that Apache::Status was of help to you. Ideally when such a situation happens, and you must load all the data into the memory, which is at short, your best bet is to rewrite the datastorage layer in XS/C, and use a tie interface to make it transparent to your perl code. So you will still use the hash but the refs to arrays will be actually C arrays. > Another thing I found is, that Apache::Status seems not always report > complete values. Therefore I recorded the sizes from top, too. Were you running a single process? If you aren't Apache::Status could have shown you a different process. Also you can use GTop, if you have libgtop on your system, which gives you a perl interface to the proc's memory usage. See the guide for many examples. > Success: A reduction from 26 MB to 7 MB - what I estimated in my first > mail. :) ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: Re: Cheap and unique]
In my post I've missed the 'd' token in "%05d"
Here are a few possible solutions that will do all the work for you
Apache/UUID.pm
--
package Apache::UUID;
use strict;
my($base, $seq);
die "Cannot push handlers" unless Apache->can('push_handlers');
init();
sub init {
Apache->push_handlers(
PerlChildInitHandler => sub {
$seq = 0;
$base = $^T . sprintf("%05d", $$);
1;
});
}
sub id { $base . $seq++; }
#sub format { ... }
1;
__END__
startup.pl
--
use Apache::UUID; # must be loaded at the startup!
test.pl
use Apache::UUID;
print "Content-type: text/plain\n\n";
print Apache::UUID::id();
Since I've used $^T token, the module must be loaded at the startup, or
someone may modify $^T. If you use time(), you don't need the child init
handler (but you pay the overhead). and can simply have:
package Apache::UUID;
use strict;
my($base, $seq);
sub id {
$base ||= time . sprintf("%05d", $$);
$base . $seq++;
}
1;
the nice thing about the childinit handler is that at run time you just
need to "$base . $seq++;". but probably this second version is just fine.
also you probably want to add a format() function so you get the ids of
the same width.
another improvement is to use pack(), which will handle sprintf for you
and will create a number which is more compact and always of the same width:
package Apache::UUID;
use strict;
my $seq;
sub id { unpack "H*", pack "Nnn", time, $$, $seq++;}
1;
Another problem that you may need to tackle is predictability... but
that's a different story.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: Re: Cheap and unique]
Michael Robinton wrote:
>>>I'm just curious - what's wrong with the function you're already using?
>>
>>Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
>
>
>> TIMESTAMP . $$ . $GLOBAL++
Do not use concat, but sprintf 0 padding. Here is an example that can
happen easily which produces two identical ids in two different procs:
P TIMESTAMP $$ $GLOB CONCAT SPRINTF
A 1020227781 753 3 10202277817533 1020227781007533
B 1020227781 7533 10202277817533 10202277810007533
As you can see if you don't pad $$ with 0 to the max proc's len (on some
machines 63999) you can get two identical UUIDs in CONCAT column above.
The same can happen with the edge of timestamp when its first digit
switches from 9 -> 10, but then this number is so big, this is most
likely won't be a problem.
So a much safer solution would be :
$uuid = time . sprintf("%05", $$) . $GLOBAL++;
s/05/06/ or other if your system's process ID can be bigger than 5 digits.
if you don't modify $^T and you don't reuse the timestamp set for you in
$r, this will save you a few more millisecs:
$uuid = $^T . sprintf("%05", $$) . $GLOBAL++;
Since $^T . sprintf("%05", $$) is unique across processes. It's not
possible to create two processes with the same $$, at the same time.
$^T is the time the Perl interpreter has been started, unless it was
modified later.
You can also move all this "work" in the ChildCleanup Handler, so during
the request time, you use a value that has been already precalculated
for the current request at the end of the previous one. (just make sure
to initialize it during the ChildInit Handler for the first request).
p.s. this concept works on Unix for sure, it's possible that on some OSs
it won't work.
p.p.s. in mod_perl 2.0 we have APR::UUID that does this work for you.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2.0 worker MPM
Patrick Mackinlay wrote: > Hello, > > I am looking into using mod_perl with Apache 2 and the worker MPM, I was > wondering what the status is of mod_perl for this setup. I noticed that > in the docs it says it is in the alpha stage, is this due to perls > ithreads not being quite ready? No, it's due to the fact that Apache 2.0 wasn't released yet (meaning that there are still API changes) and not everything has been implemented in mod_perl 2.0. If you want to see what works look at the test suite under t/ in the source distro. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::DBI fails to compile?
F.Xavier Noria wrote: > I installed Apache::DBI and "make test" run no test, but the "make test" > of Apache::AuthCookieDBI tries to use Apache::DBI and fails because > Apache/DBI.pm in line 202 invokes Apache->module(), which it seems it is > not in the interface of the Apache class I have installed: > > $ perl -MApache::DBI -e1 > Can't locate object method "module" via package "Apache" (perhaps you forgot to >load "Apache"?) at /usr/local/share/perl/5.6.1/Apache/DBI.pm line 202. > Compilation failed in require. > BEGIN failed--compilation aborted. > > This is the version of Apache.pm I have installed: > > $ perl -MApache -le 'print $Apache::VERSION' > 1.27 > > and mod_perl is 1.26, do you know what could wrong? That's normal. You cannot test modules that use mod_perl API without running them inside mod_perl server. I've the same problem as you've reported. This test suite is simple broken. If you talk to the Jacob Davies, please tell him that it's a good idea to set the prerequisites in Makefile.PL, so his module will be installable from CPAN, without doing any manual work. All Apache:: module authors should be moving to use the new Apache::Test framework soon, since it lets you test the code under running mod_perl server and works with both versions of httpd/mod_perl. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: PerlRun problem: can't find method "uri"?
Ricky wrote: > Hi All, > I am trying to porting mod_cgi script to mod_perl script because > the mod_cgi script don't run correctly under mod_perl. > > When running under apache::registry, the script show wrong result. what do you mean, wrong results. Have you read http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html > When running under apache::perlrun, the script sometimes crash. > In error_log show : > "can't locate object method "uri" via package "Apache::perlrun" > > In mod_perl manual said that the script usually run in apache::perlrun > widthout change but not in my script. > > And I can't add "use strict" because it will crash the script immediatelly. > In error_log show : > "Variable "%in" is not imported at /home/httpd/html/scdf/scdf.plx line 174." > "Global symbol "$sth" requires explicit package name at > /home/httpd/html/scdf/scdf.plx line 171." You better fix these errors, and keep 'use strict' in place. Then PerlRun should work without any problems in most cases. If after fixing those problems you still have problems, come back with your relevant questions again. It's a good idea to have your code running under 'use strict' no matter if you use mod_perl or not. This will save you a lot of grief in a long run. > Our company planning to move from Perl/CGI to better/faster technology. > Currently research about mod_perl. > Is it a good decision try to move to mod_perl because the implementation time > is slow. > Is there any other tech that easier/more faster than mod_perl? > How about PHP or JSP? It depends on your definition of "easier". Easier==sloppier: better stay away from mod_perl. Easier==more flexible: go with mod_perl. As for the speed, I doubt you will find something *significantly* faster than mod_perl. Assuming that you learn how to get the most our of mod_perl. [p.s. please make sure you reply back to the list!] __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory explodes loading CSV into hash
Ernest Lergon wrote: > Hi, > > thank you all for your hints, BUT (with capital letters ;-) > > I think, it's a question of speed: If I hold my data in a hash in > memory, access should be faster than using any kind of external > database. > > What makes me wonder is the extremely blown up size (mod)perl uses for > datastructures. Looks like you've skipped over my suggestion to use Apache::Status. It uses B::Size and B::TerseSize to show you *exactly* how much memory each variable, opcode and what not uses. No need to guess. You can use B:: modules directly, but since you say that outside of mod_perl the memory usage pattern is different I'd suggest using Apache::Status. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Memory explodes loading CSV into hash
Ernest Lergon wrote:
> Hi,
>
> in a mod_perl package I load a CSV file on apache startup into a simple
> hash as read-only class data to be shared by all childs.
>
> A loading routine reads the file line by line and uses one numeric field
> as hash entry (error checks etc. omitted):
>
> package Data;
>
> my $class_data = {};
>
> ReadFile ( 'data.txt', $class_data, 4 );
>
> sub ReadFile
> {
> my $filename = shift; # path string
> my $data = shift; # ref to hash
> my $ndx_field = shift; # field number
>
> my ( @record, $num_key );
> local $_;
>
> open ( INFILE, "<$filename" );
> while ( )
> {
> chomp;
> @record = split "\t";
> $num_key = $record[$ndx_field];
> $data->{$num_key} = [ @record ];
> }
> close ( INFILE );
> }
>
> sub new...
> creates an object for searching the data, last result, errors etc.
>
> sub find...
> method with something like:
> if exists $class_data->{$key} return...
> etc.
>
> Now I'm scared about the memory consumption:
>
> The CSV file has 14.000 records with 18 fields and a size of 2 MB
> (approx. 150 Bytes per record).
>
> Omitting the loading, top shows, that each httpd instance has 10 MB (all
> shared as it should be).
>
> But reading in the file explodes the memory to 36 MB (ok, shared as
> well)!
>
> So, how comes, that 2 MB data need 26 MB of memory, if it is stored as a
> hash?
>
> Reading perldebguts.pod I did not expect such an increasing:
>
> Description (avg.) CSV Perl
> 4 string fields (4 chars)16 bytes (32 bytes) 128 bytes
> 9 float fields (5 chars) 45 bytes (24 bytes) 216 bytes
> 5 string fields (rest) 89 bytes (32 bytes) 160 bytes
> the integer key (20 bytes) 20 bytes
> 150 bytes 524 bytes
> That will give 14.000 x 524 = approx. 7 MB, but not 26 MB !?
>
> Lost in space...
Use Apache::Status, which can show you exactly where all the bytes go.
See the guide or its manpage for more info. I suggest that you
experiment with a very small data set and look at how much memory each
record takes.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problems on OS X
Ken Williams wrote:
>
> On Sunday, April 28, 2002, at 04:48 PM, Stas Bekman wrote:
>
>> it does solve the problem on linux. Ken, can you test the bleadperl?
>> This fix was applied as a solution. If `pwd` doesn't work for you,
>> that sucks! Meaning that the problem wasn't fixed in bleadperl :( Can
>> you check the recent Cwd thread on p5p (started by me) and try running
>> cwd.t under -T?
>
>
> All bleadperl tests pass for me, except 'ext/DB_File/t/db-recno' which I
> think is known to fail.
>
> Both Cwd tests pass, in particular:
>
> ext/Cwd/t/cwd...ok
> ext/Cwd/t/taint.ok
>
> But you mention running them with -T - how do I do that?
you add -T, to ext/Cwd/t/cwd.t's shebang line, and run it as
PERL_CORE=1 LD_LIBRARY_PATH=/home/stas/perl.org/perl-current ./perl
ext/Cwd/t/cwd.t
I think my patch untainting the test's code went in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-04/msg01274.html
>>> If I also do "$ENV{PATH} = '/bin';" after that, the server gets
>>> farther before failing (this is with a fully static build - I'm
>>> giving up on APACI for now, I get link errors there). Now I get this
>>> error in t/logs/error_log:
>>>
>>> Insecure dependency in eval while running with -T switch.
>>> Callback called exit.
>>>
>>> Doesn't exactly tell me where to start looking for the error, anyone
>>> have hints? The above is the entire contents of the log.
>>
>>
>> Doug has started fixing this problem, but didn't finish. See:
>> http://marc.theaimsgroup.com/?t=10188093473&r=1&w=2
>
>
> Hmm, I'm now seeing different behavior than what I saw before. Using
> APACI and your Cwd.pm patch, the server never started, nor did it create
> t/logs/error_log. I just tried it now with a simple static build,
> though, and it did succeed. All mod_perl tests pass, though there are
> lots of warnings during the tests about "Can't exec 'pwd': No such file
> or directory". That's to be expected?
As you said earlier, my patch, fixed Cwd's _backtick_pwd under the taint
mode on linux, but broke on yours. must be reported as a bug to p5p and
fixed. 5.8.0 should be out any week now. I'm not sure what the
alternative fix for the taint problem there, you cannot know where pwd
util resides, so you cannot just say $ENV{PATH}='/bin/', can you?
in any case let's move this discussion to p5p.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problems on OS X
Ken Williams wrote:
>
> On Sunday, April 28, 2002, at 01:47 PM, Stas Bekman wrote:
>
>> Ken, CWD.pm, has always suffered from taint problems. This problem has
>> been fixed in the bleadperl, try this patch:
>>
>> --- /tmp/Cwd.pmSun Apr 28 11:44:38 2002
>> +++ /home/stas/perl.org/perl-5.6.1/lib/Cwd.pmFri Sep 14 17:09:10 2001
>> @@ -89,7 +89,6 @@
>> # The 'natural and safe form' for UNIX (pwd may be setuid root)
>>
>> sub _backtick_pwd {
>> -local @ENV{qw(PATH IFS CDPATH ENV BASH_ENV)};
>> my $cwd = `pwd`;
>> # `pwd` may fail e.g. if the disk is full
>> chomp($cwd) if defined $cwd;
>
>
> This still fails, because it won't find `pwd` without a path.
it does solve the problem on linux. Ken, can you test the bleadperl?
This fix was applied as a solution. If `pwd` doesn't work for you, that
sucks! Meaning that the problem wasn't fixed in bleadperl :( Can you
check the recent Cwd thread on p5p (started by me) and try running cwd.t
under -T?
> If I also
> do "$ENV{PATH} = '/bin';" after that, the server gets farther before
> failing (this is with a fully static build - I'm giving up on APACI for
> now, I get link errors there). Now I get this error in t/logs/error_log:
>
>
> Insecure dependency in eval while running with -T switch.
> Callback called exit.
>
>
> Doesn't exactly tell me where to start looking for the error, anyone
> have hints? The above is the entire contents of the log.
Doug has started fixing this problem, but didn't finish. See:
http://marc.theaimsgroup.com/?t=10188093473&r=1&w=2
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problems on OS X
Stas Bekman wrote:
> Ken Williams wrote:
...
> Ken, CWD.pm, has always suffered from taint problems. This problem has
> been fixed in the bleadperl, try this patch:
>
> --- /tmp/Cwd.pmSun Apr 28 11:44:38 2002
> +++ /home/stas/perl.org/perl-5.6.1/lib/Cwd.pmFri Sep 14 17:09:10 2001
> @@ -89,7 +89,6 @@
> # The 'natural and safe form' for UNIX (pwd may be setuid root)
>
> sub _backtick_pwd {
> -local @ENV{qw(PATH IFS CDPATH ENV BASH_ENV)};
oops, s/^-/+/ here
> my $cwd = `pwd`;
> # `pwd` may fail e.g. if the disk is full
> chomp($cwd) if defined $cwd;
>
> and if it works for you consider submitting it to Sarathy for 5.6.2.
>
> ______
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: problems on OS X
Ken Williams wrote:
> Hi,
>
> I used to be able to compile mod_perl pretty easily on Mac OS X, but now
> for some reason (upgrades of modules? OS upgrades?) I'm having a lot of
> trouble getting past 'make test'. Here's what happens (no matter
> whether I compile statically with just EVERYTHING=1, or as a DSO as per
> http://david.wheeler.net/osx.html):
>
>
>
> [junior:~/Downloads/perl/mod_perl-1.26] ken% make test
> cp t/conf/mod_perl_srm.conf t/conf/srm.conf
> /usr/local/src/apache_1.3.23/src/httpd -f `pwd`/t/conf/httpd.conf -X -d
> `pwd`/t &
> httpd listening on port 8529
> will write error_log to: t/logs/error_log
> letting apache warm up...\c
> [Sun Apr 28 12:29:28 2002] [error] Insecure $ENV{PATH} while running
> with -T switch at /System/Library/Perl/Cwd.pm line 92.
> BEGIN failed--compilation aborted at
> /System/Library/Perl/ExtUtils/testlib.pm line 6.
> Compilation failed in require at
> /Users/ken/Downloads/perl/mod_perl-1.26/t//docs/startup.pl line 9.
> BEGIN failed--compilation aborted at
> /Users/ken/Downloads/perl/mod_perl-1.26/t//docs/startup.pl line 9.
> Compilation failed in require at (eval 1) line 1.
> <>
>
>
> It's possible that it might have something to do with
> ExtUtils::MakeMaker and its seedy friends, because I've been helping
> work on that and installing betas from time to time. But I'm not sure
> where to start looking at that. I'm currently using EU::MM 5.91_01.
>
> Any suggestions?
Ken, CWD.pm, has always suffered from taint problems. This problem has
been fixed in the bleadperl, try this patch:
--- /tmp/Cwd.pm Sun Apr 28 11:44:38 2002
+++ /home/stas/perl.org/perl-5.6.1/lib/Cwd.pm Fri Sep 14 17:09:10 2001
@@ -89,7 +89,6 @@
# The 'natural and safe form' for UNIX (pwd may be setuid root)
sub _backtick_pwd {
-local @ENV{qw(PATH IFS CDPATH ENV BASH_ENV)};
my $cwd = `pwd`;
# `pwd` may fail e.g. if the disk is full
chomp($cwd) if defined $cwd;
and if it works for you consider submitting it to Sarathy for 5.6.2.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: modperl-docs/tmpl/custom/html download_linkpage_toc_section
Stas Bekman wrote: > argh, sometimes I talk too much, and it's late... i should stop talking, > going to sleep... :) oops, the wrong list, must be the late hour. sorry about that. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: modperl-docs/tmpl/custom/html download_linkpage_toc_section
Per Einar Ellefsen wrote: > At 19:59 27.04.2002, Stas Bekman wrote: > >>> Don't misunderstand: when i said TOC I meant the list of links on the >>> front page etc. have you checked the front page on perl.apache.org? >>> These lists aren't generated with but with various inside a >>> . I guess this was forgotten. >> >> >> Well, we Allan suggested this change, I've agreed with Allan, nobody >> said otherwise, the change went it. What's wrong with index.html pages >> having their items underlined? > > > Hmm, I missed that part :( > Well, I think it looked better before. A lot cleaner in my opinion. But > if you prefer it as it is now, I won't complain about it. I think the point is that not in what are our private preferences are. It's about deciding what's good for the average user. It's a know fact that all usability consultants preach that the sites shouldn't change the expected behavior to make it easier on the user. That means underlined links, blue color for the links, redish for the visited links. We try to follow this rule with a few exceptions where we think the underlining adds too much noise and it's absolutely clear that the menu is comprised of links. So it's easy with the menu. Now the TOC part is harder, since it's not clear that TOC is a clickable menu, but you learn that fast. So far so good. The rest of the elements which aren't "menus" should have the default behaviour. It made sense to have no-underline for index.html items when they had no description. Now when the description is in place the underlining is more importants, since not everything is a link (think of color blind people). Sure people can learn after a while that index.html's items always start with links, but that's much harder when the links are mixed with non links (and it doesn't work for everybody, think color-blind again). If you think this logic is wrong, please explain why and then we can re-consider. If someones doesn't participate in the discussions, it's obvious that his opinion won't be heard by others, and the decisions are made based on the opinions of the others... argh, sometimes I talk too much, and it's late... i should stop talking, going to sleep... :) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::VMonitor problem
Richard Titmuss wrote: > > Stas Bekman wrote: > >> Richard Titmuss wrote: >> >>> Hi, >>> >>> I am trying to setup Apache::VMonitor on a mod-perl enabled server. >>> The page is returned OK but some of the information seem corrupt. The >>> following is an example of the output which I get: >>> >>> ##PID M Elapsed LastReq Srvd Size Share VSize Rss >>> ClientRequest (first 64 chars) >>> 5: 22691 1 0.000s 8.34d 60K 16.1M 14.8M 19.5M 16.1M >>> 127.0.0.2 GET /sys-monitor >>> >>> >>> The 'M', 'Elapsed', 'LastReq' and 'Srvd' columns are not returning >>> sensible values. I'd only just started this server so the last >>> request cannot have taken 8days! >>> >>> It appears the the apache scoreboard is not being read correctly. Can >>> anyone help? >> >> >> >> Well as you've probably figured out it's not an Apache::VMonitor >> problem, since it doesn't do much but reading the data from >> Apache::Scoreboard and formatting it nicely. >> >> Does your mod_status show valid data in the extended mode? Id not it's >> an apache problem. > > > I've checked mod_status and the results are displayed correctly. Does > this mean that it is an Apache::Scoreboard problem? I've tried > recompiling both apache and Apache::Scoreboard but this does not help. > Any ideas? I haven't modified the code logic in a while and there were no bug reports, so most likely something wrong happens at the Apache::Scoreboard level. Simply try to debug it and compare with what mod_status reports. Both mod_status and Apache::Scoreboard use the same source of information. what platform, perl version do you have this problem on? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::OK error
Per Einar Ellefsen wrote: > Yes, Stas, but I think this example was taken from the docs: > >http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/overview/overview.html#Apache__Echo > > > These examples need to be synced with the CVS versions then. done, thanks ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
