loading mod_perl DSO on a per-virtualhost basis?
Hello, I'd like to configure my apache installation (which contains several virtualhosts) to use mod_perl (compiled as DSO) only with _some_ of the virtualhosts, but not all of them. That is, I'd like to put a LoadModule directive into those virtualhost sections which use mod_perl and leave it out in the other virtualhosts. The benefit (so I hoped) would be a "small" httpd for the non-mod_perl-virtualhosts and a bigger one for the others. From the apache docs, I now get the information that LoadModule is only allow in a Server Config context. So it seems that my initial assumption about the DSO mechanism was too optimistic - when used in server context, I guess that again all httpd processes have the full size - or is apache smart enough to drop in the module only when the first function within it is accessed? It it possible to get the above functionality with DSOs at all? If not, what is the real benefit of DSO, besides the ability to remove and add server functionality without recompiling? _ Thomas Corte [EMAIL PROTECTED]
Re: loading mod_perl DSO on a per-virtualhost basis?
Thomas I'd like to configure my apache installation (which contains Thomas several virtualhosts) to use mod_perl (compiled as DSO) only Thomas with _some_ of the virtualhosts, but not all of them. Apache fork()s children to handle requests, hence they are all exact copies of the parent process. Unfortunately, there isn't really a way to do what you want. Thomas That is, I'd like to put a LoadModule directive into those Thomas virtualhost sections which use mod_perl and leave it out Thomas in the other virtualhosts. The benefit (so I hoped) would be Thomas a "small" httpd for the non-mod_perl-virtualhosts and a Thomas bigger one for the others. A single httpd process could handle requests for many different vhosts. You could always run separate Apache instances per vhost. :-) --bruno Bruno Connelly [EMAIL PROTECTED] Interweb Ninjaneer Whack Productions
Re: loading mod_perl DSO on a per-virtualhost basis?
Hi, On Wed, 26 Jan 2000, Bruno Connelly wrote: You could always run separate Apache instances per vhost. :-) Thanks for your comments. From the added ":-)", I derive that this may not be common practice :) However, if I'd like to do so, I'd have to split up my httpd.conf into a part with mod_perl-using-vhosts and a part with the remaining vhosts and setup 2 startup scripts for 2 separate apache instances, both listening on port 80 (or 443 for https). Has anyone ever tried such a setup or used it for a longer period in a production setup? _ Thomas Corte [EMAIL PROTECTED]
Re: loading mod_perl DSO on a per-virtualhost basis?
Bruno You could always run separate Apache instances per vhost. :-) Thomas From the added ":-)", I derive that this may not be common Thomas practice :) It's not uncommon, I'm just making the assumption that if you're worried about resource consumption, this might not your desired solution. However, I don't know your setup. If you'll only be splitting vhosts between a mod_perl enabled Apache instance and one that's not, it might not be too bad. ...assuming the management of that wouldn't be too much of a headache. Thomas However, if I'd like to do so, I'd have to split up my Thomas httpd.conf into a part with mod_perl-using-vhosts and a part Thomas with the remaining vhosts and setup 2 startup scripts for 2 Thomas separate apache instances, both listening on port 80 (or 443 Thomas for https). Yup, it's pretty straight forward. Given you won't want to bind() to every interface plumbed on the machine, you'll probably want to put in a Listen directive per vhost. Unless you're doing name based vhost'ing, but you'll still want a single Listen directive per instance. Thomas Has anyone ever tried such a setup or used it for a longer Thomas period in a production setup? It should work fine, just keep in mind the extra resources required for multiple instances (especially with pre-forking). But again, splitting one instance into two shouldn't be too nasty. --bruno Bruno Connelly [EMAIL PROTECTED] Interweb Ninjaneer Whack Productions
self url
Hello, Is there a way to get the URL of the current document in Embperl? Sort of like $q-self_url in CGI.pm. Vladimir
Re: self url
Hello Vladimir, ñðåäà, 26 ÿíâàðÿ 2000 ã., you wrote: VI Is there a way to get the URL of the current document in Embperl? Sort of like $q-self_url in CGI.pm. Hmmm. Maybe [- $req_rec-uri -] could help? ($req_rec represents apache request_rec object in Embperl). Best regards, Ilyamailto:[EMAIL PROTECTED]
Re: Apache problem with mod_example
Hi there, Mail to your address keeps coming back with fatal errors, so I'm sending this to the mod_perl List in the hope that we have more luck. 73, Ged. On Wed, 26 Jan 2000, Mail Delivery Subsystem wrote: The original message was received at Wed, 26 Jan 2000 08:59:57 GMT from ged@localhost - The following addresses had permanent fatal errors - [EMAIL PROTECTED] - Transcript of session follows - ... while talking to zmamail03.zma.compaq.com.: RCPT To:[EMAIL PROTECTED] 554 Service unavailable; [212.1.144.72] blocked using dul.maps.vix.com 554 [EMAIL PROTECTED]... Service unavailable On Tue, 25 Jan 2000, Wang, Pin-Chieh wrote: Hi Mr. Haywood, Please, call me `Ged'. People are less formal on the Web, I think. It turn's out the apache and mod_perl is working after all. I was sure that Apache was running OK. That's great! when I called //localhost:8080/hello/world everything starts working now. But, when I called //localhost:8080/server-info I got permission denied. Do you know how can I grant my permission? Or just ask for username password? I took this from your file `Configuration'. Have you uncommented the statement and recompiled Apache? mod_info is required before you can get server-info. # AddModule modules/standard/mod_info.o I also took this from your file `httpd.conf' # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the ".your_domain.com" to match your domain to enable. # #Location /server-info #SetHandler server-info #Order deny,allow #Deny from all #Allow from .your_domain.com #/Location You have to edit this part of the file to give yourself permission to get server-info. Hope this helps. 73, Ged.
RE: self url
VI Is there a way to get the URL of the current document in Embperl?
Sort of like $q-self_url in CGI.pm.
Hmmm. Maybe [- $req_rec-uri -] could help? ($req_rec represents
apache request_rec object in Embperl).
Or $ENV{SCRIPT_NAME} or $ENV{REQUEST_URI} depending on what you need may
also work
Gerald
Virtual Hosting with Mod_perl?
Hi, I know its a bit off-topic (my apologies) but I thought that for sure someone from the list could recommend a web-hosting company that has a virtual host account with mod_perl and SQL such as mySQL, mSQL and/or Oracle, and possibly with your own apache web server, and of course good tech support and performance. Thanks in advance David
Re: ANNOUNCE: HTML::Mason 0.8
Good question! I ran a test on my Linux box and it seems to work there, anyway. The test repeatedly caused the cache to dump items by loading more components that it could handle. After a few iterations the process size maxed out at 6 MB. So it looks like the subroutines do get freed. If I get around to it at some point I'll cleanup and post the test program. Jon At 01:46 PM 1/24/00 -0800, Perrin Harkins wrote: On Sun, 23 Jan 2000, Jonathan Swartz wrote: - New in-memory code cache keeps track of component usage, and discards the most infrequently used components as needed. You can specify the cache size with interp-max_code_cache_size. This sounds cool, but does it work, i.e. when you undef a sub reference, does the memory really get released and reused? - Perrin
Re: Virtual Hosting with Mod_perl?
On Wed, 26 Jan 2000, David Jourard wrote: I know its a bit off-topic (my apologies) but I thought that for sure someone from the list could recommend a web-hosting company that has a virtual host account with mod_perl and SQL such as mySQL, mSQL and/or Oracle, and possibly with your own apache web server, and of course good tech support and performance. Check out http://perl.apache.org/isp.html thats just what you need :) - gustav Gustav Kristoffer Ek, Netcetera, Brolæggerstræde 4, 1211 København K Telefon +45 33 14 70 00 / +45 20 40 00 05 - Faximile +45 33 14 62 00 Design, Webhotel, Mailhotel, UUCP mod_perl http://www.netcetera.dk
Re: loading mod_perl DSO on a per-virtualhost basis?
However, if I'd like to do so, I'd have to split up my httpd.conf into a part with mod_perl-using-vhosts and a part with the remaining vhosts and setup 2 startup scripts for 2 separate apache instances, both listening on port 80 (or 443 for https). I think you might find the answer to this in the performace tuning section of the mod_perl guide: http://perl.apache.org/guide I haven't got the full url handy. Kees
httpsd with my content handler immediately dumps core- likely causes?
Hi,
I've written an Apache perl module. The module is supposed to look at
the request, and do some DBI selects in an MySQL table, then display
them with HTML::Template. There were initially some issues with scoping,
I hacked through these and eventually get the module to compile without
all the errors that cause the server not to start.
I've got PerlModule Apache::DBI in my httpd.conf (dev.conf) and I open a
handle to my database before the sub handler {...}.
Now I get only:
[root@melanie /root]# httpsd -X -f /etc/httpd/conf/dev.conf
[Wed Jan 26 10:28:38 2000] [warn] Loaded DSO modules/libperl.so uses
plain Apache 1.3 API, this module might crash under EAPI! (plea
e it with -DEAPI)
Segmentation fault (core dumped)
[root@melanie /root]#
For the record, RedHat's response to the above warning seems to be "Well
it only matters if you're using SSL calls, and you're not, so go to
hell." ... This from a RedHat systems engineer:
It is a warning, not an error. You may ignore it.
It simply means the modules were compiled for a non-SSL-enabled version
of Apache. If the modules do not use any SSL functionality, there will
be no problem.
Whatever, I guess I have take their word for it (or roll my own with
Open SSL which I really can't spare the time to fight with.) Anyway,
some simpler early test versions of the module (before adding the DBI
and HTML::Template stuff) worked, so I THINK mod_perl is OK. There are
some registry scripts running against the same httpsd and mod_perl to
support this assertion.
Nothing is really showing up in the logs (the warning does, nothing
else), I'm wondering if this rings a bell with anyone.
Perhaps someone could point me to a clearer explanation of Apache::DBI
persistent connections etc...
I'm still a bit mystified as to the difference for scoping and name
spaces between scripts (modules) that are handlers and scripts that run
under Apache::Registry. I have read Stas's section on this AND man
APache::DBI AND perldoc DBI AND Jeff Baker's thing. Unfortunately they
didn't clear up my confuson. For various reasons (aparently including
masocisim G) I am trying to write my own handler.
Thanks,
John Walker
Re: [ID 20000118.004] DynaLoader doesn't dlclose XS code on interpreter
On Wed, Jan 26, 2000 at 04:06:29PM +, Alan Burlison wrote: Gurusamy Sarathy wrote: Scheduling dlclose()s using call_atexit() ought to work. I'm going to let the interested parties test that and send me a patch. Is anyone up for this? I'm in the US this week, so I'm not able to contribute much (plus I'd probably just break something ;-) Gurusamay, do you have a timescale for when you need this? I'll try to do it this weekend, or else if I get bored during LinuxWorld Expo :) Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
problem with variables sticking.
Hi, this is a huge problem. I have a module written a module with a form on it, and for some reason or another if one user fills out the form and presses the submit button (doing its stuff), and then another different user happens to access that same module to display the same form at around the same time the first user presses submit, the form loads with the values that the first user put into the fields. Does any one have any idea how this could possibly be happening? It's only happening with mod_perl modules, never happened with my perl scripts Thanks, Etienne
Re: loading mod_perl DSO on a per-virtualhost basis?
Hi Thomas, On Wed, 26 Jan 2000, James G Smith wrote: Thomas Corte [EMAIL PROTECTED] wrote: So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect to decrease top's values above significantly? I don't think so. My understanding of DSOs in Apache was to allow inclusion of code without recompiling the whole thing. This allows for third-party proprietary modules. The DSOs can, in general, share code across binaries, not processes. All processes sharing a binary don't have separate copies of the binary, or shouldn't. However static libraries cannot be shared between binaries. Only DSOs. Your biggest savings could come from making the perl core a DSO so the perl binary and Apache share the same core perl interpreter code. James is quite right, but I'm told that even making the perl core a DSO won't give the savings that I think you are hoping for. In a mod_perl box, as far as memory consumption is concerned, the processes of concern are usually the Apache children. They are fairly big, and there can be a lot of them. Because of the way that Apache tries to preempt incoming requests by pre-forking a pool of children `just in case', you may not always know how many! They share a good chunk of their memory when they are forked, but then as a result of copy-on-write (two or more processes share a page of memory, one wants to change it, the others don't, so a copy has to be made just for that process) the memory gradually (or otherwise) becomes unshared. When they grab some memory to store a large object, the children have a habit of hanging on to it until they die. In addition there have been memory leakage and similar problems which have sometimes caused the Apache children to do antisocial things like growing without bound and refusing to die. Some of these problems are being dealt with as new releases come out and I'm sure that a lot of us have high hopes for mod_perl 1.22. Running a second server (a `proxy', not mod_perl enabled, and which listens normally on port 80 but always on a _different_ port from the mod_perl enabled server) to serve static documents, tweaking the server configuration variables such as MaxRequestsPerChild to limit child growth, the use of modules designed to limit the processes' resource consumption, and faster networks, clients and servers can all offer partial solutions, but I feel that memory footprint is going to remain an issue with mod_perl until memory is much cheaper per byte (happening as we write) or until Doug and friends make it use less, or until something unthinkable happens - like the technology becoming obsolete overnight because of a breakthrough elsewhere. In the meantime, some people are using Gigabytes of RAM to cope with their mod_perl children. I hope this isn't too depressing:) 73, Ged.
Re: numerous segv's, bus error
[apologies if people get this twice -- it seemed to bounce the first time] We've been getting many segv's and bus errors on apache processes since adding modperl. Env: Apache 1.3.11 (though we had the same thing under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00. If you compare this to my earlier post this week, I believe we are having the same problem. I've tried rolling back to 1.3.9 as well and had the same problem. I'm running Linux 2.3.39 and 2.2.15, btw -- it's interesting to note that you are having this problem on another system. I've tried every possible configuration of static/dynamic I can think of, too. Setting PerlFreshRestart to "off" didn't seem to do the trick for me either. I tried using the latest cvs snapshot of mod_perl with no luck. I agree -- this is a problem with the cleanup. In a way I'm glad it's not just me, although I'm really sorry you are being bit by this too! Hopefully someone will have an idea. -DeWitt
OT: mod_proxy socket error
Hi all, I have been getting the following error when I try to do some stress testing on a machine: [error] [client 10.1.1.1] (55)No buffer space available: proxy: error creating socket Basically the box is just the front end proxy to a backend process that is running on another machine. It is running FreeBSD 3.4-RELEASE. I tweaked kern.ipc.maxsockbuf. But since I am trying to fetch requests from a remote host increasing this setting did not help. I am guessing that I am going to have to tweak some of the net.inet values to increase the buffers for the nic but I just can not seem to see the forest through the trees right now. If anyone has already run into this or a similar problem in the past I would love to get the answser on a silver platter :^) Thanks and sorry for the slightly off topic post. Ian
Re: make test
That was a good guess. In fact I had the following definition in my /etc/hosts 127.0.0.1 localhost.localdomain local is seems that the alias localhost is important. Thanks. Ilan - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Bruno Connelly [EMAIL PROTECTED] Cc: Ilan Bar-On [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: éåí ùðé, éðåàø 24, 2000 10:46 Subject: Re: make test Ilan When I am connected to the net(inetrnet) everything continue Ilan to work fine. Ilan However, when I am offline, make test fails. Ilan It complains about: Ilan still waiting for server to warm upnot ok Ilan server failed to start! Perhaps this is because the interface it's trying to bind() to isn't plumbed yet? [tx... well, well] Do you have this entry in /etc/hosts? 127.0.0.1 localhost.localdomain localhost Do you have a loopback device [lo] configured? [hint: try 'ifconfig lo'] Having these fixed will solve your problem. ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Running 2 httpd on one mache question.
"Martin A. Langhoff" wrote: Hi all, I've read all the documentation on how to run 2 different httpd, one for lightweight serving and a mod_perl enabled daemon. Also read the threads about this last weeks. But there's one thing that I can't imagine. When I run top, how do I tell memory/cpu consumption from lightweight daemons from the mem/cpu consumption from mod_perl daemons? Thanks in advance.. A couple ways, first, the mod_perl httpd will be taking up much more RAM, but what I really do is rename the lightweight httpd binary to another name, like phttpd (for proxy-httpd), or some such, then its real easy to tell. You'll have to change the apachectl command script with the new binary name of apache. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: loading mod_perl DSO on a per-virtualhost basis?
Hello, On Wed, 26 Jan 2000, G.W. Haywood wrote: If not, what is the real benefit of DSO It's intended to save memory, by sharing it between processes. Well, this is exactly what I want :). Currently, I have mod_ssl and mod_perl linked statically into my httpd binary (under HP/UX 11), which as a result is about 3MB big. "top" yields a process size of about 9MB, with about 4,5MB resident for each httpd running. This size seems to cause some memory and swapping problems. So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect to decrease top's values above significantly? _ Thomas Corte [EMAIL PROTECTED]
Re: problem with variables sticking.
Etienne Pelaprat wrote: Hi, this is a huge problem. I have a module written a module with a form on it, and for some reason or another if one user fills out the form and presses the submit button (doing its stuff), and then another different user happens to access that same module to display the same form at around the same time the first user presses submit, the form loads with the values that the first user put into the fields. Does any one have any idea how this could possibly be happening? It's only happening with mod_perl modules, never happened with my perl scripts Welcome to mod_perl! Since perl persists, your data may stay around between requests ... try putting "use strict;" at the top of your programs modules, and work through those issues. Use 'my $var' when variables should be localized... give the modperl guide a good couple reads too! http://perl.apache.org/guide/ The problem you are having is documented in the guide. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
SIG __WARN__ and (unrelated) mail digest
How do I get a friggin' daily digest of this barfimonious list instead of
the full barf?
Just for something more on topic, how do I disable specific warnings in
mod_perl?
Bad and weird things seem to happen when I try to handle SIG{__WARN__} even
when I hide it as local. Is there any other way to pragma out specific
warnings?
--John Hempe
several program w/ mod_perl
Hello,
while I begin to write some test perl script to test mod_perl after read
necessary document,still get folloing error.please correct my error(maybe
silly one)
Following is my problem while using mod_perl.
apache 1.3.3 + mysql 2.22 + RH 6.0 + modperl 1.21 + perl 5.005_3
Modperl build w/ everything=1
apache conf:
Alias /perl//usr/local/apache/share/cgi-bin/
PerlFreshRestartOn
PerlRequire /usr/local/apache/share/cgi-bin/include/startup.pl
#PerlSetupEnv OFF
PerlSendHeader OFF
#DBI_TRACE "2=/tmp/dbitrace.log"
PerlModule Apache::DBI
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
# PerlSendHeader On
Options +ExecCGI
/Location
Location /perl-status
SetHandler perl-script
PerlHandler Apache::Status
/Location
+
and the startup.pl is below:
use CGI;
use Apache::DBI;
use strict;
Apache::DBI-connect_on_init
("DBI:mysql:uwang::localhost",
"uwang",
"uwang",
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1 # commit executes immediately
}
);
1;
I did read the mod_perl,cgi-to_mod_perl,mod_perl_traps and
perl.apche.org/guide before coding.
now weird problem is:
1. since I use connect_on_init and set dbi trace,I think once the apache
server start,it should automatically create a dbh connection,aka dbh,is it?
but i never see this info in /tmp/dbitrace.log .why?
2.dbitrace.log did log any connection made by my mod_perl script.something
like below:
DBI 1.06 dispatch trace level set to 2
- DBI-Apache::DBI::connect(DBI:mysql:uwang::localhost, uwang, uwang,
HASH(0x830d900))
- FETCH= 'mysql' ('Name' from cache) at DBI.pm line 64.
- ping for DBD::mysql::db (Apache::DBI::db=HASH(0x821db30)~0x821db00)
- ping= 1 at DBI.pm line 112.
^
- STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'RaiseError' 0)
- STORE= 1 at DBI.pm line 400.
- STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'PrintError' 1)
- STORE= 1 at DBI.pm line 400.
- STORE for DBD::mysql::db (DBI::db=HASH(0x821db00)~INNER 'AutoCommit' 1)
- STORE= 1 at DBI.pm line 400.
- connect= Apache::DBI::db=HASH(0x821db30)
^
Now here is 2 questoin. first is,does the ping=1... line means what the
guide document said "it will ping if a exist dbh still alive" ?so does the
ping=1 means "Yes,I've find a exist dbh and it's ok"?since these info is
generate by my first connection in my script,does it means it's ping the dbh
create by the apache::DBI connect_on_init?butjust the connect_on_init not
logged? the 2nd is,the connect line, does this means,"ok,I will tell the
mod_perl script to use a exist dbh HASH(0x821db30)"? if so,means the script
is REUSE the dbh as we expect.Also,I am quite sure because when I reload
the script again and find out that above log info occur again,yeah,so does
it means the 2nd connection still reuse the same dbh?
I am happy at first but later all changed. TO test if its true,I use ab to
do the test,I run with:
./httpd -X
then
./ab -n 10 -c 10 myscript.pl
during the runtime,I use mysaladmin processlist to see it it REALLY just
create one connection.and :-( NO,NOT at all.tens of mysql connection
there...why? Do I understand above log info wrongly or config the
httpd.conf file wrong?
Ok,with above configuration,another problem there.my script just do one
thing,"select username from user where id=1".the problem is funny.in the
first time I run the script,the homepage generated like :
test blah blah blah---just one line
Ok,then I reload it via hit the Refresh button of browser,ok now it looks
like:
test blah blah blah---just one line
test blah blah blah---the 2nd line!!!
so when you refresh again,just add another SAME line.Seems the sql query
was cached??when I hit the REFRESH button,its funny that it not only
execute the sql query in this request,but also execute the one I execute
before.so when you refresh 10 times,you got 10 line.I am blur and I didn't
think I use any sentence could make this problem occur.
Also,I set the StartServer is 15 in httpd.conf.before I startup apache,it
will start 15 apache child.ok,before start apache,there is just 1 mysqld
there,as soon as I start up apache,it 's 16 now.yes,each apache child
establish a mysql connection,seems the connect_on_init works,but now what I
want?
Thank you all very much,
Vincent
__
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com?sr=mc.mk.mcm.tag001
Re: PLEASE HELP - ERROR Linking Apache with mod_perl
Asghar, I've answered this question a few days ago - look at the archives! (hint: perl.apache.org) search for PL_perl_destruct_level (it'll show up in the next guide's release) I hope somebody could respond to this problem. I get the following link error when I try to make apache_1.3.9 with mod_perl-1.21. Am I missing a library module? Thanks, -Asghar This is how I built it: cd mod_perl-1.21 perl Makefile.PL PREP_HTTPD=1 make make test make install cd ../apache_1.3.9 ./configure --with-layout=RedHat --target=perlhttpd --activate-module=src/modules/perl/libperl.a gcc -c -I./os/unix -I./include -DLINUX=2 -DTARGET=\"perlhttpd\" -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite `./apaci` buildmark.c gcc -DLINUX=2 -DTARGET=\"perlhttpd\" -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite `./apaci`\ -o perlhttpd buildmark.o modules.o modules/perl/libperl.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a regex/libregex.a lib/expat-lite/libexpat.a -lm -lcrypt modules/perl/libperl.a(mod_perl.o): In function `perl_shutdown': mod_perl.o(.text+0xf8): undefined reference to `PL_perl_destruct_level' mod_perl.o(.text+0x102): undefined reference to `PL_perl_destruct_level' mod_perl.o(.text+0x10c): undefined reference to `PL_perl_destruct_level' mod_perl.o(.text+0x13b): undefined reference to `Perl_av_undef' MORE ERROR ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Virtual Hosting with Mod_perl?
I think Minerva has what you need. Chantilly Virginia. http://www.minerva.net. Haven't tried their virtual hosting though, just their colocation for a physical host. At 10:01 AM -0500 01/26/2000, David Jourard wrote: Hi, I know its a bit off-topic (my apologies) but I thought that for sure someone from the list could recommend a web-hosting company that has a virtual host account with mod_perl and SQL such as mySQL, mSQL and/or Oracle, and possibly with your own apache web server, and of course good tech support and performance. Thanks in advance David
Re: problem with variables sticking.
this is a huge problem. I have a module written a module with a form on it, and for some reason or another if one user fills out the form and presses the submit button (doing its stuff), and then another different user happens to access that same module to display the same form at around the same time the first user presses submit, the form loads with the values that the first user put into the fields. Does any one have any idea how this could possibly be happening? It's only happening with mod_perl modules, never happened with my perl scripts Actually we do have the idea, please read: http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it And remember: "mod_perl hates sloppy programmers and punishes them" :) (hint: *all* variables should be *initialized*) ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
efficiency questions (templates, regexes, db calls)
Hi, gang. I'm working on my first serious mod_perl app, and have a few
questions regarding efficiency -- basically looking for traps I may not
have internalized after reading the mod_perl_traps page and so forth.
I'm developing a site that will use MySQL on the backend to store some
info related to goofy timewasting projects (e.g., name, url, contributor,
date last updated, description, etc.) The idea is that there really needs
to be a site where I can list all my goofy timewasting projects, and I
want other people to submit their stuff, too. Sort of a freshmeat for the
random non-commercial stuff that abounds on the 'Net, but which seems to
be neglected in this weblog age, or doesn't get much notice unless it's an
Open Source [tm] project with millions of contributors. :)
Anyway. I have been designing the templates for each class of page on the
site (main project list, individual project detail, admin forms, and so
forth). I want to populate each template with data from the db. I don't
particularly want to use EmbPerl; I'd rather read the templates at init
time and parse in the db data when the page is to be returned. Are there
any traps I should be aware of? I only have four or five relatively small
templates, so memory consumption shouldn't be a big deal. From what I
understand from reading the Guide, these vars will likely be shared,
anyway, right, if I make the vars global and populate them at startup?
I figure I'll put the actual perl modules in lib/perl/, and put the
templates I'm going to use in directories under docroot that correspond
to the handler I've defined, just for sanity's sake. So,
Location /hello
SetHandler perl-script
PerlHandler Apache::Hello
/Location
would use templates found in $docroot/hello, and so on. But the actual
templates would be loaded at httpd init time, and kept around, then
I'll perform substitutions on them based on user input or database info.
I know about using /o to compile a regex. The embedded tokens in the
templates won't change, so this will probably work fine, right?
(e.g.:
!--( $variable )--
can be replaced by the variable's value on the fly, without hitting
the disk to open the template file:
my $variable = "something I got from a form or db";
my @lines = split($GLOBAL_VAR_CONTAINING_TEMPLATE_GUTS);
while(@lines) {
s/!--( $variable )--/$variable/o;
print;
}
I know to use persistent db connections and pre-load DBI. I know to
tweak Max* to maximize performance. I'm just wondering if there's any
other obvious traps that come to mind. Thanks in advance.
Steve
Re: Results of calling perl_shutdown in mp_dso_unload
On Fri, 21 Jan 2000, Daniel Jacobowitz wrote: (with appropriate changes to unload DSOs after shutting down perl, of course). I still get memory leakage - that's not terribly surprising - but it is much less. It's on the order of about 24K/restart and is probably the fault of some module - my guts would be DBD::Pg. I'll play around with that later. It's small enough to show that the idea is workable. Restarts are also a bit slower, unsurprisingly - there's a lot more to do. right, that's one of the reasons restarts are a noop for mod_perl by default (not including dso-magic) Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Doug is slowly crawling back from the death flu :-/ I'm think about releasing 1.22 as it stands in the cvs tree, since it's so long overdue, and bang out the dso issues from there. as much as I want to cure the dso problems, I don't want to introduce new problems the currently stable static configuration.
RE: mod_perl 1.21 - CGI.pm 2.56 error in phase other than conten t
from chapter 9 of wrapmod:
There are a number of standard variables that Apache adds to the
environment prior to invoking the content handler. These include
DOCUMENT_ROOT and SERVER_SOFTWARE. By default, the complete C%ENV
hash is not set up until the content response phase. Only variables
set by BPerlPassEnv, BPerlSetEnv and by Imod_perl itself will be
visible. Should you need the complete set of variables to be
available sooner, your handler code can do so with the
Isubprocess_env method. Example:
my $r = shift;
my $env = $r-subprocess_env;
%ENV = %$env;
On Wed, 22 Dec 1999 [EMAIL PROTECTED] wrote:
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
doug,
thanks for the response. I had tried the bandaid with no luck.
Probably should have said that in the post :-)
Ok having realised that the Handler wasn't getting called as I already had
another PerlPostReadRequestHandler being called the issue is getting
clearer
I am trying to call CGI within a PerlAuthenHandler
I can new correctly create the CGI object, i.e. it no longer falls over on
registering it's callbacks. However it does not get any of the data. Now I
presume this is because the CGI environment is not yet set up. In the
server log it appears to be working offline.. So I tried adding to the
environment before calling CGI-new setting REQUEST_METHOD CONTENT_LENGTH
and CONTENT_TYPE. This creates the object correctly (but without any
parameters) on a POST request. It would appear that CGI is not getting
anything from STDIN. At the moment I can work around this by calling
cgi-param for each bit of $r-content, I was just wondering if there is a
better way fro all of this ?
SAM
Re: PerlRun and Exporter() vars
On Mon, 27 Dec 1999, John M Vinopal wrote:
More about the undef of package variables. Sure enough, the variables are
nuked in PerlRun::flush_namespace(). This can be inhibited by removing
them from the script's namespace before termination:
my $name = __PACKAGE__ . '::';
delete($name-{'VARIABLE NAME HERE'});
I notice that the 1.17 bug about undefing subroutines was fixed by adding
some checking code PerlRun::undef_cv_if_owner(), should this same sort of
thing be done for variables as well?
yes, sounds like that's the case. thanks for the insights. ToDo
Re: efficiency questions (templates, regexes, db calls)
did you check out?
http://search.cpan.org/search?dist=HTML-Template
this might do most of what you need, and handle some things
you haven't thought of yet.
cliff rayman
genwax.com
Steven Champeon wrote:
Hi, gang. I'm working on my first serious mod_perl app, and have a few
questions regarding efficiency -- basically looking for traps I may not
have internalized after reading the mod_perl_traps page and so forth.
I'm developing a site that will use MySQL on the backend to store some
info related to goofy timewasting projects (e.g., name, url, contributor,
date last updated, description, etc.) The idea is that there really needs
to be a site where I can list all my goofy timewasting projects, and I
want other people to submit their stuff, too. Sort of a freshmeat for the
random non-commercial stuff that abounds on the 'Net, but which seems to
be neglected in this weblog age, or doesn't get much notice unless it's an
Open Source [tm] project with millions of contributors. :)
Anyway. I have been designing the templates for each class of page on the
site (main project list, individual project detail, admin forms, and so
forth). I want to populate each template with data from the db. I don't
particularly want to use EmbPerl; I'd rather read the templates at init
time and parse in the db data when the page is to be returned. Are there
any traps I should be aware of? I only have four or five relatively small
templates, so memory consumption shouldn't be a big deal. From what I
understand from reading the Guide, these vars will likely be shared,
anyway, right, if I make the vars global and populate them at startup?
I figure I'll put the actual perl modules in lib/perl/, and put the
templates I'm going to use in directories under docroot that correspond
to the handler I've defined, just for sanity's sake. So,
Location /hello
SetHandler perl-script
PerlHandler Apache::Hello
/Location
would use templates found in $docroot/hello, and so on. But the actual
templates would be loaded at httpd init time, and kept around, then
I'll perform substitutions on them based on user input or database info.
I know about using /o to compile a regex. The embedded tokens in the
templates won't change, so this will probably work fine, right?
(e.g.:
!--( $variable )--
can be replaced by the variable's value on the fly, without hitting
the disk to open the template file:
my $variable = "something I got from a form or db";
my @lines = split($GLOBAL_VAR_CONTAINING_TEMPLATE_GUTS);
while(@lines) {
s/!--( $variable )--/$variable/o;
print;
}
I know to use persistent db connections and pre-load DBI. I know to
tweak Max* to maximize performance. I'm just wondering if there's any
other obvious traps that come to mind. Thanks in advance.
Steve
Re: Results of calling perl_shutdown in mp_dso_unload
On Wed, Jan 26, 2000 at 08:13:41PM -0800, Doug MacEachern wrote: right, that's one of the reasons restarts are a noop for mod_perl by default (not including dso-magic) Makes sense. Here's a question - an apache patch should be able to mark the module as not-to-unload (although since it should be not-to-unload-unless-removed-from-config it would be a bit more complicated than that - still not impossible). But is that worthwhile or should we just adjust to being unloaded if built as DSO? Then we have the fact that this currently removes PerlRestartHandler functionality and goes far beyond PerlFreshRestart. Those are a big issue - those will HAVE to work differently depending on whether or not mod_perl is a DSO. If not, they can continue to work as before, but if it is they will never be invoked. I'll clean up the patch and fire it off later this weekend, if Doug doesn't get a chance to look at it before then. Doug is slowly crawling back from the death flu :-/ I'm think about releasing 1.22 as it stands in the cvs tree, since it's so long overdue, and bang out the dso issues from there. as much as I want to cure the dso problems, I don't want to introduce new problems the currently stable static configuration. Understood - good idea. Which reminds me - the CVS instructions linked from perl.apache.org no longer work. Is there a public CVS archive still? Where did it move? Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: Status in httpd access log
have a look at Apache::RedirectLogFix
On Thu, 6 Jan 2000, Mark Nudelman wrote:
I'm writing my first module using modperl, so I'm probably doing
something really wrong, but I haven't been able to figure this out. I
want my script to return an HTTP error code to the client, and I want
that error code to be logged to the httpd access log. If I use this
script:
my $r = Apache-request;
$r-status(304);
everything works as expected: the client receives a "304 Not Modified"
status line, and the log shows a "304" status.
But if I do this:
$r-status(304);
$r-err_header_out("X-Test-Header" = "abc");
$r-send_http_header();
then the client still receives the 304 status as expected, as well as
the extra header, but the log shows a status of 200, not 304. In fact,
the err_header_out doesn't matter; if I just call send_http_header, the
log shows 200. How can I make the log show the correct status?
Another problem is that in some cases, such as if I return a "400 Bad
Request" status, I'm getting a "Connection: close" header as well. Is
there any way I can control this? I don't want to send a Connection:
close header, even if I return an error status.
Thanks for any help,
--Mark
Re: Perl modules in apache configuration
if you compile modperl with PERL_TRACE=1 and setenv MOD_PERL_TRACE s then you should see some useful diagnostics when mod_perl is processing Perl sections. On Sun, 9 Jan 2000 [EMAIL PROTECTED] wrote: Hello! I'm trying to configure httpd.conf using Perl sections (mod_macro is not enough for me), but the result is weird. The most weird thing is that Perl sections randomly doesn't execute! I have no experience (yet) with Perl configuration modules, so I don't understand where to start tracking. mod_perl developers' guide didn't help, as perldoc mod_perl :-( -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145][[EMAIL PROTECTED]]
Re: Memory leak/server crashes
there are hints in the SUPPORT doc on how to debug such problems. there
was also several "Hanging process" threads in the past weeks with more
tips, search in the archives for keywords gdb, .gdbinit, curinfo
if you can get more insight from those tips, we can help more.
On Sun, 9 Jan 2000, James Furness wrote:
I'm looking for some help getting apache to run reliably. Apache 1.3.9 with
mod_perl 1.21 and Perl 5.005_03 is running on a dual P500 with 1 Gb of RAM
running Redhat 6.1. We run about 5 sites off the box, most of which are
fairly high traffic, and use a lot of CGI and
MySQL 3.22.25 is used with Apache::DBI.
The major problem seems to be a memory leak of some sort, identical to that
described in the "memory leak in mod_perl" thread on this list from October
1997 and the "httpd, mod_perl and memory consumption (long)" thread from
July 1997.
The server runs normally for several hours, then suddenly a httpd process
starts growing exponentially, the swapfile usage grows massively and the
server starts to become sluggish (I assume due to disk thrashing caused by
the heavy swap usage). Usually when this started to happen I would log in
and use apachectl stop to shutdown the server, then type 'killall httpd'
several times till the processes finally died off, and then use apachectl
start to restart apache. If I was not around or did not catch this, the
server would eventually become unresponsive and lock up, requiring a manual
reboot by the datacentre staff. Messages such as "Out of memory" and
"Callback called exit" would appear in the error log as the server spiralled
down and MySQL would start to have trouble running.
To combat this, I created a script to monitor load and swapfile usage, and
restart apache as described above if load was above 7 and swapfile usage
above 150Mb. This script has kept the server online and we now have an
uptime of something like 22 days (previously no more than 1 day), but the
script is getting triggered several times a day and no more "Out of memory"
messages are appearing, but the situation is not ideal.
I have tried adding:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
Carp::cluck "$class can't \$UNIVERSAL::AUTOLOAD!\n";
}
As recommended by the developers guide, which flooded the error log with the
text below being printed roughly once a second in the error log:
-
Apache=SCALAR(0x830937c) can't $UNIVERSAL::AUTOLOAD!
Apache=SCALAR(0x8309364) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
DBI::DBI_tie=HASH(0x82dd16c) can't $UNIVERSAL::AUTOLOAD!
IO::Handle=IO(0x820aabc) can't $UNIVERSAL::AUTOLOAD!
--
I've pretty much exhausted any ways I can think of to trace this problem,
such as i've tried to eliminate memory leaks in code by removing some
scripts from mod_perl and running them under mod_cgi and i've tried tweaking
MaxRequestsPerChild both without any success.
One thing that was mentioned in a previous thread was that using 'exit'
could confuse perl, and exit() is used fairly heavily in the scripts since
most are converted to mod_perl from standard CGIs, but i'd prefer not to
have to remove these since the structure of the scripts is reliant on some
form of exit statement. Is there some alternative to exit()?
I've also had a look at some of the patches to Apache.pm and Apache.xs
suggested in the previous threads, and these seem to have been incorporated
into mod_perl 1.21.
Are there any other solutions I could try to this problem? Does anyone know
what might be causing this?
The second problem I have is when loading pages, usually CGI, but I think
this has happened on some static pages, what IE5 describes as "Server not
found or DNS error" is experienced. Originally I thought this was the server
hitting MaxClients (150) since it usually occurs at the same time as massive
surges of hits, and /server-status usually shows 150 httpd processes have
been spawned, however I increased MaxClients to 200 recently and the error
has continued to happen, even though /server-status doesn't show any more
than about 170 processes spawned. I have not ruled out DNS server troubles
or backbone problems (We've had a few routing troubles recently that slowed
things down, but not actually cut off traffic or anything like that), but I
am at a loss as to what else could be causing this so I thought i'd ask
whilst i'm on the subject of server problems :)
Thanks in advance,
--
James Furness [EMAIL PROTECTED]
ICQ #: 4663650
Re: Help
sounds like your script is running under mod_cgi, not mod_perl On Tue, 11 Jan 2000, Akio wrote: I´m programming in mod_perl and I'm trying to use libapreq-0.31 but when I call method new, I get the msg "Can't locate object method "new" via package "Apache::Request"". The package (module) that use it has a statement "use Apache::Request ( )" and the next statement is : my $r= Apache::Request-new(shift); I have it installed in a Sun Solaris server (not i86) and I´m using Perl 5.005. I have downloaded it from CPAN site. Anyone can help me?
Re: problems with module at root of web site
On Wed, 12 Jan 2000, Sean Chittenden wrote: Mind if I ask a nit-pick of a performance question? Currently speed and performance are of upmost importance (I'm currently involved in a mod_perl vs JServ development race). That being said, isn't pushing a handler onto the request stack slower than predefining a handler that the request falls through to? I could be wrong and haven't tested things otherwise, but, it would seem like pushing a custom handler (granted it's already compiled into byte-code) onto the stack at the time of the request would take slightly longer. I suppose I'd be who of me to test this assertion, but if you have any idea as to wether or not this case ahead of time, I'd be greatly interested in hearing about your past experience. I don't think it would be a measurable difference. the only overhead using push_handlers vs. .conf is: -one Perl method call -growing the Perl*Handler array by 1, if it's not big enough already
RE: mod_perl bug (mod_perl 1.21; Apache 1.3.9).
On Wed, 19 Jan 2000, John Hughes wrote:
what happens if you preload Apache::Registry in httpd.conf:
PerlModule Apache::Registry
Didn't try that. But code examination seems to imply that it would have
no effect.
1. Apache::Registry gets run, so:
unless (defined $Apache::Registry::NameWithVirtualHost) {
$Apache::Registry::NameWithVirtualHost = 1;
}
Now NameWithVirtualHost is 1.
2. a non-virtualhost request is received so perl_handler in mod_perl.c does:
if((nwvh = ApachePerlRun_name_with_virtualhost())) {
if(!r-server-is_virtual) {
SAVESPTR(nwvh);
sv_setiv(nwvh, 0);
}
}
now NameWithVirtualHost is 0.
and it stays zero forever.
On reflection my fix is over the top - it has the effect of overriding
the value of NameWithVirtualHost set by the user.
I don't think perl_handler should be changing NameWithVirtualHost *AT ALL*,
that should be left up to the user, with a default in Registry.pm.
it used to be that way, but moved to perl_handler because it's a quicker
check in C, and multiple modules (besides Apache::Registry) need this
logic.
I attach patches to do that. They work for me.
thanks. I'll revisit this soon.
One last query, what about ApachePerlRun_namespace in PerlRunXS.xs, that
seems to think that the mere existence of the variable NameWithVirtualHost
implies that names should be modified with the virtualhost. It doesn't
check the *VALUE* of the variable:
that's okay, I don't think anybody is using PerlRunXS, I'd be surprised if
it still works at all. if there's to be a xs/c version ala PerlRunXS,
it's put off until modperl-2.0
Re: Suggested improvements to RegistryLoader.pm - stuff for virtualhosts
On Wed, 19 Jan 2000, John Hughes wrote: It would be nice if RegistryLoader.pm let me load a script for a virtual host in such a way that I didn't have to worry about how they were represented. Something like: my $r = Apache::RegistryLoader-new; $r-handler($uri, $filename, $virthost); looks good to me, thanks John!
Re: Problems w/ CGI under mod_perl
perhaps you should call
Apache-request-new($r)-register_cleanup(\CGI::_reset_globals);
there is no Apache::new method
the problem here (which has come up many times in the past), is that
CGI.pm uses the Apache-request method to get a reference to the global
$r. this normally isn't set until the response phase, unless you do it
yourself, which can be done with a line of config like so:
PerlPostReadRequestHandler 'sub { Apache-request(shift) }'
Re: horrible memory consumption
have a look at the Apache::Status in the cvs tree, there are hooks into B::TerseSize which is used to measure Perl memory usage. On Wed, 19 Jan 2000, Jason Terry wrote: Is there a way I can tell where my memory usage is going in an Apache child? I have a server that starts with acceptable numbers, but after a while it turns into this Server Version: Apache/1.3.9 (Unix) mod_perl/1.21 PHP/3.0.12 mod_ssl/2.4.4 OpenSSL/0.9.4 Redhat Linux: 2.2.13 PID USER PRI NI SIZE RSS SHARE LC STAT %CPU %MEM TIME COMMAND 9666 nobody-1-1 38900 37M 67681S0.07.5 6:57/usr/local/apache/bin/httpd 9665 nobody-1-1 35728 34M 62401S0.06.9 5:57/usr/local/apache/bin/httpd 9663 nobody-1-1 35312 34M 64121S0.06.8 6:11/usr/local/apache/bin/httpd Now I examined these children using /server-status and they had all recieved more than 7000 accesses for each child. Is there a way I can find out where all this RAM is being used. Or does anyone have any suggestions (besides limiting the MaxRequestsPerChild)
Re: send_fd and timeout problem
On Thu, 20 Jan 2000, Martin Lichtin wrote:
Doug MacEachern wrote:
mod_perl doesn't set it's own alarm when $r-send_fd is called. did you
call $r-print or print before hand?
Hmm, no, I do something like this:
$r-content_type('application/octet-stream');
my($size) = -s $fh;
$r-header_out('Content-Length', $size);
$r-send_http_header;
$r-send_fd($fh, $size);
close($fh);
you must be seeing logs from another process, none of those calls set an
'Apache-print' timeout.
Re: Performance ?'s regarding Apache::Request
On Thu, 20 Jan 2000, Clifford Lang wrote: mod_perl 1.21 Apache 1.3.9 Solaris 2.5.1, Linux 6.0 Is this a good or bad idea? I want to create an inheritable module based on Apache::Request mainly for uploading files, then create individual PerlHandler modules for individual page content. If I do this, will the uploaded files end up increase the memory consumption of the module, or is all memory freed after the fileupload process? Apache::Request reads the uploaded file in 4K chunks and saves it to a tmpfile, just as CGI.pm does. you shouldn't see the process grow to the size of the file unless you've hit a bug we don't know about.
Re: Can't exec programs ?
On Thu, 20 Jan 2000, Pierre-Yves BONNETAIN wrote: [EMAIL PROTECTED] said: you'll get a better idea of the problem running strace (or truss) against the server. in any case, you should avoid any code that's forking a process, since it's throwing performance out the window. Is there a 'nice way' (meaning, a patch or manual change I can do to those modules) to prevent forking or, rather, replace it by stg else that gets me the same thing ? I can spend (a lot of) time looking for system() and backticks in the modules I use, but if I need the functionnality how can I 'correct' the code of those modules ? I don't know of a tool to help with this, you just need to keep an eye on things with strace or truss and weed out the forking code.
Re: problem
On Thu, 20 Jan 2000, Etienne Pelaprat wrote: Hi All, I've hit a problem that I can't seem to rectify. I compile mod_perl with EVERYTHING=1, but in one of my modules, I get the error: [Wed Jan 19 20:30:05 2000] null: Rebuild with -DPERL_STACKED_HANDLERS to $r-push_handlers at /usr/local/apache/lib/perl/Apache/BOSCIndex.pm line 37. make sure the rebuilt httpd is the one you're using now. that's bitten plenty of us in the past. EVERYTHING=1 does enable stacked handlers. if you rebuild again, be sure to start with freshly unpacked source trees of both mod_perl and Apache.
Re: problem
On Thu, 20 Jan 2000, Cliff Rayman wrote: unfortunately PERL_STACKED_HANDLERS used to be experimental and therefore EVERYTHING includes just about EVERYTHING except PERL_STACKED_HANDLERS. i think you need to add PERL_STACKED_HANDLERS=1 to your long list of Makefile.PL parameters. this has been discussed in the mail archives so you can search there and you'll find the original message from Doug. no, PERL_STACKED_HANDLERS is including with EVERYTHING=1
Re: CGI.pm and QUERY_STRING fixup
On Mon, 24 Jan 2000, Bill Moseley wrote:
...
Under mod_cgi I can clean up $ENV{QUERY_STRING} at the start of a program
by removing leading '' and double '', but that doesn't work, obviously,
under mod_perl.
Could someone suggest a way to clean up the query string from within an
Apache::Registry script? Is it possible to just write a cleaned up query
string to args() at the start of my Registry script, or is that too late in
the request?
PerlFixupHandler would be the best place to fixup $r-args
Re: CGI.pm and QUERY_STRING fixup
On Tue, 25 Jan 2000, Bill Moseley wrote: Ok, this seems to work, but perldoc Apache doesn't say anything about setting it. Is this at risk of not working in the future? you can set $r-args, that won't be going away in the future.
Re: Apache::AuthCookie takeover?
On Tue, 25 Jan 2000, Ken Williams wrote: Can someone set the maintainer of Apache::AuthCookie to be me? patch below :) thanks Ken!! diff -u -u -r1.63 apache-modlist.html --- apache-modlist.html 1999/11/24 02:40:01 1.63 +++ apache-modlist.html 2000/01/27 05:19:27 @@ -114,7 +114,7 @@ * PerlAuthenHandler's AuthAnybdpfAuthenticate with any username/password MPB AuthenCachebmpfCache authentication credentialsJBODNAR -AuthCookie bdpOAuthen + Authz via cookies EBARTLEY +AuthCookie bdpOAuthen + Authz via cookies KWILLIAM AuthenDBI bmpOAuthenticate via Perl's DBI MERGL AuthExpire i Expire Basic auth credentials DOUGM AuthenGSS cdpfGeneric Security Service (RFC 2078) DOUGM
Re: self url
On Wed, 26 Jan 2000, Vladimir Ivaschenko wrote: Hello, Is there a way to get the URL of the current document in Embperl? Sort of like $q-self_url in CGI.pm. from chapter 9 of wrapmod: If the URI argument is omitted, the Iparse() method will construct a fully qualified URI from B$r object, including the scheme, hostname, port, path and query string. Example: my $self_uri = Apache::URI-parse($r);
Re: numerous segv's, bus errors
On Wed, 26 Jan 2000, Steven Parkes wrote: We've been getting many segv's and bus errors on apache processes since adding modperl. Env: Apache 1.3.11 (though we had the same thing under 1.3.9.), Perl 5.005003, modperl 1.21, hpux 11.00. At first most of the failures were coming within visit() during what looks to be clean up of children. PerlFreshRestart is Off. I added PerlSetEnv PERL_DESTRUCT_LEVEL -1 and that seemed to get rid of many of those though this seems like a less than optimal solution and I'd like to better understand what the real issue is here. Moreover, we still see a number of failures. Many seem to occur in __errno. (gdb) bt #0 0xc01ecb88 in kill () from /usr/lib/libc.2 #1 0x769c8 in sig_coredump () from /usr/local/alpha/apache/bin/httpd #2 signal handler called #3 0xc0179214 in __errno () from /usr/lib/libc.2 #4 0xc01751bc in free () from /usr/lib/libc.2 #5 0x10013c in Perl_safefree () from /usr/local/alpha/apache/bin/httpd #6 0x112248 in Perl_sv_clear () from /usr/local/alpha/apache/bin/httpd #7 0x112478 in Perl_sv_free () from /usr/local/alpha/apache/bin/httpd a buggy xs modules or c library that overwrites memory can trigger these problems, seemingly random core dumps in free() or malloc(). do you have a tool such as purify or insure? they can often identify the problem right away. otherwise, we need to know more about your setup to help, what modules you're using, etc.
Re: Results of calling perl_shutdown in mp_dso_unload
On Wed, 26 Jan 2000, Daniel Jacobowitz wrote: Here's a question - an apache patch should be able to mark the module as not-to-unload (although since it should be not-to-unload-unless-removed-from-config it would be a bit more complicated than that - still not impossible). But is that worthwhile or should we just adjust to being unloaded if built as DSO? I think both options would be nice to have. Which reminds me - the CVS instructions linked from perl.apache.org no longer work. Is there a public CVS archive still? Where did it move? things have changed recently, here's a snippet from the latest mod_perl_cvs.pod: =item anoncvs To checkout a fresh copy from anoncvs use cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login with the password "anoncvs". cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl For a basic introduction to anoncvs see http://dev.apache.org/anoncvs.txt
Re: Results of calling perl_shutdown in mp_dso_unload
On Jan 26, Doug MacEachern wrote: =item anoncvs To checkout a fresh copy from anoncvs use cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" login with the password "anoncvs". cvs -d "pserver:[EMAIL PROTECTED]:/home/cvspublic" co modperl Both of those should have another colon before the pserver. Like: cvs -d ":pserver:[EMAIL PROTECTED]:/home/cvspublic" login Jim
Re: using socket on NT's mod-perl
Huan He wrote: Hello All, Does anyone ever write a TCP socket program in mod-perl module on NT ? In my program, I use socket in phase PerlAccessHandler to connect to a remote socket server, the socket in mod-perl can be opened and connected, but when I try to write message to the remote server, the server socket always receives null. But if I use the same section code of mod-perl in a normal standalone perl program, it works fine. Does anyone know why ? I had this problem too when I had more than 1 ThreadsPerChild, set this to 1 and you should be fine. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
