Re: Problems installing libapreq
On 15 Aug 2001, Joe Schaefer wrote: Nick Tonkin [EMAIL PROTECTED] writes: I'm trying to install libapreq on a new box on which I've rolled an apache-mod_ssl-openssl combo. ^^ If you have, the include directories (-I) that apreq uses to find the header files are listed with % perl -MApache::src -wle 'print Apache::src-new-inc' This prints a blank line (although to be fair on other boxes it prints a long list of dirs). But Apache.pm is fine: cpan install Apache Apache is up to date. apache_request.h:5: httpd.h: No such file or directory apache_request.h:6: http_config.h: No such file or directory apache_request.h:7: http_core.h: No such file or directory apache_request.h:8: http_log.h: No such file or directory apache_request.h:9: http_main.h: No such file or directory apache_request.h:10: http_protocol.h: No such file or directory apache_request.h:11: util_script.h: No such file or directory *** Error code 1 Somehow they are not getting setup right. Yeah, no kidding, Joe. Anyone have any ideas how to set things up right? And why when I use the './configure --with-apache-includes=DIR' syntax to manually specify a dir where the relevant files do in fact live, it no works? And especially why the weird error: root@wm-server /tmp/libapreq-0.33make Making all in c Makefile, line 278: Need an operator
Re: Apache::Request
Hello, RHI get the following error on RHmy $i = Apache::Request-instance($r); RH RHCan't locate object method instance via package Apache::Request Just to avoid the whoops factor: make sure you have use Apache::Request in your script, too. This can also cause the error you are reporting. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Children dying
Stas Bekman wrote: No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? So what is the point of having DSO at all then? The question was 'How do I build on Solaris with DSO?', the answer was 'Build perl to use the system malloc', I don't see what the problem with that is. -- Alan Burlison -- $ head -1 /dev/bollocks repurpose collaborative focus groups, going forwards
DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alan Burlison wrote: Stas Bekman wrote: No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? So what is the point of having DSO at all then? The question was 'How do I build on Solaris with DSO?', the answer was 'Build perl to use the system malloc', I don't see what the problem with that is. You are right, it was my mistake. I read the solution to the problem was not to build it as DSO. (mail overload problem :( ) I'll add this note regarding Solaris. I think the best thing would be if somebody who has an extensive DSO build experience across many platforms could summarize the problems, so we can put it into the guide. Personally I always build my production servers as static, so I only rely on comments from others. Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc * My server leaks memory on restart with DSO = don't use DSO _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Children dying
Thanks very much to all of you. I've upgraded my perl distro to 5.6.1 and recompiled everything and the children stopped dying. Alex
RE: Children dying
On Thu, 16 Aug 2001, Stas Bekman wrote: The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? because solaris is a special case. as is any platform where perl defaults to using its own malloc. the problem is perl's malloc pollutes the main httpd program with 'free' and 'malloc' symbols. when apache restarts (happens at startup too), any references in the main program to 'free' and 'malloc' now point to la-la land, things go boom. with 5.6.0+ this pollution can be prevented with -Ubincompat5005. or -Uusemymalloc for any version of perl, but there's a chance that might hurt performance depending on platform, so -Ubincompat5005 is likely a better choice. the modperl Makefile.PL has warned about this problem for ages, but i think the warning is often missed/ignored.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Stas Bekman wrote: Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; which can be turned off with: % Configure -Ubincompat5005 ... * My server leaks memory on restart with DSO = don't use DSO shouldn't happen with 5.6.1, at least it doesn't with my testing.
Re: DSO problems summary? (was Re: Children dying)
On Thu, Aug 16, 2001 at 09:35:43AM -0700, Doug MacEachern wrote: that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; Well... With # perl -v This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; # perl -V:bincompat5005 bincompat5005='define'; on # uname -a SunOS netra 5.8 Generic_108528-09 sun4u sparc SUNW,UltraAX-i2 am I safe? Or what should I rebuild with what flags? Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. Alex.
Re: Do virtual hosts need their own servers?
Hi there, On Wed, 15 Aug 2001, Philip Mak wrote: When I have multiple virtual hosts running Apache::ASP (mod_perl), do they need to run their own instance of Apache? If one Apache is listening to port 80 then no others can. This is why you will get an error message when you try to start an Apache when there is already one listening on the port(s) that the newly starting Apache tries to bind to. If you want to run more than one Apache server instance then they all have to listen on different ports. So you could for example do some URL-based redirecting with a proxy listening on 80 and handing requests to other instances which are listening on other ports, or something like that - a bit like having a light/heavy server pair (see the Guide) but for different reasons. and the webmasters of the different virtual hosts trust each other, then is it safe to [snip] 'Trust' and 'Safe' are interesting concepts on the Web. 'Suspect' and 'dangerous' are more likely. 73, Ged.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alex Povolotsky wrote: This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; that's fine. Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. how did you build modperl? if USE_APXS=1 you may have missed this other warning: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) the first option is the easiest cure.
Re: Do virtual hosts need their own servers?
On Thu, Aug 16, 2001 at 06:47:23PM +0100, Ged Haywood wrote: Hi there, On Wed, 15 Aug 2001, Philip Mak wrote: When I have multiple virtual hosts running Apache::ASP (mod_perl), do they need to run their own instance of Apache? If one Apache is listening to port 80 then no others can. This is why you will get an error message when you try to start an Apache when there is already one listening on the port(s) that the newly starting Apache tries to bind to. If you want to run more than one Apache server instance then they all have to listen on different ports. So you could for example do some URL-based redirecting with a proxy listening on 80 and handing requests to other instances which are listening on other ports, or something like that - a bit like having a light/heavy server pair (see the Guide) but for different reasons. Only one instance of apache can bind to the same port *on the same IP*. By having one server answer to multiple IP addresses (on one or many network interface cards) you can have as many apache instances as you have IP addresses (not forgetting 127.0.0.1 if you're so inclined). Depending on the O/S you may also consider (I have and have dismissed it as too troublesome) running apache on different ports and using transparent port mapping such that -- IP address 1 : 80 -- local port 8000 -- IP address 2 : 80 -- local port 8001 -- IP address 3 : 80 -- local port 8002 Dave -- - Dave Baker : [EMAIL PROTECTED] : [EMAIL PROTECTED] : http://dsb3.com/ - GnuPG: 1024D/D7BCA55D / 09CD D148 57DE 711E 6708 B772 0DD4 51D5 D7BC A55D
Re: readdir()
This feature is present when compiling under rh 7.1. With rh 6.2 there is no problem. This seems to be related as you have said to the glibc version. I compiled on rh 6.2 and move the httpd binary on rh 7.1 and there was no problem with readdir anymore. On Thu, 26 Apr 2001, Lincoln Stein wrote: Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: Hello, LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- Pierre Laplante SedNove Inc.
Re: Do virtual hosts need their own servers?
Hi there, On Thu, 16 Aug 2001, Jonathan Edwards wrote: Related to this topic, I have a question about multiple instances of Apache. We run two mod_perl enabled sites on two separate IPs. These sites rely on mod_perl heavily. Each site has a unique perl script that handles just about everything. Currently, we only have one instance of Apache running, and I've noticed that the httpd child processes are quite large (up to 32megs!). We've upgraded the RAM on our server twice and now we're at 512, but it seems to be using all of that without a problem. Are these httpd processes so large because they include copies of both perl scripts? Would it be more efficient to set up two instances of Apache, one for each site/IP, and that way each child httpd would only contain one of the two perl scripts? You can experiment but I wouldn't hold out great hopes of miracles. It could be that there's a lot of bloat from modules that you use, so you can find that even an apparently small script makes your Apache children grow alarmingly. Another common fault - if you can call it a fault - is the abuse of Perl's willingness to read huge data structures into RAM. It's sometimes the result of quick-n-dirty coding techniques at the prototype stage finding their way into user-facing code. You might also find that a large fraction of the RAM used by Apache is shared so effectively it doesn't matter. Do the processes start off much smaller and grow over time? If so it might be worth cutting down on MaxRequestsPerChild to see what happens. There's a good section about tuning in the Guide, it covers the sharing issues too. http://perl.apache.org/guide (forgive me if you've read it already:). 73, Ged.
RE: Children dying
No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-) exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? Because the admonition to -Dusemymalloc is not the same as, nor easily deduce-able from, advice to compile static. The guy who had the problem that started this thread did everything right, i.e. use the same compiler, start from fresh sources, compile static, no Expat, yet he still had segfaults. Maybe the Guide ISN'T the best place. Maybe the best place is mod_perl's INSTALL document. But somehow I'd be willing to bet that this advice holds true for earlier versions than, oh, the NEXT release of mod_perl... which is where/when such a change to INSTALL would be for those of us who aren't yet brave enough to use the CVS version daily. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Do virtual hosts need their own servers?
On Thu, Aug 16, 2001 at 12:13:37PM -0600, Jonathan Edwards wrote: Related to this topic, I have a question about multiple instances of Apache. We run two mod_perl enabled sites on two separate IPs. These sites rely on mod_perl heavily. Each site has a unique perl script that handles just about everything. Currently, we only have one instance of Apache running, and I've noticed that the httpd child processes are quite large (up to 32megs!). We've upgraded the RAM on our server twice and now we're at 512, but it seems to be using all of that without a problem. Are these httpd processes so large because they include copies of both perl scripts? Would it be more efficient to set up two instances of Apache, one for each site/IP, and that way each child httpd would only contain one of the two perl scripts? Compare the memory requirement two sets of perl scripts against the memory requirement of doubling the total number of apache processes. My personal opinion is that the latter will be a lot more expensive in resources. You might do better do work to optimize/minimize the total number of mod_perl instances (separate, lightweight server for images and static content; turn off keep_alive unless it's definately giving positive results; etc). How many apache children do you normally have running at any given time? Dave p.s. The processes could also be large because of suboptimal coding, or (if they grow over time) memory leaks p.p.p.s. love the palm pilot cases ... -- - Dave Baker : [EMAIL PROTECTED] : [EMAIL PROTECTED] : http://dsb3.com/ - GnuPG: 1024D/D7BCA55D / 09CD D148 57DE 711E 6708 B772 0DD4 51D5 D7BC A55D
RE: Children dying
-Original Message- From: Rob Bloodgood [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 16, 2001 11:20 AM To: Stas Bekman Cc: mod_perl Subject: RE: Children dying sigh... I didn't see the other thread that spawned from my orignal post... rendering this reply redundant. Apologies.
Re: Do virtual hosts need their own servers?
How many apache children do you normally have running at any given time? Apache is set to: MaxKeepAliveRequests 200 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 10 MaxClients 512 MaxRequestsPerChild 200 Is that to say that the max number of children is 20 (StartServers + MaxSpareServers) or 512 (MaxClients) I am just starting to learn about having a light server to perform all static functions. As you may have seen on the site, there are a lot of images. The images are stored in a MySQL database, and the mod_perl script requests them. Is my understanding correnct that I can set up a server to deal with all of the mod_perl scripting requests, and have a separate server that deals exclusively with displaying images and other static content? I'm a little confused, but it sounds like a pretty sweet deal. Jon - Original Message - From: Dave Baker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jonathan Edwards [EMAIL PROTECTED] Sent: Thursday, August 16, 2001 12:24 PM Subject: Re: Do virtual hosts need their own servers? On Thu, Aug 16, 2001 at 12:13:37PM -0600, Jonathan Edwards wrote: Related to this topic, I have a question about multiple instances of Apache. We run two mod_perl enabled sites on two separate IPs. These sites rely on mod_perl heavily. Each site has a unique perl script that handles just about everything. Currently, we only have one instance of Apache running, and I've noticed that the httpd child processes are quite large (up to 32megs!). We've upgraded the RAM on our server twice and now we're at 512, but it seems to be using all of that without a problem. Are these httpd processes so large because they include copies of both perl scripts? Would it be more efficient to set up two instances of Apache, one for each site/IP, and that way each child httpd would only contain one of the two perl scripts? Compare the memory requirement two sets of perl scripts against the memory requirement of doubling the total number of apache processes. My personal opinion is that the latter will be a lot more expensive in resources. You might do better do work to optimize/minimize the total number of mod_perl instances (separate, lightweight server for images and static content; turn off keep_alive unless it's definately giving positive results; etc). How many apache children do you normally have running at any given time? Dave p.s. The processes could also be large because of suboptimal coding, or (if they grow over time) memory leaks p.p.p.s. love the palm pilot cases ... -- - Dave Baker : [EMAIL PROTECTED] : [EMAIL PROTECTED] : http://dsb3.com/ - GnuPG: 1024D/D7BCA55D / 09CD D148 57DE 711E 6708 B772 0DD4 51D5 D7BC A55D
Out of Memory
I am getting out of memory error message in my error log. Can any one suggest a way in finding this memory leak? Thanks in advance... -r PS: it is a simple update of a record but I get: Out of memory during large request for 536875008 bytes... God help me :(
Re: Do virtual hosts need their own servers?
On Thu, 16 Aug 2001 14:24:50 -0400 Dave Baker [EMAIL PROTECTED] wrote: Compare the memory requirement two sets of perl scripts against the memory requirement of doubling the total number of apache processes. My personal opinion is that the latter will be a lot more expensive in resources. You might do better do work to optimize/minimize the total number of mod_perl instances (separate, lightweight server for images and static content; turn off keep_alive unless it's definately giving positive results; etc). Yes, do turn OFF keep_alive. This has the benefit of freeing up heavyweight mod_perl processes sooner. I do this, and serve graphics from a separate, lightweight server (thttpd), so I get the best of both worlds. I'm able to keep the number of mod_perl processes under 15, while still serving 40 hit per second, because the bulk of the hits are on graphics, where a full mod_perl server process is just a waste. -- Jay Thorne Manager, Systems Technology, UserFriendly Media, Inc. http://www.userfriendly.org/
Re: Out of Memory
[EMAIL PROTECTED] wrote: Rasoul Hajikhani writes: Yes. It has three gig of ram. Is Template Toolkit memory intensive? I was told that the swap was turned off on that machine. Swap was completly turned off? That isn't good... should have a small amount of swap... You may be asking for a chunk of memory the machine doesn't have available... can you run top on the machine? -- C Wayne Huling [EMAIL PROTECTED] Yes. I can run top on that machine. This problem, out of memory error, has just come up... I am being told that the machine does not need swap space!? Is this true? -r
Re: Problem with use getting the wrong file
On Thu, 16 Aug 2001, Philip Mak wrote: Hi, I have two mod_perl programs on my site. One is in the directory inr2, and the other is in the directory otherinr2. These mod_perl programs have exactly the same code. Both of them do: use cfg; where cfg.pm is a file that's in both inr2 and otherinr2, but it's different in these directories. But the code in otherinr2 is getting the cfg.pm from inr2 since they have the same filename and relative paths. How can I make the use command not act braindead about this? Is there a CPAN module that I can import to overload the use command with something that takes the full pathname into account perhaps? try a do 'cfg.pm'; to force the compile otherwise you might want to take a look at Apache::Reload on CPAN. remco
Re: modperl 2.0
On Sun, Aug 12, 2001 at 10:17:32AM -0400, Barrie Slaymaker wrote: On Sat, Aug 11, 2001 at 08:58:00AM -0600, The Doctor wrote: Hopefully this will point you in the right direction. I would need more data to figure it all out. As a next step, can you find the locations of the perls in question and run a perl5.6.0 -V, a perl5.6.1 -V and a perl -V? Weirdly perl5.6.1 -V thinks it is perl 5.6.0 ?-S
Re: modperl 2.0
On Sun, Aug 12, 2001 at 07:18:11PM -0400, Barrie Slaymaker wrote: On Sun, Aug 12, 2001 at 03:55:26PM -0600, The Doctor wrote: When I ran perl 5.6.1 it was identifying itself as perl 5.6.0 . Identity crisis?? Dunno, but you can bet it's not right. Care to post the command and results? Sounds like a symlink problem, you might want to use some combination of the ls -l, whence or hash, sum and strings commands to figure out what's right. I can promise you that perl 5.6.1 properly reports itself and that you'd have to edit it somehow to make it say otherwise (and I'm not proposing that somebody did). Whatever perls are running around that box are pretty screwed up, but the good news is it should be pretty easy to fix once the problem is hunted down... I even told perl 5.6.1 that it was 5.6.1 but still report 5.6.0 ?-S
Re: Do virtual hosts need their own servers?
Hi there, On Thu, 16 Aug 2001, Jonathan Edwards wrote: Apache is set to: StartServers 10 MaxClients 512 Is that to say that the max number of children is 20 (StartServers + MaxSpareServers) or 512 (MaxClients) MaxClients. But if you have 10M unshared in each child and only 500M of RAM you'll never get there, the machine will just grind to a halt as it starts to swap processes to and from disc. You really need to think hard about the settings. Read the docs. I am just starting to learn about having a light server to perform all static functions. [snip] have a separate server that deals exclusively with displaying images and other static content? I'm a little confused, but it sounds like a pretty sweet deal. You'll be a lot less confused after you've read the Guide a few times. http://perl.apache.org/guide 73, Ged.
Re: modperl 2.0
On Mon, Aug 13, 2001 at 11:25:50AM +0800, Stas Bekman wrote:
On Sun, 12 Aug 2001, Barrie Slaymaker wrote:
On Sun, Aug 12, 2001 at 08:39:09AM -0600, The Doctor wrote:
/usr/libdata/perl5/i386-bsdos/Config.pm
so this is fine, on linux this is called /i{3|4|5|6}86-linux/ whereas on
BSD this will be /i{3|4|5|6}86-bsdos/ or similar :)
but this all goes off-topic here.
And that is a perl issue, but people around here are trying to be more
helpful that the perl lot.
Re: Problem with use getting the wrong file
I have two mod_perl programs on my site. One is in the directory inr2, and the other is in the directory otherinr2. These mod_perl programs have exactly the same code. Both of them do: use cfg; where cfg.pm is a file that's in both inr2 and otherinr2, but it's different in these directories. But the code in otherinr2 is getting the cfg.pm from inr2 since they have the same filename and relative paths. How can I make the use command not act braindead about this? Is there a CPAN module that I can import to overload the use command with something that takes the full pathname into account perhaps? You can specify a full path to use/require. Check man perlfunc for the details. You can also specify a path relative to the current working directory if you don't like hard-coding full paths in your scripts. - Perrin
Re: modperl 2.0
At 4:02 PM -0600 8/16/01, The Doctor wrote: On Sun, Aug 12, 2001 at 10:17:32AM -0400, Barrie Slaymaker wrote: On Sat, Aug 11, 2001 at 08:58:00AM -0600, The Doctor wrote: Hopefully this will point you in the right direction. I would need more data to figure it all out. As a next step, can you find the locations of the perls in question and run a perl5.6.0 -V, a perl5.6.1 -V and a perl -V? Weirdly perl5.6.1 -V thinks it is perl 5.6.0 ?-S Please paste the entire output of perl5.6.1 -V so that we can see what's wrong. Thanks, Robert Landrum -- A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX.
Re: modperl 2.0
Weirdly perl5.6.1 -V thinks it is perl 5.6.0 ?-S Please paste the entire output of perl5.6.1 -V so that we can see what's wrong. Thanks, Here it comes: Script started on Thu Aug 16 16:12:49 2001 doctor.nl2k.ab.ca//usr/libdata$ find . -name \*Config.pm\* -print ./perl5/CPAN/Config.pm~ ./perl5/CPAN/Config.pm ./perl5/i386-bsdos/Config.pm ./perl5/site_perl/Net/Config.pm ./perl5/site_perl/i386-bsdos/Tk/Config.pm ./perl5/site_perl/i386-bsdos/Apache/MyConfig.pm ./perl5/site_perl/i386-bsdos/Apache/ModuleConfig.pm ./perl5/site_perl/5.005/HTML/EP/Config.pm ./perl5/site_perl/5.005/HTML/Mason/Config.pm ./perl5/site_perl/5.005/Apache/Roaming/LiPrefs/Config.pm ./perl5/site_perl/5.005/Apache/DBILogConfig.pm ./perl5/site_perl/5.005/i386-bsdos/Net/Config.pm ./perl5/site_perl/5.005/i386-bsdos/Apache/MyConfig.pm ./perl5/site_perl/5.005/i386-bsdos/Apache/ModuleConfig.pm ./perl5/site_perl/5.6.0/i386-bsdos/Apache/MyConfig.pm ./perl5/site_perl/5.6.0/i386-bsdos/Apache/ModuleConfig.pm ./perl5/site_perl/5.6.0/Net/Config.pm ./perl5/site_perl/5.6.0/Template/Config.pm ./perl5/5.00503/i386-bsdos/Config.pm ./perl5/5.00503/CPAN/Config.pm ./perl5/5.00503/CPAN/Config.pm~ Ok... There are several installations here. My guess is that the system was installed with perl version 5.00503. Then you upgraded to perl 5.6.0. Now you've upgraded again to perl 5.6.1. Perl 5.6.1 has installed a Config.pm into ./perl5/i386-bsdos/Config.pm. doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V Perl lib version (v5.6.0) doesn't match executable version (v5.6.1) at /usr/libdata/perl5/i386-bsdos/Config.pm line 21. Compilation failed in require. BEGIN failed--compilation aborted. Umm... perl5.6.0 -V is looking at the first config file it finds, which happens to be the one that was installed by perl 5.6.1. That is why the versions do not match. doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V[1P[4h1[4l Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: [snip] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under bsdos Compiled at May 9 2000 14:39:24 @INC: /usr/libdata/perl5/i386-bsdos /usr/libdata/perl5 /usr/contrib/lib/perl5/site_perl/5.6.0/i386-bsdos /usr/contrib/lib/perl5/site_perl/5.6.0 /usr/contrib/lib/perl5/site_perl . doctor.nl2k.ab.ca//usr/libdata$ exit exit At this point, I'm going to suggest that you fully migrate to perl 5.6.1. This means that you need to stop using perl5.6.0 in your #! lines. Either that, or remove perl5.6.0 and link it to perl5.6.1. Note: YMMV. ln -s /usr/bin/perl5.6.1 /usr/bin/perl5.6.0 If this is not what you have in mind, then I suggest reinstalling a fresh copy of perl 5.6.0 from source to overwrite the existing Config.pm file and any other files perl 5.6.1 might have installed. In the future, I would suggest including as much information in your original post as neccesary as not every one is as patient or as willing to help as I am, especially when the thread starts getting long. Sincerely, Robert Landrum -- A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX.
Re: Problem with use getting the wrong file
I have two mod_perl programs on my site. One is in the directory inr2, and the other is in the directory otherinr2. These mod_perl programs have exactly the same code. Both of them do: use cfg; where cfg.pm is a file that's in both inr2 and otherinr2, but it's different in these directories. But the code in otherinr2 is getting the cfg.pm from inr2 since they have the same filename and relative paths. How can I make the use command not act braindead about this? Is there a CPAN module that I can import to overload the use command with something that takes the full pathname into account perhaps? You can specify a full path to use/require. Check man perlfunc for the details. You can also specify a path relative to the current working directory if you don't like hard-coding full paths in your scripts. - Perrin I have learned recently(and the original poster as well) that despite two files having different file names, and doing a require /full/path/to/file.pl, modperl will only compile the file once because they both have the same package name. I have yet to find a solution to the problem that I like... I have a file that contains the database information (username, password, db name, connect functions, ect) and for a while I couldnt figure out why two scripts using two seperate files for database info would connect to the wrong database heh. ryan
Re: modperl 2.0
Thank you, much better. I can't make out the difference between the two command lines (again, I ask you to please clean up your script output, or just copy and paste from your terminal to your mailer, those ^Hs and ^]s make things hard to decipher). Can you do a type perl perl5.6.0 perl5.6.1, and then ls -l and sum each of those files? It looks like a symlink (or even a hardlink) problem. No way no how should perl5.6.0 have an executable version of Did you do the install of perl5.6.1 yourself? If so, did it look Ok? Also, when perl5.6.1 was installed, where did it put the libraries? Thanks, Barrie doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V Perl lib version (v5.6.0) doesn't match executable version (v5.6.1) at /usr/libdata/perl5/i386-bsdos/Config.pm line 21. Compilation failed in require. BEGIN failed--compilation aborted. doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V[1P[4h1[4l Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=bsdos, osvers=4.2, archname=i386-bsdos uname='bsdos rdlcom.com 4.2 bsdi bsdos 4.2 kernel #0: wed oct 25 17:38:20 mdt 2000 [EMAIL PROTECTED]:mntproto4.2-i386usrsrcsyscompilegeneric i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release) cppflags='-fno-strict-aliasing' ccflags ='-fno-strict-aliasing' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/X11/lib -L/usr/local/lib' libpth=/usr/local/lib /usr/shlib /shlib /lib /usr/lib /usr/X11/lib libs=-lbind -ldl -lm -lc libc=/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-shared -x -L/usr/X11/lib -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under bsdos Compiled at May 9 2000 14:39:24 @INC: /usr/libdata/perl5/i386-bsdos /usr/libdata/perl5 /usr/contrib/lib/perl5/site_perl/5.6.0/i386-bsdos /usr/contrib/lib/perl5/site_perl/5.6.0 /usr/contrib/lib/perl5/site_perl . doctor.nl2k.ab.ca//usr/libdata$ exit exit Script done on Thu Aug 16 16:13:30 2001 HTH
Re: modperl 2.0
On Thu, Aug 16, 2001 at 04:10:16PM -0600, The Doctor wrote: And that is a perl issue, but people around here are trying to be more helpful that the perl lot. Ofcourse people here are also a 'perl lot', so take care. We're only concentrating on one aspect of perl, that related to Apache. -- Alastair| [EMAIL PROTECTED] | http://www.calliope.demon.co.uk |PGP Key : A9DE69F8 ---
Re: modperl 2.0
On Thu, Aug 16, 2001 at 06:39:19PM -0400, Barrie Slaymaker wrote: Thank you, much better. I can't make out the difference between the two command lines (again, I ask you to please clean up your script output, or just copy and paste from your terminal to your mailer, those ^Hs and ^]s make things hard to decipher). Can you do a type perl perl5.6.0 perl5.6.1, and then ls -l and sum each of those files? It looks like a symlink (or even a hardlink) problem. No way no how should perl5.6.0 have an executable version of Script started on Thu Aug 16 16:52:56 2001 doctor.nl2k.ab.ca//usr/bin$ type perl pero5.6.0 l5.6.0 perl5.6.1 perl is ./perl perl5.6.0 is /usr/contrib/bin/perl5.6.0 perl5.6.1 is /usr/contrib/bin/perl5.6.1 doctor.nl2k.ab.ca//usr/bin$ echo bash tells me it is hashed bash tells me it is hashed doctor.nl2k.ab.ca//usr/bin$ ls -l perl* -rwxr-xr-x 1 root wheel11250 Jul 2 19:32 perl -r-xr-xr-x 1 news bin 264900 Oct 8 2000 perl4 lrwxr-xr-x 1 root wheel4 Aug 16 16:52 perl5 - perl lrwxr-xr-x 1 root wheel 26 Aug 16 16:52 perl5.00402 - ../contrib/bin/perl5.00402 -rwxr-xr-x 1 root wheel 1319624 Jan 16 1999 perl5.00502 -rwxr-xr-x 1 root wheel11250 Oct 8 2000 perl5.00503 -rwxr-xr-x 1 root wheel31722 Oct 8 2000 perlbug -rwxr-xr-x 1 root wheel26305 Oct 8 2000 perlcc -rwxr-xr-x 1 root wheel16823 Oct 8 2000 perldoc doctor.nl2k.ab.ca//usr/bin$ ls -l perl*[4h/[4l[4hu[4l[4hs[4l[4hr[4l[4h/[4l[4hc[4l[4ho[4l[4hn[4l[4ht[4l[4hr[4l[4hi[4l[4hb[4l[4h/[4l[4hb[4l[4hi[4l[4hn[4l[4h/[4l -rwxr-xr-x 1 root bin 9989 Jul 2 19:33 /usr/contrib/bin/perl lrwxr-xr-x 1 news bin 15 Aug 16 03:17 /usr/contrib/bin/perl4 - ../../bin/perl4 lrwxr-xr-x 1 news bin 14 Aug 16 03:17 /usr/contrib/bin/perl5 - ../../bin/perl -rwxr-xr-x 1 root bin10351 Jun 15 1998 /usr/contrib/bin/perl5.00402 -rwxr-xr-x 1 root bin 9989 May 29 1999 /usr/contrib/bin/perl5.00503 -rwxr-xr-x 1 root bin13313 Apr 12 13:23 /usr/contrib/bin/perl5.6.0 -rwxr-xr-x 1 root bin14184 May 1 20:05 /usr/contrib/bin/perl5.6.1 -rwxr-xr-x 1 root wheel 35467 May 1 20:06 /usr/contrib/bin/perlbug -rwxr-xr-x 1 root bin16922 May 1 20:06 /usr/contrib/bin/perlcc -rwxr-xr-x 1 root wheel 22649 May 1 20:06 /usr/contrib/bin/perldoc doctor.nl2k.ab.ca//usr/bin$ sum ^C doctor.nl2k.ab.ca//usr/bin$ sum perl perl5.6.0 perl p5.6 5.6.1 383 11 perl sum: perl5.6.0: No such file or directory sum: perl5.6.1: No such file or directory doctor.nl2k.ab.ca//usr/bin$ sum perl perl5.6.0 perl5.6.1[4h/[4l[4hu[4l[4hs[4l[4hr[4l[4h/[4l[4hc[4l[4ho[4l[4hn[4l[4ht[4l[4hr[4l[4hi[4l[4hb[4l[4h/[4l[4hb[4l[4hi[4l[4hn[4l[4h/[4lperl [4h/[4l[4hu[4l[4hs[4l[4hr[4l[4h/[4l[4hc[4loperl5.6.0 perl5.6.1 [Aoctor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/conperl5.6.0 perl5.6.1 1[Aoctor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contperl5.6.0 perl5.6.1[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrperl5.6.0 perl5.6.1[Ator.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contriperl5.6.0 perl5.[4h6[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contribperl5.6.0 perl5[4h.[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/perl5.6.0 perl[4h5[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/bperl5.6.0 per[4hl[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/biperl5.6.0 pe[4hr[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/binperl5.6.0 p[4he[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/bin/perl5.6.0 [4hp[4l[Actor.nl2k.ab.ca//usr/bin$ sum /usr/contrib/bin/perl /usr/contrib/bin/perl5.6. [4h/[4l[4hu[4l[4hs[4l[4hr[4l[4h/[4l[4hc[4l[4ho[4l[4hn[4l[4ht[4l[4hr[4l[4hi[4l[4hb[4l[4h/[4l[4hb[4l[4hi[4l[4hn[4l[4h/[4l 57522 10 /usr/contrib/bin/perl 5866 14 /usr/contrib/bin/perl5.6.0 14518 14 /usr/contrib/bin/perl5.6.1 doctor.nl2k.ab.ca//usr/bin$ exit exit Script done on Thu Aug 16 16:55:24 2001 Did you do the install of perl5.6.1 yourself? If so, did it look Ok? Yes, make test said all was ready and go. Also, when perl5.6.1 was installed, where did it put the libraries? LEt me see; I used BSD)SDistributed option. Thanks, Any helpful hints is REAL help. Barrie doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V Perl lib version (v5.6.0) doesn't match executable version (v5.6.1) at /usr/libdata/perl5/i386-bsdos/Config.pm line 21. Compilation failed in require. BEGIN failed--compilation aborted. doctor.nl2k.ab.ca//usr/libdata$ perl5.6.0 -V[1P[4h1[4l Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=bsdos, osvers=4.2,
PerlModule
My apache server does not start up when I add PerlModule B::TerseSize to the httpsd.conf file. Or any PerlModule flag. Any one can tell me why? I am trying to determine a leakage in my script... thanks -r
Re: PerlModule
My apache server does not start up when I add PerlModule B::TerseSize to the httpsd.conf file. Or any PerlModule flag. Any one can tell me why? I am trying to determine a leakage in my script... Do you have B::TerseSize installed on your system? It's not a standard module. Check your error_log for messages. - Perrin
Re: Problem with use getting the wrong file
I have learned recently(and the original poster as well) that despite two files having different file names, and doing a require /full/path/to/file.pl, modperl will only compile the file once because they both have the same package name. No, I don't think that's correct. Perl will compile both files if they have different paths and you specify the full path. However, if they do have the same package name, the second one will overwrite the first one, which is probably not what you intended. I have yet to find a solution to the problem that I like... I have a file that contains the database information (username, password, db name, connect functions, ect) and for a while I couldnt figure out why two scripts using two seperate files for database info would connect to the wrong database heh. There are tons of solutions for having separate config files for two scripts. You could name the config files differently and call the right one from each script. You could use a path relative to the current directory in your require statement. You could one conf file with one big hash of configuration that is keyed on a variable you set with PerlSetVar to something different for each script. - Perrin
mod_perl's ease of installation and the list (was: Re: Problemsinstalling libapreq)
On Thu, 16 Aug 2001 10:38:56 -0700 Ged Haywood wrote: On Wed, 15 Aug 2001, Nick Tonkin wrote: Somehow they are not getting setup right. Yeah, no kidding, Joe. He's only trying to help. :) Yes, you're right. Please accept my apology to you, Joe, for my gracelessness. However, this does bring up an issue I'd like to throw out there. I've been using mod_perl for more than three years. I'm a pretty experienced and fairly proficient developer in Perl. I have administered at least a dozen boxes running FreeBSD or Linux or Solaris, in the sense that I've kept them going and have installed a typical Perl-apache-mod_perl-RDBMS etc. setup on them. I'm _not_ a sysadmin, but I've always managed to run everything I needed to on my boxes, because for the most part, everything in the Open Source world works so damn well. However, I've installed mod_perl a lot of times, and I have to say that the majority of the times there has been some glitch during the installation that has stumped me and I've had to resort to the list for help. I've also seen over the years that a good portion of the traffic on this list has been requests for help with the install. Now many of you who are most proficient in the use of mod_perl and programming in general are also the ones who wind up knowing the answers to the install-related questions. For whatever reason you have acquired sysadmin skills as well as software development skills. Many others of us, though, don't have much experience at all in system admin, nor do we know much about system libraries and dependencies and whatnot. In my case at least, I don't care to become expert at that stuff; I've never programmed C and I don't intend to learn Java. I'm just a self-taught Perl hacker and happy with it. So what I mean to say is, firstly, that I think that it's unfortunate that the level of complexity of getting mod_perl going is so high, and maybe some more work could be directed in the ease-of-use area. I realize, of course that it takes at least two to tango, and to be fair there are many other components of a comprehensive web application platform that also have work together with each other and mod_perl. I'm sure in my current case it's something to do with how FreeBSD installed Perl, or some such. But that's my whole point. I don't think it should be a prerequisite that you be able to debug your whole system configuration in order to get mod_perl working. It just creates a barrier, one which I've always been determined to overcome, but which I am sure has turned many other would-be mod_perlers away. Secondly, and relatedly, for those of you who are generous enough to try to help when there's some glitch, please remember that there are some of us who almost never meddle with this stuff. I've noticed that often the answers tend to assume a great deal of knowledge of the guts of make and compiling and whatnot. Of course, mod_perl rules, Doug rules too, and every time I've needed help it has eventually come, as I'm sure it will this time. End of speech :) nick ( In the absence of any better ideas at this time, I'm gonna nuke /usr/local/lib/perl5 completely and see what happens if I start over again. ) ~~~ Nick Tonkin
Re: mod_perl's ease of installation and the list (was: Re: Problemsinstalling libapreq)
On Thu, 16 Aug 2001, Nick Tonkin wrote: ( In the absence of any better ideas at this time, I'm gonna nuke /usr/local/lib/perl5 completely and see what happens if I start over again. ) On FreeBSD, better do a new installation of perl somewhere else (/home/perl, /usr/local/perl/, ... whatever) and do all the mod_perl stuff with that (just use /home/perl/bin/perl Makefile.PL and /home/perl/bin/perl -MCPAN -e shell and so on later). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Problems installing libapreq
NT == Nick Tonkin [EMAIL PROTECTED] writes: NT And especially why the weird error: NT root@wm-server /tmp/libapreq-0.33make NT Making all in c NT Makefile, line 278: Need an operator Are you on a BSD system? The make is probably incompatible. GNU make (the default on Linux) uses different syntax for some things. If you're not using GNU make to build perl-related things, you should. ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Problems installing libapreq
NT And especially why the weird error: NT root@wm-server /tmp/libapreq-0.33make NT Making all in c NT Makefile, line 278: Need an operator Are you on a BSD system? The make is probably incompatible. GNU make (the default on Linux) uses different syntax for some things. If you're not using GNU make to build perl-related things, you should. ;-) Why not use the ports to install this (if FreeBSD)? If that's not an option, then use gmake as suggested. -sc -- Sean Chittenden PGP signature
cvs commit: modperl-2.0/t/apache read.t
dougm 01/08/16 10:24:57
Modified:t/apache read.t
Log:
force http; test doesnt work witih t/TEST -ssl
Revision ChangesPath
1.2 +3 -0 modperl-2.0/t/apache/read.t
Index: read.t
===
RCS file: /home/cvs/modperl-2.0/t/apache/read.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- read.t2001/05/05 18:46:14 1.1
+++ read.t2001/08/16 17:24:57 1.2
@@ -6,6 +6,9 @@
plan tests = 1;
+#force test to go over http, since this doesn't work with t/TEST -ssl
+Apache::TestRequest::scheme('http');
+
my $location = /TestApache::read;
my $socket = Apache::TestRequest::vhost_socket('default');
cvs commit: modperl-2.0/t/response/TestAPI server_rec.pm
dougm 01/08/16 20:51:37 Modified:t/response/TestAPI server_rec.pm Log: fix api/server_rec when running under t/TEST -ssl Revision ChangesPath 1.3 +1 -1 modperl-2.0/t/response/TestAPI/server_rec.pm Index: server_rec.pm === RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/server_rec.pm,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- server_rec.pm 2001/04/03 16:59:09 1.2 +++ server_rec.pm 2001/08/17 03:51:37 1.3 @@ -24,7 +24,7 @@ ok $s-port || 1; -ok $s-error_fname; +ok $s-error_fname || 1; #vhost might not have its own (t/TEST -ssl) #error_log;
cvs commit: modperl-2.0/t/filter input_msg.t
dougm 01/08/16 20:58:11
Modified:t/filter input_msg.t
Log:
force http scheme since ssl is not listening on this vhost port
Revision ChangesPath
1.3 +1 -0 modperl-2.0/t/filter/input_msg.t
Index: input_msg.t
===
RCS file: /home/cvs/modperl-2.0/t/filter/input_msg.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- input_msg.t 2001/08/12 19:02:24 1.2
+++ input_msg.t 2001/08/17 03:58:11 1.3
@@ -3,6 +3,7 @@
my $module = 'TestFilter::input_msg';
+Apache::TestRequest::scheme('http'); #force http for t/TEST -ssl
Apache::TestRequest::module($module);
my $config = Apache::TestConfig-thaw;
cvs commit: modperl-2.0/t/response/TestAPI aplog.pm
dougm 01/08/16 21:07:45
Modified:t/response/TestAPI aplog.pm
Log:
loglevel setting not working under t/TEST -ssl (not sure if this is a bug of feature)
Revision ChangesPath
1.6 +5 -1 modperl-2.0/t/response/TestAPI/aplog.pm
Index: aplog.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/aplog.pm,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- aplog.pm 2001/05/04 04:21:51 1.5
+++ aplog.pm 2001/08/17 04:07:45 1.6
@@ -50,7 +50,11 @@
$s-log_error('$s-log_error test ok');
$s-loglevel(Apache::LOG_INFO);
-$slog-debug(sub { die set loglevel no workie });
+
+if ($s-error_fname) {
+#XXX: does not work under t/TEST -ssl
+$slog-debug(sub { die set loglevel no workie });
+}
$s-loglevel(Apache::LOG_DEBUG);
$slog-debug(sub { ok 1; $package test done });
