Re: message type 0x49 arrived from server while idle
Hi there, On Fri, 19 Sep 2003, Tobias Kremer wrote: I have developed an application based on Apache 1.3.27, mod_perl 1.27, Postgres 7.3.2, Class::DBI 0.94 (utilizes Ima::DBI) on SuSE Linux 7.0 with a 2.4.20 kernel. The problem is that everytime more than one request at a time is made to the server I find the following error message in my logs and from then on apache seems to be stalled and is unable to process any further requests: message type 0x49 arrived from server while idle Nobody seems to have seen this error message before (I grep'd through my perl lib dir and found nothing). I think it's from Postgres, not Perl. Try Googling for message type arrived from server while idle It seems to have got something to do with many apache children accessing the postgres database I'm sure that's right, I think you're confusing Postgres somehow. There are suspicions about threads in some of the messages that Google found with the query above. I've never used Postgres so I wouldn't know where to point you, but have you checked the Postgres docs for that message? There are a few references such as this http://developer.postgresql.org/docs/pgsql/src/interfaces/libpq/fe-protocol3.c fairly late on in the Google results. The solution David and others found is not applicable to my problem because I'm already running apache 1.3.27 (not 1.3.28 which seems to be causing this trouble) I'm not sure I understand what you're saying here. At the beginning of your message it looked like you were using 1.3.27, not 1.3.28. Are you saying that the problem is present with a 1.3.27 Apache but not with 1.3.28? If so then could you not simply stay with 1.3.27? 73, Ged.
Re: Sleeping sessions
Hi there, On Wed, 17 Sep 2003, Andrey A. Kudrin wrote: I've compiled apache 1.3.28 + mod_perl 1.28 + mod_ssl 2.8.15. Before that all was ok, Before what? Before mod_ssl? Try it without. Have you checked in the documentation that the version of mod_ssl is suitable for your purposes? but at the moment all httpd session freezing in memory and turning to sleeping, 30-40 min and server is overloaded. You must send more information. Read the documentation on the mod_perl site to find out what you need to send. 73, Ged.
Re: upgrading to apache 2
Hello there, On Wed, 17 Sep 2003, Malka Cymbalista wrote: I am currently running apache 1.3.26 with mod_perl 1.36 and Perl 5.6.1 on my web server which is a Sun Solaris machine ... I would like to install Apache 2, mod_perl 2, and Perl 5.8. While Apache version 2 is stable, mod_perl version 2 is not yet. If you are prepared to accept some of the issues which arise during the early stages of software development then by all means try mod_perl version 2. If not, then stay with the latest version 1, which means you must also use a version 1 Apache. There have been several issues with Perl 5.8.0, and although I have had no problems with 5.8.0 on my own development boxes, in either case I would wait for Perl 5.8.1 before release into a user environment - and I would test that for a couple of months first. As far as I can tell Perl 5.6.1 is as good a release of Perl as any. 73, Ged.
Re: Summary: identifiying unique users
Hi all, On Tue, 16 Sep 2003, Frank Maas wrote: | How to avoid multiple logins? | | The short answer is: you can't. Sure you can. Charge $10 per login. 73, Ged.
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Have you benchmarked some simple things on the boxes? So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) 73, Ged.
Re: AIX perfomance
Hi there,
On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote:
Benchmarking simple CPU-intensive perl scripts shows that they
tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
GCC defaults to `-maix32'
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
73,
Ged.
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, William McCabe wrote: I've got a lot of experience with mod_perl on both linux and AIX and can state categorically that there are no typical conditions which would cause AIX run strangely slowly compared to linux on comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. Roughly what hardware setups do you generally work with, and what differences are notable between Linux and AIX when running mod_perl servers? (If that's not too long a piece of string to measure:). Are there situations where you'd prefer one or the other, if so why? 73, Ged.
RE: porting from mod_perl1 to mod_perl2
Hi there, On Sat, 6 Sep 2003, Bart Terryn wrote: Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Have you checked perldoc perllocale ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT]
Hi there, On Wed, 3 Sep 2003, kfr wrote: Anyone know how to capture the UUID from a request? What makes you think there'll be one in there? I've been looking all over the place and cant seem to find any reference to it anywhere ... Try Google? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT]
Hi there, On Wed, 3 Sep 2003, kfr wrote: had to re-compile my server with mod_ssl :) the hardware address is really what I'm after. What hardware? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: collecting unique client (computer) specific info? [OT][x-adr][x-bayes]
Hi there, On Wed, 3 Sep 2003, kfr wrote: http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt from section 3.5 ... I was assuming there was some way to parse and decrypt the mac address from: The following is an example of the string representation of a UUID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 the 00a0c91e6bf6 being the mac address of the computer. You don't even know there is a MAC address. And if there is, it can easily be spoofed. Forget it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi guys, On Thu, 28 Aug 2003, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 Have you mentioned this to Philippe Chiasson? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi Stas, On Fri, 29 Aug 2003, Stas Bekman wrote: Ged Haywood wrote: Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Wasn't he organising the release of mod_perl 1.28? If people are moving to a 1.3.28/1.28 combination, I would expect his mailbox to start filling up... 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
Hi there, On Fri, 29 Aug 2003, Stathy G. Touloumis wrote: should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
=?x-unknown?q?Re=3A_=5Bmp1=5D_Can=B4t_compile_mp1=2E28_-_work?==?x-unknown?q?ed_with_1=2E27?=
Hi there, On Wed, 27 Aug 2003, Bernd Kuhls wrote: I am trying to compile mod_perl-1.28 without luck. SUSE 5.3 (I know it´s old) gcc version 2.7.2.1 =:0 Perl-5.8.0, Apache-1.3.28 mod_perl-1.28 from source. With Apache-1.3.27 and mod_perl-1.27 I could compile using the same Perl-installation. You mean using Perl 5.8.0? ** Error: Cannot build mod_include with Perl support (USE_PERL_SSI) ** ** when mod_perl is compiled as DSO because of cross-module calls. ** ** Ignoring PERL_SSI flag now. ** Have you tried it without EVERYTHING=1? With 1.27 it worked with DSO, what has changed? Er, have you checked the CHANGELOG? Compiler: cc='cc', ccflags ='-I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-I/usr/include -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64' This doesn't look good at all. Try without LARGEFILE support? osname=linux, osvers=2.0.35, archname=i686-linux Does that say 2.0.35 or do I need new glasses? For all programs I used the same compiler and as I stated with the earlier versions compiling never was a problem. I'm surprised you got away with it for so long really. Your OS and compiler are very old. What version of the C libraries are you using? The link you mentioned does say that the error you get when building static is a symptom of a broken Perl. Did you run the Perl testsuite when you built your Perl, and if so what failed? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
Hi there, On Tue, 26 Aug 2003, Patrick West wrote: I've installed apache_1.3.27 and mod_perl-1.27. When I go to run the tests in mod_perl-1.27/t (just running the first one), first it complains that it couldn't start the server. But the server is actually running. Are you sure you have the right server running? Did you check that there were no httpd processes running before you started the test? You might want to check which ports 80, 8080, 8259... are being used as this might lead you to the answer. Have you checked the error_log files for the server(s)? Pay particular attention to dates and times, both when you give the commands to start servers, run tests etc. and also when you look in the log files. This may help you to understand what happened and when. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation problem
Hello there, On Mon, 25 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz and unarchive it to /usr/src/httpd_perl for back-end server then when I make perl Makefile.PL APACHE_SRC=../apache_1.3.28/src/ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS='- -prefix=/usr/local/httpd_perl' [snip] modules/psections...ok modules/request.Use of uninitialized value in numeric eq (==) at modules/request.t line 147. Use of uninitialized value in concatenation (.) at modules/request.t line 147. [snip] Can you tell us a bit more about your system? The documentation gives you information about what information you need to give... What compiler was used to build your Perl, and was it the same compiler that you used to build mod_perl and Apache? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Installation/test problems - mod_perl-1.27
Hi there On Tue, 26 Aug 2003, Patrick West wrote: Apparently $net::httpserver is set incorrectly, [snip] So ... where is $net::httpserver being set? t/net/config.pl 73, Ged. PS: Please keep it on the list... :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and staticfrontend
Hi there, On Wed, 27 Aug 2003, Charlie Garrison wrote: Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. It's not so hard. There's a skeleton module in the Apache sources for you to start with, take a look at it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1.0] Installation problem
Hi there, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: I've downloaded apache_1.3.28.tar.gz mod_perl-1.28.tar.gz [snip] tests failed: [snip] Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.16-22smp, archname=i386-linux Upgrade Perl (and your operating system?:). that might help, and version 5.6.0 of Perl is a disaster just waiting to happen anyway. You should be OK with 5.6.1 but I would think 5.8.1 might be better. [snip] Compiler: cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 2731 (ASPLinux 7.0 2.96-79) Please post the output of gcc -v on your system. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Re[2]: [mp1.0] Installation problem
Hello again, On Wed, 27 Aug 2003, Alan Rafagudinov wrote: GH Please post the output of GH gcc -v Reading specs from /usr/lib/gcc-lib/i386-asplinux-linux/2.96/specs gcc version 2.96 2731 (ASPLinux 7.1 2.96-85.asp) Make sure to use that compiler to build Perl, mod_perl and Apache. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hi there, On Sat, 16 Aug 2003, Cory 'G' Watson wrote: started flipping switches and localized it to PerlFreshRestart being on. Have you read http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Evil_things_might_happen_when_using_PerlFreshRestart When I turn it off, the eval() happens _before_ my startup.pl use() and subsequence call to App-load(). So is it working now? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hi there, On Fri, 15 Aug 2003, Cory 'G' Watson wrote: It looks as though this works during the first 'load' that Apache does, which I'm assuming is the phase that checks for errors. The second phase seems to cause my global hash to get undef'ed, even though the loadPages() method works properly. I'm not entirely convinced of the explanation, but have you tried testing the value of $Apache::Server::ReStarting in the code that fills the hash? It's in the Guide. Your message was a bit cavalier about what's a hash and what's a hashref, are you sure you aren't just missing a dereference somewhere? Have you got 'use strict' and warnings on? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hello again, On Fri, 15 Aug 2003, Cory 'G' Watson wrote: PerlVar app blah Perl App-loadApp(blah, /usr/local/blah/lib); /Perl [snip] Ignore syntax errors and lack of declarations, as I just threw that together from memory The guesswork would be a lot easier if it didn't involve so much guesswork. :) Have you read http://perl.apache.org/docs/1.0/guide/config.html#PerlSetVar_and_PerlAddVar and http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: mod perl issues/ cpan won't make properly
Hello again, On Tue, 5 Aug 2003, Hodge, Jeff F (ECIII) wrote: My directories look exactly like that. :) First I went to the apache directory and ran the configure to enable DSO. Do you have any particular reason for using DSO? IMHO it's usually more trouble than it's worth. I always build static if I can. Also I like a file 'makepl_arg.mod_perl' in the mod_perl source directory to supply the configuration. Sample attached. Then you just have to say perl Makefile.PL in the mod_perl directory and everything is set up for you. Then you can repeat it whenever you like: just remove the source directories, extract the sources fresh, copy the makepl_args.mod_perl file, and issue the perl Makefile.PL command again. How does root user affect things? People have had problems with permissions getting a little screwy, and it's safest to do builds as non-root in case there's an accident. I need Apache::request and DBD::mysql rsn Get Apache and mod_perl running first. There shouldn't be any problemn with the rest. I repeated my build/install steps interesting. its failing a test; output: (I'm fairly sure this wasn't the result the other day): Failed 1 test script out of 667, 99.85% okay. It could be worth following the instructions to try to pin that down. btw - what is 73? Morse code shorthand. Long time ago. It means best wishes. 73, Ged.
Re: [mp2] ModPerl::Test::read_post destructive?
Hi there, On Sun, 10 Aug 2003, Michael Maciag wrote: Is the read_post in ModPerl::Test destructive in some way? If so, could someone point me in the right direction I might take to modify it to be non-destructive? I think you'll find that reading POST data has always been destructive. If you want to read it more than once you have to save it somewhere. Check the archives for more information. 73, Ged.
Re: mod perl issues/ cpan won't make properly
Hello there, On Mon, 4 Aug 2003, Hodge, Jeff F (ECIII) wrote: Here's how I installed mod_perl/apache: cd apache_1.3.28 ./configure --enable-module=so cd mod_perl_1.28 I don't like the look of that. Please send *exactly* what you did. Have you got the mod_perl directory inside the apache directory? Your directories should be somethign like this: /dloads/apache_mod_perl/apache_1.3.28/ /dloads/apache_mod_perl/mod_perl-1.28/ perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl make make test make install What is the user that's running this? Don't do the first three steps as root, only do the 'make install' as root: % perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl % make % make test % su Password: # make install # exit % That backslash on the first line is important. If you've done everything as root and if you have the mod_perl directory inside the apache one, then it's best to remove the directories and start again. So using Cpan I tried to install the Bundle::Apache...which bombs out Don't worry about it for now, you don't need it for your mod_perl Apache. ALSO here is perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: [snip] ccversion='', gccversion='2.95.3 20010315 (SuSE)', [snip] gnulibc_version='2.2.5' [snip] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 2 2003 13:09:23 [snip] Looks like you compiled this Perl yourself using gcc 2.95.3 a couple of days ago, is that right? Did the Perl tests all pass OK? 73, Ged.
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: sorry to break the thread in two. :( Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: --- Ged Haywood [EMAIL PROTECTED] wrote: How did you do the perl Makefile.PL step? % cd /usr/src % tar xzvf apache_1.3.xx.tar.gz % tar xzvf mod_perl-1.xx.tar.gz % cd mod_perl-1.xx % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 So your non-root user has write permission in /usr/src? H... % make make test make install This can't work, you need to be root to make install. 73, Ged. PS: Did you build your own Perl? Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:).
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Rather than /usr/src, I put in /home/aprk That's fine. But in future, tell us what you did, not some fiction... :) Yes, you are correct. make make test as non-root, then install as root. (Odd, isn't it, the docs at http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation don't make this explicit?) Yes, I always think that, but many of the Open Source packages neglect to mention this point every time it might be mentioned. I think authors expect it to be either very obvious or else perhaps unnecessary - some operating systems don't have a Unix-like permisisons system. Did you build your own Perl? Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. Have you cleaned up any old Apaches and mod_perls? No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're happy that it's all as you wnt it, you might want to use chkconfig to set it up to start at boot again. I think my next step should be to start over fresh. Again. :) [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? [2] How do I uninstall everything from [1], so I can start fresh? Well RH should let you uninstall packages with rpm, but I don't use rpm and I tend to avoid RedHat so I don't know exactly how you'd do it. My preference would be to look in /usr/local/ and /var/lib to see if there are any apache things such as /usr/local/apache, and if so go in there as root and rm -rf the entire apache directory. That will perhaps throw away config files etc. you've been working on, you might want to make backups. When you've done that you might want to use slocate to build a database of filenames on your filesystem, then use it to search for any httpd or apachectl files that escaped. If so there'll probably be truckloads of files in there with them. Nukem. The source trees in your home directory don't matter. Nuke them too. You won't need to do anything about Perl on your system if you really did compile it from source yourself. [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. (Want my dev box to match the outside box as much as possible). This newsgroup keeps mentioning build from sources, will I be going astray trying the rpm route? I hate RPMs. For Apache2/modperl2 you would be better off going to the CVS sources unless you can get hold of a very recent RPM, things are changing really fast in the mod_perl version 2 codebase. True, it could be important for your dev box to match your prod box, but when you figure out what's going on it will probably matter less - until you start doing really fancy stuff, when it will start to matter again. [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. mysteries to a newcomer. FWIW you sound like you're picking it up quickly. 73, Ged.
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Exactly HOW do I change the locale? http://twiki.org/cgi-bin/view/Codev/UsingPerl58OnRedHat8 about half a dozen messages down. See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 make make install again, yes? Better start with % cd /home/directory/src (or whatever your home directory is) and then % rm -rf apache_1.3.28 % rm -rf mod_perl-1.28 % tar xzvf apache_1.3.28.tgz % tar xzvf mod_perl-1.28 % perl Makefile.PL and I would suggest that in future instead of % make make install that you do these steps as separate commands % make % make test % su Password: # make install # exit % which will give you the opportunity to abandon ship at any point before the install. Finally if you do % script before you start the 'perl Makefile.PL' step then everything you see on the screen will be logged to a file so you can peruse it later if you feel the need. It will help you to become familiar with build the process. It looks a lot more complicated than it is. Really. % man script for more details. I'd use 'less -S' to look at the scriptfile. In fact I always alias 'less -S' to 'li' in my login scripts... :) 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: To recap: I freshly installed RedHat 9 on a box, then used RPM to remove modules involving httpd. (See notes below). Then I built perl 5.8.0 from source, first doing a export LANG=C why not LANG=en_US ? Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, Oooohhh. Don't do that... We're getting out of my area of experience here, I don't use mod_perl2, but I hear there are recent changes to CGI.pm. Did you install the latest CGI.pm? You should. 73, Ged.
Re: MP1, Redhat 7.3: Transmission size limited after some time
Hi there, On Thu, 3 Jul 2003, Gerd Knops wrote: I got a really odd problem: I have identical mod_perl/apache installs on FreeBSD 3.x systems and a few Redhat 7.3 systems. After some time running OK, the Redhat systems start acting up. Transmissions are suddenly cut of after somewhere between 90 and 150 kb. [snip] Restarting the web server fixes it, but a few hours/days later the problem resurfaces. This makes me think perhaps you have MaxRequestsPerChild set to zero in your configuration? 73, Ged.
Re: DProf on Mac OS X
Hi there, On Fri, 25 Jul 2003, John Siracusa wrote: Has anyone gotten this to work on OS X? [snip] I've used this profiling technique on other Unix-like OSes, so I think I'm doing it right. I'm sure you're doing it right. But on OS X, I get a tiny tmon.out file that never grows after the initial server startup. I don't see any error messages or log lines. When I try to use Apache::DProf, I get a bus error on any request: [Fri Jul 25 18:52:48 2003] [notice] child pid 3840 exit signal Bus error (10) I've never tried it on OS X, but I had exactly the same problem when Perl 5.6 first came out. I didn't investigate further since the Perl development team were rather unhelpful about it. And about quite a lot of other things. With hindsight that might be understandable, they must have been taking a lot of flack about that time. The problem persisted until I upgraded to 5.7.2. Any way you can try it on a different OS, or even try a different Perl? And before Stas jumps on me *again* for saying that I have no evidence that 5.8.0 is the culprit in this case. It just smells fishy to me. :) 73, Ged.
Re: Advice sought for learning mod_perl (2 or 1)
Hello there, On Thu, 24 Jul 2003, Robert Lee wrote: I am new to Apache/mod_perl and everything else. We're all still learning... I bought a fairly good book on Apache/mysql/mod_perl. There are others, see the mod_perl web site: http://perl.apache.org Unfortunately, it is based on the Apache 1 server and mod_perl1. That's not too bad, there are lots of similarities. Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? Q2: Any real benefits to working on the latest and greatest? Or should I go to the older versions? Depends what you want to do... :) If you are interested in learning about it and you don't have a project that you have to put on a live Webserver in a couple of months' time, I'd say stay with mp2 and watch it evolve. Maybe get involved in some of the development. I wouldn't consider mp2 for production use yet because of that evolution process if for no other reason, but if you don't have the commercial pressures then it doesn't matter so much and there's no point your spending a lot of time learning about something if it's going to be more-or-less history by the time you need to use it seriously. I realize that for Q2, I may want to simply go with the more stable versions of the Apache server and mod_perl as I am just learning For your education it's probably worth your while learning how to get the latest CVS versions, at least of mod_perl. The latest versions of Apache2 and mod_perl2 will be quite stable enough for you to use to learn about them. Now your browsers on the other hand... 73, Ged.
Re: templating system opinions (axkit?) [OT]
Hi Matt, On Wed, 23 Jul 2003, Matt Sergeant wrote: The main reason I like AxKit is it prevents me from screwing up [snip] I just write straight perl code. I barely notice that I'm using XML. Can you give us in a couple of sentences your take on the state of XML in general and AxKit in particular? To me somehow things don't seem to be going in quite the same direction any more... 73, Ged.
Re: Help me understand mod_perl and Environment settings
Hi there, On Thu, 17 Jul 2003, Bernhard Donaubauer wrote: I just startet learning mod_perl and apache. I use the current version of mod_perl 1 and apache 1.3. Perl itself has version 6.5.1. Can you be a little more careful with your version numbers in future? but my testapplication does sometimes see my environment settings and sometimes not. It changes if I press the refresh button of the browser. Please see the mod_perl Guide at http://perl.apache.org There are references to the symptoms you see at http://perl.apache.org/docs/1.0/guide/debug.html#Sometimes_My_Script_Works__Sometimes_It_Does_Not 73, Ged.
Re: Virtual Host Logging Perl Script
Hi there, On Tue, 15 Jul 2003, Jez Hancock wrote: Does anyone how one could log errorlog entries in a similar manner to the script above - ie pipe the errorlog to a script which appends one copy of the error entry to a main error logfile and another copy to the virtual host's error logfile? It's possible, but I don't think you really want to do it. You would be asking the server to do more than is necessary while handling each request (you probably already are:). Would it not be better for example to rotate your logs frequently, and to process them afterwards, off-line? You would then have a choice of doing things with the various log file analysis tools too. If you are a little bit creative in what you log, it can be simple to extract the information you need for each vhost from one file. Have you considered using something other than flat files for logging? 73, Ged.
Re: perl5.8
Hi there, On Wed, 16 Jul 2003, Grant Cooper wrote: I was upgrading to perl5.8 using freeBSD To install via ports, I typed this : cd /usr/ports/lang/perl5.8 make install clean rehash use.perl port What does rehash do? And what does use.perl port do? This List is for questions related to mod_perl, not for general Perl questions. Please take your question to a more appropriate place, you will find one for example at http://lists.perl.org 73, Ged.
Re: Virtual Host Logging Perl Script
Hi Jez, On Wed, 16 Jul 2003, Jez Hancock wrote: [snip] We started looking at mod_log_sql: [snip] but had trouble getting it to work on FreeBSD unfortunately. I'd have thought something a bit lighter might do for this. Right now it seems a bit silly having a separate ErrorLog line in each of the apache virtual host stubs, but as far as I am aware there isn't an easier way is there? You could look at mod_macro. 73, Ged.
Re: must I use mod-perl
Hi there, On Sun, 13 Jul 2003, Dennis Stout wrote: I downloaded source for Apache, PHP, and mod_perl and compiled it all and had it working in about the time it took to download it + compile time + about 5 minutes. There is no config to mod_perl really. Either it's there or it isn't. True, it's very quick to install once you get the hang of it. But let's not _over_simplify: you _do_ have to tell Apache what URLs need to be handled by mod_perl or it will just take up RAM and not do anything... :) Once you have an Apache with mod_perl either (I would say preferably) compiled in, or (I would say as a last resort) available as a loadable module, all it takes to get mod_perl to do things for you is a simple configuration directive or two in httpd.conf or your favourite Apache configuration file. Plus your Perl scripts of course. It's all in the documentation. 73, Ged.
Re: must I use mod-perl
Hello there, On Sun, 13 Jul 2003, Bulba007 wrote: When must I to use mod_perl? It is necessary? No, it's not necessary. You may want to use mod_perl if you want to use Perl scripting with the Apache Web server. At the expense of some complexity, especially in the installation and configuration of your server, it can provide better performance and more control over the server than is possible with CGI scripting. There is a great deal of documentation available. See the mod_perl home page for more information: http://perl.apache.org Because mod_perl version 2 and the documentation for it are still works in progress, assuming that you are using Linux, at the moment I would advise you to consider only mod_perl 1.27 or 1.28 with Apache 1.3.27 if possible. 73, Ged.
RE: Dynamically banning hosts
Hi there, On Sat, 12 Jul 2003, Jesse Erlbaum wrote: Is it possible to dynamically ban IP addresses using mod_perl. Yes, it is possible with mod_perl. You can create a PerlAccessHandler In addition to Jesses's comments, I'd suggest that you might want to look at firewalling techniques to eliminate the requests before they ever reach your server. If your mod_perl server is doing the access denial, then there has already been a lot of processor activity wasted on the attack. Something like IPCop is freely available, easy to configure (if you avoid pitfalls with multiple Ethernet cards being shuffled:) and very effective. But there is no easy solution to a determined DOS attack on an open IP. 73, Ged.
Re: compile issue: conflicting types for getline
Hi there, On Thu, 10 Jul 2003, Stewart, Eric wrote: RedHat Linux 9.0, with Apache 1.3.27, PHP 4.3.2, and mod_perl 1.28, I'm getting a compile error. [snip] I'm thinking it's more along the lines of a compiler (IOW, RedHat's use of gcc 3.2.2) issue. It *might* be the compiler, but I doubt it. I think you might be running into RH9-related problems, I've had more than enough of them and I don't even use it on most of my mod_perl boxes... After I had troubles with 3.2.2 (nothing to do with mod_perl at all) I upgraded to 3.2.3 which solved the problems. I never tried to compile mod_perl with 3.2.2 but I've compiled mod_perl pre-releases (not 1.28 as released) using gcc 3.2.3 no trouble at all. This was on a system running Linux 2.5.69, gcc 3.2.3, glibc 2.3.1, perl 5.8.0, Apache 1.3.27 but no PHP. I'd rather like to avoid downgrading either my OS or compiler. Don't do that. You might want to try upgrading gcc to 3.2.3, cleaning up your installation and recompiling everything, including Perl. If it works that will be useful information, please let me know. 73, Ged.
Re: Newbie question about mod_perl capabilities
Hi there, On 8 Jul 2003, Walter H. van Holst wrote: On Tue, 2003-07-08 at 10:14, Matt Sergeant wrote: Sorry Ged, Walter is talking about CONNECT which is a proxy request. Argh. :) Well, thanks to a someone on IRC I have found a code snippet that might do exactly that. So it appears that mod_perl can do this. And yes, it is intended for exactly the kind of CONNECT requests you describe. :) 73, Ged.
Re: ProxyPass not getting type of dynamic images?
Hi there, On Mon, 7 Jul 2003, Kirk Bowe wrote: ProxyPass / http://other.server.with.specified.port.com:8082/ ProxyPassReverse / http://other.server.with.specified.port.com:8082/ ProxyReceiveBufferSize 16384 Most of it works fine but I appear to be losing content types. Is it something mod_proxy is doing? If you look in apache_1.3.27/src/modules/proxy/proxy_util.c at the function ap_proxy_read_headers() you may find something. You could add some logging. 73, Ged.
Re: Newbie question about mod_perl capabilities
Hi there, On 7 Jul 2003, Walter H. van Holst wrote: I am new to mod_perl and am trying to figure out whether it suits my needs or not. Can I use it to intercept any http CONNECT requests Apache receives and answer those? The concept of a connection is at the transport level, way below HTTP. The HTTP protocol simply assumes a reliable transport (you don't even need an Internet:) and deals with exchanges of messages. See RFC1945. Read the Eagle Book (*), for more information about where mod_perl fits into the scheme of things. Chapter 3 has a good explanation of the Apache request cycle. 73, Ged. (*) Writing Apache Modules with Perl and C, ISBN 1-56592-567-X
Re: Flushing
Hello there, On Sun, 6 Jul 2003, Oskar wrote: I have script that is doing some time consuming operations This has been discussed many times on the List, check the archives. 73, Ged.
Re: If (!$one_thing) {$other;}
Hi there, On Wed, 2 Jul 2003, Dennis Stout wrote: This also means I can write a small subroutine to eval a form that's been posted, and given the authentication passes, add code to the thing while it's running, AND save the code to the DB so it'll be around for reboots. Wouldn't that just be awesome? Can I urge a little caution? 73, Ged.
Re: Is statically-compiled mod_perl better?
Hi there, On Thu, 3 Jul 2003, ColinB wrote: What is the preferred method of compiling mod_perl - static or dynamic? Static. (But that's just my opinion after years of experience and watching people running into trouble with DSO mod_perl on this List. :) I have read that *static* linking is likely to load and execute faster, but may be wasteful of resources if there are multiple proceses each with its own copy of the common code. In normal circumstances the speed of loading is unlikely to be an issue. If you're using mod_perl 1.x on Linux/Unix/whatever then unless you're using 'httpd -X' or a very strange configuration there will be multiple processes. A recent post by Randal seemed to indicate the memory saved by using a DSO mod_perl wasn't as large as one might think - check the archives. It therefore seems likely that a statically compiled mod_perl would be faster, provided that a large number of httpd's are not being run at the same time. Is this correct? There are many factors to consider, but the speed difference between static and DSO isn't often talked about here so you can draw your own conclusions. Check out the tuning section of the Guide, the archives. It seems that at present it is not possible to build mod_perl 2.0 statically. It can only be built dynamically and loaded using LoadModule in httpd.conf. This seems strange if the preferred method of building is static. True. That's because it's still in development. Check the archives... 73, Ged.
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Dennis Stout wrote: I made a simple mod_perl change to the config and when restarting Apache I got this error: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:2250 no listening sockets available, shutting down /usr/local/apache/bin/apachectl: line 87: 16512 Segmentation fault $HTTPD $ARGV I then backed out the change and retried, got the same error. killall httpd then try it again :) In other words there's an Apache still running when you're trying to start a second one which wants to listen on the same socket that the first Apache is already listening on. That isn't permitted. But you shouldn't be getting segmentation faults in that case so something else is probably wrong too. Did you build from source? Did you follow the instructions in the Guide? Linux? 1.3.27/1.27? DSO? Maybe you can post the information requested in the docs? 73, Ged.
Re: Apache config problem .. please help
Hi there, On Thu, 3 Jul 2003, Ranga Nathan wrote: In other words there's an Apache still running The 'top' output is : [snip] How can I get a list of ports being used so I can kill the processes? As I said, there may be more wrong than just what's obvious. It looks like the obvious explanation that another Apache is running is not the right one. At the risk of asking questions I wouldn't have to ask if you'd posted the information I asked for, why port 2205? That's not what I'd expect to see, but without more information I'm groping about in the dark. What's trying to use that port? MySQL perhaps? Why not stop it first, or change the port that Apache is trying to use, or the port that whatever apachectl is trying to start is trying to use, or... As far as I can tell httpd is not running. The IP is 208.179.25.28 c2h5oh:~$ ping 208.179.25.28 PING 208.179.25.28 (208.179.25.28): 56 data bytes 64 bytes from 208.179.25.28: icmp_seq=0 ttl=236 time=389.6 ms --- 208.179.25.28 ping statistics --- 2 packets transmitted, 1 packets received, 50% packet loss round-trip min/avg/max = 389.6/389.6/389.6 ms c2h5oh:~$ telnet 208.179.25.28 80 Trying 208.179.25.28... telnet: Unable to connect to remote host: Connection refused Looks like you're right. Have you read the stuff I mentioned? I dont see any apparent signs of hacking either. Don't go tilting at windmills just yet. :) 73, Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
Under command line and CGI it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
Apache - with so, unique_id, no expat
mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
--
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool-start;
poolFinish(pool);
return s;
}
--
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: There's nothing else in that function that would be likely to cause the fault, if pool were invalid I'd expect it to happen in poolAppendChar(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: How big are your Apache kids?
Hi there, On Mon, 30 Jun 2003, Nigel Hamilton wrote: I recently managed to get the RAM consumption of my server under control. :) Does anyone have a really lean and mean mod_perl, Apache configuration On the face of it 20Mb looks a bit heavy for mod_perl processes. But it depends so much on what you're doing with them that it really makes no sense to generalize, except for things you already know like not loading modules you don't need. You've probably already checked the tuning section of the Guide for tips, and trawled through the archives for discussions on the subject (of which there have been many:). If you can consider a proxy setup it may be that you can trade off complexity in your configuration against your RAM consumption, but first I'd be asking is it necessary? Only you can answer that one, and in any case RAM is a lot cheaper than software development. 73, Ged.
Re: A::Registry vs. mod_perl handler philosophy
Hi there, On Fri, 20 Jun 2003, Peter B. Ensch wrote: I'm beginning to develop apps under mod_perl. I'm curious as to how people decide between coding for Apache::Registry vs. mod_perl handlers. Use Apache::Registry only if you have to in order to get legacy CGI scripts working. It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. All new code should use handlers. 73, Ged.
Re: A::Registry vs. mod_perl handler philosophy
Hi Ken, On Fri, 20 Jun 2003, Ken Y. Clark wrote: On Fri, 20 Jun 2003, Ged Haywood wrote: All new code should use handlers. I wouldn't be so strict about such definitions. I didn't say must. :) Or am I missing something? You will get better performance from handlers and you can do more with them. I wouldn't deliberately build unnecessary limitations into a new system if I had any choice in the matter. Whatever works for you, I say. But mayhap I'm too permissive. Well I'm probably not permissive enough... :) 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Thu, 19 Jun 2003 [EMAIL PROTECTED] wrote: My question now is, did Doug take this into consideration when he build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) I'm sure Doug took into consideration all sorts of things we never even thought about. Try it out and let us know what happens? I think I need someone with 'inside information' into mod_perl Well you have the source code... :) 73, Ged.
Re: mod_perl slower than expected? - Test Code!
Hi there, On Wed, 18 Jun 2003, Trevor Phillips wrote: Whether it's i686 or i386 - both mod_perl and FastCGI are using the same compile of perl - so what difference should there be? Must have got my wires crossed somewhere - I thought you must be using different Perls. 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. I really don't see why you don't recompile your Perl. It's not a big deal and it's going to be a lot safer that way. Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. I can't tell you how much what you're proposing to do worries me. I wouldn't dream of doing it on one of my servers, not even on a development machine. The size of the files you access isn't the issue. It's the size of the variables in the C data structures. If different parts of the same code disagree about that, and they pass each other pointers to different shaped structures, you are going to have serious problems. As Stas said, the *best* you can hope for is an immediate crash of some sort. It's possibile however that the problems might not surface immediately and that the symptoms might not be obvious. You could have all kinds of data corruption before you know what's hit you. 73, Ged.
Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev
Hi Stas, On Wed, 18 Jun 2003, Stas Bekman wrote: Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Neat! 73, Ged. Script started on Wed Jun 18 13:29:03 2003 hurricane:~/src/Apache-Test-1.03-dev$ t/TEST -times=10 -order=random *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -times=10 -order=random /usr/local/apache/bin/httpd -X -d /home/ged_demountable/src/Apache-Test-1.03-dev/t -f /home/ged_demountable/src/Apache-Test-1.03-dev/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost:8529 started *** Using random number seed: 894127215 (autogenerated) [snip] All tests successful. Files=20, Tests=120, 10 wallclock secs ( 7.25 cusr + 1.44 csys = 8.69 CPU) *** server localhost:8529 shutdown hurricane:~/src/Apache-Test-1.03-dev$ Script done on Wed Jun 18 13:29:26 2003
Re: mod_perl slower than expected?
Hi there, On Tue, 17 Jun 2003, Trevor Phillips wrote: [snip] The speed problem is not a connect time problem - it's actual run-time of the Perl code. [snip] The only common thing between all the systems with the problem is they're using the i686 Debian package for mod_perl. Do you know for sure that the Per was compiled for i686? Maybe it was compiled for i386, so it would run on just about anything but it can't use a lot of the faster features found in later processors. I'd always compile my own executables, if only so I know what's in there. 73, Ged.
Re: mod_perl on Solaris notes..
Hi there, On Mon, 16 Jun 2003, Ryan Dietrich wrote: mod_perl on Solaris Thanks for the tips! things ended up being ridiculously stable (they haven't rebooted since last February I'm told).. Hehe: www2:~$ top -bn1 | head 9:57am up 421 days, 19:57, 1 user, load average: 0.03, 0.10, 0.08 134 processes: 131 sleeping, 1 running, 0 zombie, 2 stopped CPU states: 0.0% user, 0.1% system, 0.0% nice, 0.0% idle Mem: 971560K av, 452444K used, 519116K free, 105828K shrd, 101196K buff Swap: 1044184K av,1032K used, 1043152K free 64372K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 9912 ged 11 0 916 916 652 R 0 34.9 0.0 0:01 top :) 73, Ged.
Re: each considered harmful?
Hi guys,
On Mon, 16 Jun 2003, Stas Bekman wrote:
[snip,snip]
keys %hash;
does the trick
interesting that I don't remember this issue being reported earlier.
Probably because we all read the Camel Book, section 5.4.3, the bit
about FIRSTKEY. All except Randal that is... :)
Most people when iterating over a hash will say something like
foreach $scalar_name ( keys %hash_name ) { ... }
which automatically resets the iterator and is safe in a perisitent
Perl environment like mod_perl. I hope.
73,
Ged.
Re: Sharing memory between children
Hi there, On 16 Jun 2003, Clinton Gormley wrote: I had a look at the memory usage of my apache/mod_perl 1 processes, and was alarmed to find that only 3Mb of 25Mb processes was being shared (and that's straight after startup) I see about the same on my own server when processes get bloated, but I don't let the processes live to serve large numbers of requests so eventually they're killed off and replaced with new, smaller children. Generally about 25% of the processes are big ones, the rest staying around their initial size, but that's just the way things happen on this server, and it's not especially busy - it runs about half a dozen virtual hosts. Just in case, I put in a lot more RAM than I thought I needed. Of course with a completely different set of (Perl) software and operating conditions, there's no reason why your experience should be anything like this. When I load nothing, the size of my processes starts at 4204 (2504 Sounds a little on the high side, but not outrageous. You're putting quite a lot of stuff into your httpd, do you really need it all? Am I being really dumb here? I don't think so. If it's a problem for your machines you might want to consider a light proxy front end + mod_perl backend. It's easy to set up. A lot depends on the amount and type of traffic that you're going to see. If everything is dynamic HTML you might not gain much, but if there's a lot of static content you might gain a lot. Every site is different - even if they're on the same machine. 73, Ged.
Re: Current stable platform for mod_perl application ?
Hi there, On Mon, 16 Jun 2003, Mithun Bhattacharya wrote: I have a choice between the very well tested 7.3 but highly likely to become unsupported by RedHat soon. Or I could go for RedHat 9.0 A distribution is just a package of stuff that you could put together yourself if you had the time and energy. Generally it includes an enormous mountain of stuff you neither need nor want, but it has to have frills, bells and whistles to compete. For a mod_perl server all you need is a decent kernel, networking support, a shell and tools to build the server(s) e.g. an editor, a C compiler suite and Perl. You can add all kinds of goodies like mail, ftp and name servers but that isn't what we're talking about here. The less you have in there, the less there is to go wrong and the fewer holes there are in it. Even having a C compiler on the machine is an added security risk. Do you actually need or use RH support? I'm not saying that there's anything wrong with it, but by the time you've a few years of Linux experience under your belt it's unlikely you'll need much more than the odd security patch - and you'll be able to deal with that sort of thing easily, even if it means installing a new kernel. I'd say stick with what you know. I tried RH9.0 on internal servers: I found so many things broke it was hardly worth the effort, except for the machine on our receptionist's desk which needs a nice GUI for her word processing stuff (even if it's less reliable than I'd like). Having said that, I had as much trouble with the latest Slackware distro. Things have changed a lot in a couple of years, so I think you either need to keep regularly up to date or else only do it when it's forced on you. I belong to the inertial navigation group. Must be my age. Also does the Native Posix Thread Library support in RedHat 9.0 have any added benifit for mod_perl/my applications ? I've no idea, but that's all a bit new and exciting for me anyway... :) 73, Ged.
Re: Sharing memory between children
Hi There, On 16 Jun 2003, Clinton Gormley wrote: On Mon, 2003-06-16 at 13:03, Ged Haywood wrote: I had a look at the memory usage of my apache/mod_perl 1 processes, and was alarmed to find that only 3Mb of 25Mb processes was being shared (and that's straight after startup) But this is happening right at startup... before any bloating. Maybe there are lots of variables in your code that are different for each different process. Do you use the process ID for example? I wouldn't get too excited about it until you see how your servers behave in actual use. I shouldn't be a bit surprised if you find that suddenly there are lots of things that seem to be more important... 73, Ged.
Re: Current stable platform for mod_perl application ?
Hi there, On Mon, 16 Jun 2003, Mithun Bhattacharya wrote: [snip] RedHat 7.3 has the notorious gcc 2.96 - no body has been able to figure out whether it is actually broken or not I guess :). [snip] Whether it's broken or not it was never released, it escaped. :) The developers called it a development release, not to be used in production: http://gcc.gnu.org/gcc-2.96.html Until recently I used gcc 2.95 and I had next to no trouble with it, compiling certainly many hundreds (perhaps thousands, didn't count) of all kinds of packages, including almost all versions of Apache, Perl and mod_perl since mid-1999 i.e. (if memory serves) Apache 1.2.19, mod_perl 1.19 and Perl 5.005_03. To my mind there are more programmers in this world than there should be who don't mind warnings in compiler output, but if you have a fussy compiler you'll expect to see the odd warning amongst the slew of messages you get when you build something. Apache, Perl and mod_perl are better than many in this respect. Recently I started to use gcc 3.2 although I never used it to compile mod_perl. I had a few problems with gcc 3.2 - I was mostly compiling kernels and kernel modules - so I upgraded to 3.2.3 which has given me very good service so far. Slower than 2.95 :( but just as fussy. :) It's a real slog to buid the compiler and support stuff on an old system, if you're thinking of doing it I'd advise getting a recent distribution which has at least gcc version 3.0 already in there. Changing libraries can be just as traumatic as changing compilers. I'm using glibc 2.3.1 at present. I've used gcc 3.2.3 to compile Apache 1.3.23 and the latest mod_perl versions (1.27 and the candidate for 1.28), with no problems at all. Using 3.2.3 as yet I've only built Apache with statically linked modules, and that's unlikely to change unless someone offers money. Since the last guy who did that never paid, it would probably need to be cash in advance. (You know who you are... :) 73, Ged.
Re: How practical is that Practical mod_perl?
Hi Slava, On Sat, 14 Jun 2003, Slava Bizyayev wrote: So, what it looks like? http://groups.yahoo.com/group/modperl/message/34174 Looks like a moment of truth. Yup. :) 73, Ged.
Re: problem building libapreq on Solaris
Hi there, On Fri, 13 Jun 2003, Xavier Noria wrote: Hello, I've just compiled Apache 1.3.27 with mod_perl 1.27 from their tarballs on Solaris. perl is 5.8.0 packaged for Solaris. The installation of libapreq with cpan(1) stops here: [snip] t/httpd -f `pwd`/t/httpd.conf /bin/sh: t/httpd: not found [snip] Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, Don't know if there's anyone who actually knows what's going on here but I thought you'd just like to hear from somebody. :) This is a wild stab in the dark. Guessing that the libapreq installation scripts are assuming that you're building a new Apache/mod_perl, you might in that case be expected to have a copy of the a httpd in the t directory. When you run 'make test' during an Apache build that's where the binary will be, temporarily. You could try a soft link from there to the real httpd - I have no idea if something else will then fail. You know that your mod_perl and your Perl should really be compiled with the same compiler? I always think it's best to build it yourself to be sure. 73, Ged.
Re: How practical is that Practical mod_perl?
Hi all, On Fri, 13 Jun 2003, Slava Bizyayev wrote: We should together refrain from doing mistakes (at least publicly). It is unrealistic (and perhaps a little Oriental?) to refuse to accept that we make mistakes, and that we will continue to make them. It is far more constructive to prepare for them - usually one would try to minimise their impact; to acknowledge them, and if necessary to own up to them :) when they are made; and to take whatever corrective action might be called for in a timely fashion. In all the above, for several years Stas has set us a fine example. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... I don't know if I fully understand what you're saying here. When, here on this List and on numerous occasions, Stas begged us for reviews of the text of his book, did you respond? Many of us did. If we missed some mistakes we will all share the blame and I for one am quite happy with that. Let's call an end to this. 73, Ged.
Re: [mp1] 1.28 release candidate #1
Hi there, On 9 Jun 2003, Philippe M. Chiasson wrote: Finally, the first mod_perl 1.28 release candidate #1 has arrived. [snip] Please give this release a spin Linux 2.5.69, gcc 3.2.3, glibc 2.3.1, perl 5.8.0; 1300MHz Duron (x86). All tests successful, 6 tests skipped. Files=34, Tests=400, 13 wallclock secs ( 7.88 cusr + 1.60 csys = 9.48 CPU) No problems at all. 73, Ged.
Re: static linking vs DSO linking
Hi Randal, On 11 Jun 2003, Randal L. Schwartz wrote: Am I crazy for suggesting that DSO doesn't really gain you much...? 'Sfunny you should say that... Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? Never had to worry about it a great deal, I usually just throw RAM or boxes at it. Maybe you could have a look at Squid or something? 73, Ged. -- On Tue, 10 Jun 2003, Ged Haywood wrote: On Tue, 10 Jun 2003, Forrest Aldrich wrote: I wonder if this will affect anything else, especially other things that require DSO support. ? Have you got the Eagle Book? You need --enable-module=so in your configure arguments to put mod_so into Apache, mod_so allows Apache to load shared objects. What does --enable-shared=max imply to Apache... make as much as possible as shared objects, the idea being to make the resulting binary smaller. It won't save any memory if you run it with tons of modules loaded, so it's probably more trouble than it's worth. Which is my opinion of DSO generally. I always build static if I can.
Re: Compling mod_perl as a static module....
Hi Forrest, On Tue, 10 Jun 2003, Forrest Aldrich wrote: seems to have worked [snip] # /usr/apache/bin/httpd -l Compiled-in modules: http_core.c mod_so.c mod_dosevasive.c mod_perl.c [snip] :) building mod_perl is such a pain [snip] thoughts on this one? It isn't usually such a pain. Without getting an account on the box or looking at the entire build process it's difficult to see why you've had such trouble. You do seem to be putting a lot of stuff in there, and I wonder if it wouldn't have been simpler to start with a very cut-down configuration. Well, no matter, you have a statically linked mod_perl now. Can I suggest that you create another account on the box and rebuild httpd from scratch in exactly the same way to make sure you have all the information you need to repeat it? I of course still need to test mod_perl with something - Did you not run 'make test' ? will try my go at installing RT or something simple (open to suggestions). Lynx? Telnet? What are you going to use mod_perl for? 73, Ged.
Re: Compling mod_perl as a static module....
Hi there, On Tue, 10 Jun 2003, Forrest Aldrich wrote: I wonder if this will affect anything else, especially other things that require DSO support. ? Have you got the Eagle Book? You need --enable-module=so in your configure arguments to put mod_so into Apache, mod_so allows Apache to load shared objects. What does --enable-shared=max imply to Apache... make as much as possible as shared objects, the idea being to make the resulting binary smaller. It won't save any memory if you run it with tons of modules loaded, so it's probably more trouble than it's worth. Which is my opinion of DSO generally. I always build static if I can. On your EXPAT question, I'm not sure what you found is relevant. You might want to check the List archives for discussions about EXPAT, not so long ago it seemed to come up quite a lot. 73, Ged.
Re: Compling mod_perl as a static module....
Hi there, On Sun, 8 Jun 2003, Forrest Aldrich wrote: I want to try compiling mod_perl statically What's the question? 73, Ged.
Re: Fw: [Perl] HTML::Mason help anyone?
Hi there, On Mon, 9 Jun 2003, Issac Goldstand wrote: Forwarded from the Israeli Perl Mongers mailing list: - Original Message - From: Ron [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 09, 2003 1:48 PM Subject: [Perl] HTML::Mason help anyone? I have a simple form [snip] The problem is that I only see the values printed when I use the GET option in the form above, when I change GET to POST nothing gets printed... POST data can only be read once, if you want to read it again you have to save it somewhere. It looks to me like before you try to read it, it's being read by something else and therefore lost to you. This question seems to crop up quite a lot (if this is the right answer:) 73, Ged.
Re: Compling mod_perl as a static module....
Hello again, On Mon, 9 Jun 2003, Forrest Aldrich wrote: Referring back to my original post, it with the options I specified, the compile process still insists on compiling mod_perl as a DSO. Even if I explicitly set USE_DSO=0 -- I wonder if one of the other flags (like EVERYTHING=1) is triggering the DSO compile. No, I often compile statically with EVERYTHING=1. I don't think we're dealing with a full deck here. Are you quite sure that you're looking at the right executable after you build it? Check the timestamp. Try running it by giving the full pathname and the -l switch for example /home/forrest/src/apache_1.3.27/src/httpd -l or change to the directory that the exewcutable is in and say ./httpd -l (you can do both without being root) and see if the output includes a line mod_perl.c which tells you that mod_perl is compiled in (i.e. compiled statically). 73, Ged.
Re: Compiling mod_perl as a static module....
Subject: Returned mail: see transcript for details The original message was received at Sun, 8 Jun 2003 23:22:26 +0100 from IDENT:[EMAIL PROTECTED] [212.22.195.7] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 553 5.3.0 Zone rejected due to abuse.) - Transcript of session follows - ... while talking to forrie.com.: MAIL From:[EMAIL PROTECTED] 553 5.3.0 Zone rejected due to abuse. == Hi there, As you can see mail from me doesn't reach you directly. What's this abuse? On Sun, 8 Jun 2003, Forrest Aldrich wrote: I'm finally getting down to trying this out, per your directions. As I recall I have already asked you to keep your messages on the List. Please read http://perl.apache.org/maillist/email-etiquette.html 73, Ged.
Re: How tell what version of mod_perl is installed?
Hi there, On 5 Jun 2003, Dennis G. Allard wrote: Hmmm. No one has actually answered the question, although I am getting all kinds of advice... (-; ... It's been good advice. If the question to which you refer is the one in the subject line, then one answer is look in the error log. Apache tells you when it starts. It's generally about the first thing it says. Your error log is defined in your Apache configuration file (probably httpd.conf) in a line that starts ErrorLog You could also take a look at http://perl.apache.org/docs/2.0/user/intro/start_fast.html which has an example of the output in the error log from a server when it's started. If your question isn't the one in the subject line, please accept my apologies - I haven't been following this thread closely. Feel free to ask it again if it hasn't yet been answered. There's more FM to R if you work with Apache/mod_perl 1.x - if you're going to be doing a lot of work for a commercial application and you don't want to be involved in the mod_perl 2.x development, and you're going to want lots more people around to hold your hand, then that's what I'd recommend. There are good books too. Buy them. Read them. You're an exceptional individual if you can absorb it all the first time through, so read them again. Oh, heck. More advice. 73, Ged.
RE: Trouble with Apache::Request
Hi there, On 6 Jun 2003, K Old wrote: No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works Want to run that by me again?? I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. Is it *exactly* the same error? Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. [snip] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ for module Apache::Request: libapreq.so.1: cannot open shared object file: \ No such file or directory [snip] Is there in fact no such file or directory? I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. 73, Ged.
Re: [mp2] make test fails to start httpd
Hi there, On Wed, 4 Jun 2003, Dave wrote: I am having the exact same test failure results on openbsd Did you build the Perl on that machine? If not, it might be worth a shot. 73, Ged.
Re: modperl 2.0: apache crashes when running modperl script
Hi guys, On Mon, 2 Jun 2003, Stas Bekman wrote: Sun Jun 01 18:51:42 2003] [notice] Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.46 OpenSSL/0.9.6b http://www.openssl.org/news/secadv_20030219.txt 73, Ged.
Re: Apache, Mod_PERL, and PERL
Hi there, On Sat, 31 May 2003, Ryan Farrington wrote: It was my assumption that apache allowed for the perl executable to be loaded into memory and called from then on without having to worry about creating the external process Well that sort of sounds right, but instead of making assumptions, why not read the Guide? You'll find it at http://perl.apache.org There's quite a lot to read (but around here we don't consider that to be an excuse for not reading it. :) (ISAPI I think is what the reference said). I have no idea what you're talking about. Can you at least read enough to be able to tell us what it is you've got there and what you've read that you don't understand? It will help us to help you if you tell us things like which operating system, versions of Apache and mod_perl, how you've configured them, what Perl modules you're trying to use, what your scripts are supposed to do... When I touch a .pl from the web the perl executable runs =( What else would you want it to do? 73, Ged.
Re: Help with Apache::httpd_conf
Hi there, On Thu, 29 May 2003, Shashank Kailash Shringi wrote: I need one common entry for handlers in Location directive, both inside and outside virtual host. I'm not sure I understand your problem, but I wonder if it's the sort of thing that mod_macro could help you with? 73, Ged.
Re: how to secure perl modules?
Hi there, On Thu, 29 May 2003, Kirk Rogers wrote: i have a collection of perl modules ... i dont want to send it out without at least making it somewhat difficult for some hacker to just simply steal it and load it somewhere else without my consent. This is getting to be an old chestnut, I wonder if we should specifically forbid discussion of it in the email-etiquette doc.? The best way to do what you want is to code it in C, compile it and send out only the compiled executables, a bit like that firm up in the North-West USA. There are -ahem- Open Source packages to translate Perl into C and/or bytecode, but then I suppose you wouldn't get much help from this List with C programs... It does seem a bit rich to take all the free stuff you can from CPAN and then try to deny everyone else the fruits of your own labours. But I suppose it's a free world, at least in parts. 73, Ged.
Re: libapreq-1.1 SEGV's on AIX
Hi there, On Thu, 29 May 2003, Steven M. Carter wrote: There's a thread here: http://www.geocrawler.com/archives/3/182/2000/2/0/3376687/ in which Doug MacEachern says: I don`t expect libapreq (or any of the Apache:: xs modules outside of the mod_perl dist) to work under aix. it needs to point at the apache and mod_perl .exp files to link properly. I don`t have access to an aix box at the moment, maybe one of our aix experts can help here? a patch to Apache::src would be ideal so all the Apache:: xs modules on cpan can use it. the Apache:: xs modules that ship with mod_perl don`t have this problem because they are all linked static by default. I have no idea if anything ever came of this. HTH 73, Ged.
Re: Help: Problems compling mod_perl-1.x-dev on FreeBSD-4.8
Hi there, On Fri, 30 May 2003, Forrest Aldrich wrote: how do you add/activate other modules to apache in this manner. Here's one I prepared earlier. Use caution, this is an old one and I haven't tested it lately. The documentation is in the Eagle Book, I don't know if it's in the CookBook, my copy is distant. Geoff might tell us. 73, Ged. -- USE_APACI=1 APACHE_PREFIX=/usr/local APACHE_SRC=../apache_1.3.22/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--sbindir=/usr/local/sbin/httpd_perl APACI_ARGS=--sysconfdir=/usr/local/apache/httpd_perl/conf APACI_ARGS=--runtimedir=/usr/local/apache/httpd_perl/run APACI_ARGS=--logfiledir=/usr/local/apache/httpd_perl/logs APACI_ARGS=--localstatedir=/usr/local/apache/httpd_perl/stat APACI_ARGS=--proxycachedir=/usr/local/apache/httpd_perl/proxy APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=include APACI_ARGS=--enable-module=info APACI_ARGS=--enable-module=usertrack --
Re: Problem with make test and libapreq 1.1
Hi there, On Wed, 28 May 2003, Angie Ahl wrote: I'm having a problem getting past the maketest stage installing libapreq-1.1 (to get Apache::Request), Apache 1 and Mod_Perl 1 If that's all that's holding up the installation, you'd probably get away with installing manually and not doing the tests (any of them:). I wouldn't normally recommend it - I'd want to fix the tests - but you probably want to get something happening, and fixing things first could be a little frustrating. OTOH this might be a symptom of something more serious... 73, Ged.
Re: Large Data Set In Mod_Perl
Hi there, On Wed, 28 May 2003, Perrin Harkins wrote: simran wrote: [snip] * Lookup the _distance_ for the planet _mercury_ on the date _1900-01-01_ [snip] you can get by with MLDBM or something similar. You might also want to investigate using a compiled C Btree library which could be tuned specifically to your dataset. Hard work. [snip] perhaps something such as copying the whole 800,000 rows to memory [snip] That would be the fastest by far, but it will use a boatload of RAM. To economise on memory you could compress the data (or part of it) before storage/lookup using a fast compress/decompress algorithm. There would be a tradeoff between memory consumption and processor cycles of course. That kind of thing can get a bit complicated... :) 73, Ged.
Re: Handler called second time acts up.
Hi there, On Thu, 29 May 2003, Igor Rojdestvenski wrote: designed a mod_perl handler moduel [snip] works fine first time, but when I refresh it, it works differently. [snip] My theory is that something is wrong with local/global variables [snip] Check out the mod_perl Guide - you can find it on the mod_perl website, http://perl.apache.org The guide contains a wealth of information about this kind of thing. See in particular the sections about mod_perl traps, debugging, and Sometimes it works, sometimes it doesn't... 73, Ged.
Re: Problems compiling modperl
On Thu, 27 Mar 2003, Johnson, Fred wrote: I haven't been successful building mod_perl with apache, and apacheSSL on a Solaris 2.8 with the latest recommended patches. I am working on a Solaris 2.8 machine, with gcc 2.95.3, perl v5.6.1, mod_perl-1.26, apache_1.3.22, and finally, apache_1.3.22+ssl_1.45. Is there a reason for using those old versions? I think you should be using Apache 1.3.27 and mod_perl 1.27, and probably Perl 5.8.0. [notice] Destruction-DESTROY called for $global_object /tmp: Permission denied It's not just a permissions problem? Building on Solaris hasn't always been the most straightforward of exercises. SSL might add a little excitement. If you trawl around in the archives you should find people who've done it on 2.8. I'm afraid I don't know anything about that particular ssl version. If that's the problem you might try a different way of getting ssl in the mix. 73, Ged.
Re: Server questions
Hi there, On Fri, 7 Mar 2003, Michael Hyman wrote: I am not familiar with clustering Would you run a mod_perl based web site on a cluster? If the performance and the money for the hardware are issues then perhaps before you buy you should spend some time looking into things like alternative system architectures, software packages, development methods, timescales and *those* costs... There's a lot more to it than what's the fastest machine. Apache isn't the fastest Web server on the planet and coding it in Perl isn't the fastest way of implementing an algorithm. Asking for data from Oracle won't usually be the fastest way to get hold of it - especially if the machine running Oracle is remote. On the same hardware, you might get ten times the performance from a well-tuned proxy server setup than you can from a single mod_perl server. And you might not. Put all those things into a system and the difference between Solaris and Linux or between PC and Sparc may well be lost in the noise. And if you don't have a pretty good idea of where you're going with it all before you set out, then you might not get there. Have you any metrics for the kinds of loads you expect to meet, and the parts of the system which will use most resources to sustain them? Do you know what performance you can expect from the database under the expected load conditions? Is any of this under your control? 73, Ged.
Re: Apache is exiting....
Hi there, On Mon, 3 Mar 2003, Paolo Campanella wrote: gdb reports that clean_child_exit is not defined - perhaps you are looking at newer sources than mine (1.3.22). Is there a reason why you don't want to upgrade to 1.3.27? 73, Ged.
Re: sanity check problem: Help installing mod_perl 1.27 andapache1.3.27
Hello again Charlie, On Mon, 24 Feb 2003, Charlie Smith wrote: Yes. I used gcc to compile perl 5.8, DBI 1.30, DBD::Orace 1.12. And Apache and mod_perl? I did have similar type of problem with perl 5.8 install. I changed all file containing 'WI,-E' to not use ',-E'. This allowed me to get through the 'make' for perl 5.8. I almost suggested doing something similar in my previous post. But it's better to fix the build process and submit a patch... :) 73, Ged.
Re: sanity check problem: Help installing mod_perl 1.27andapache1.3.27
Hi Charlie, On Mon, 24 Feb 2003, Charlie Smith wrote: How long before something like this gets into the build process and out as a patch? Or is there something I could do in the interim? As it seems that you're the only one having the problem, I meant that *you* might fix it and submit a patch. That's what this Open Source stuff is all about. :) On Mon, 24 Feb 2003, Charlie Smith wrote: Yes. I used gcc to compile perl 5.8, DBI 1.30, DBD::Orace 1.12. And Apache and mod_perl? You need to recompile Apache and mod_perl if you rebuild Perl. 73, Ged.
Re: sanity check problem: Help installing mod_perl1.27andapache1.3.27
Hi Charlie,
On Mon, 24 Feb 2003, Charlie Smith wrote:
Ok. I'll give it a whack or hack or whatever you want to call it. Where are
the Wl flags loaded from for the mod_perl stuff?
Actually they're from the Apache source, the mod_perl configuration may hack them.
The tool I use most for poking around in sources is 'grep'...
hurricane:~$ grep -r Wl /home/ged/src/apache_1.3.27/*
[snip,snip]
/home/ged/src/apache_1.3.27/htdocs/manual/programs/apxs.html:
-strongWc,/strongemcompiler/em-emflags/em ] [
-strongWl,/strongemlinker/em-emflags/em ] emfiles/em ...
/home/ged/src/apache_1.3.27/htdocs/manual/programs/apxs.html:
-strongWl,/strongemlinker/em-emflags/em
/home/ged/src/apache_1.3.27/src/CHANGES: *) Allow special options -Wc,xxx and -Wl,xxx
on APXS compile/link command.
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Zlink=dynamic
-Wl,-Bexport
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-E
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-E
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-E
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-Bexport
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-Bexport
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-Bexport
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-Bexport
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-Blargedynsym
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-E
-Wl,-B,deferred
/home/ged/src/apache_1.3.27/src/Configure: LDFLAGS_SHLIB_EXPORT=-Wl,-E
-Wl,-B,deferred -Wl,+s
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-Bexport:\$(SRCDIR)/support/httpd.exp
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Wl,-bE:\$(SRCDIR)/support/httpd.exp
/home/ged/src/apache_1.3.27/src/Configure:
LDFLAGS_SHLIB_EXPORT=-Zlink=dynamic -Wl,-Bexport
/home/ged/src/apache_1.3.27/src/modules/perl/mod_perl.config.sh:#replace -Wl args
meant for cc with args for ld
/home/ged/src/apache_1.3.27/src/modules/perl/mod_perl.config.sh:while ($ldopts =~
s/-Wl,(\S+)/$1/) {
/home/ged/src/apache_1.3.27/src/support/apxs.8:.BI \-Wl, linker-flags
/home/ged/src/apache_1.3.27/src/support/apxs.8:.BI \-Wl, linker-flags
/home/ged/src/apache_1.3.27/src/support/apxs.pl:print STDERR
[-Wl,flags] files ...\n;
/home/ged/src/apache_1.3.27/src/support/apxs.pl:my ($opt_Wl, $opt_L, $opt_l);
/home/ged/src/apache_1.3.27/src/support/apxs.pl:foreach $opt_Wl (@opt_W) {
/home/ged/src/apache_1.3.27/src/support/apxs.pl:$opt .= $1 if ($opt_Wl
=~ m|^\s*l,(.*)$|);
/home/ged/src/apache_1.3.27/src/support/apxs.pl:$opt .= -W$opt_Wl;
/home/ged/src/apache_1.3.27/src/support/apxs:print STDERR
[-Wl,flags] files ...\n;
/home/ged/src/apache_1.3.27/src/support/apxs:my ($opt_Wl, $opt_L, $opt_l);
/home/ged/src/apache_1.3.27/src/support/apxs:foreach $opt_Wl (@opt_W) {
/home/ged/src/apache_1.3.27/src/support/apxs:$opt .= $1 if ($opt_Wl =~
m|^\s*l,(.*)$|);
/home/ged/src/apache_1.3.27/src/support/apxs:$opt .= -W$opt_Wl;
hurricane:~$ grep -r Wl /home/ged/src/mod_perl-1.27/*
/home/ged/src/mod_perl-1.27/apaci/mod_perl.config.sh:#replace -Wl args meant for cc
with args for ld
/home/ged/src/mod_perl-1.27/apaci/mod_perl.config.sh:while ($ldopts =~
s/-Wl,(\S+)/$1/) {
73,
Ged.
Re: [mp2] what is GEN1 and why is it my log?
On Thu, 20 Feb 2003, Nick Tonkin wrote: Hi, In my logs when dumping a warn() I see this occasionally: 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28. 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28. 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28. 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28, GEN1 line 245. 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28. 192.168.0.24 at /home/wm/perl/WM/Auth/Access.pm line 28. Anyone know what GEN1 is I think it comes from Symbol.pm. It's a handle: the string GEN is in the source, the digit is just picked by the package when it opens a file/socket/whatever it's doing. and why it appears every so often? Nope. :( 73, Ged.
Re: sanity check problem: Help installing mod_perl 1.27 and apache1.3.27
Hi there, On Thu, 20 Feb 2003, Charlie Smith wrote: Am having problems as seen in the 'sanity check' below. [snip] -lsocket -lnsl -lpthread -Wl -L/usr/local/lib -L/opt/local/lib /usr/local/lib/perl5/5.8.0/sun4-solaris/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.8.0/sun4-solaris/CORE -lperl -lsocket -lnsl -ldl -lm -lc cc1: Invalid option `-Wl' cc1: Invalid option `-Wl' The -Wl argument should be followed by a comma and option(s) which gcc will pass to the linker. Your -Wl has no option(s) after it. This is not good. The configuration process does some substitutions on the Wl argument depending on the platform etc. Maybe the substitution isn't working right on your platform. In an earlier post you said that you'd had to add to your path to get 'make' to run. That's weird, makes me think your setup is whacky. Have you used make, gcc etc. to compile anything else on your system? Have you tried to build Apache stand-alone (without mod_perl)? Have you read the INSTALL documents for anything that might be mentioned about your platform? 73, Ged.
Re: Help with Apache 1.3.27 + mod_perl 1.27 installation
Hi there, On Thu, 20 Feb 2003, Arshavir Grigorian wrote: I was trying to build Apache 1.3.27 + mod_perl 1.27 [snip] So, following the suggestion from http://perl.apache.org/docs/1.0/guide/install.html#APACI_ARGS that one can pass *any* arguments to the Apache ./configure through the APACI_ARGS directive, I placed the following lines into /use/local/apache2-19/build/makepl_args.mod_perl APACHE_SRC=../apache_1.3.27/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 \ APACI_ARGS='--prefix=/usr/local/apache2-19, --enable-module=dir' This generated some errors during the configure process See a sample makepl_args.mod_perl (very old one:) below for the way to use this directive. 73, Ged. -- makepl_args.mod_perl.1.3.22 -- USE_APACI=1 APACHE_PREFIX=/usr/local APACHE_SRC=../apache_1.3.22/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--sbindir=/usr/local/sbin/httpd_perl APACI_ARGS=--sysconfdir=/usr/local/apache/httpd_perl/conf APACI_ARGS=--runtimedir=/usr/local/apache/httpd_perl/run APACI_ARGS=--logfiledir=/usr/local/apache/httpd_perl/logs APACI_ARGS=--localstatedir=/usr/local/apache/httpd_perl/stat APACI_ARGS=--proxycachedir=/usr/local/apache/httpd_perl/proxy APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=include APACI_ARGS=--enable-module=info APACI_ARGS=--enable-module=usertrack
