reloading PerlHandlers
Hi all, Firstly, I apologize if this comes up frequently, I did try to find it in the archives/FAQs. I just started playing with PerlHandlers, much simpler, faster and alot more fun than I expected! But, when I tweak the code of a module I have to do an apachectl graceful or something, very annoying. Now, I guess there's PerlFixupHandler or something, but there are also a bunch of Apache children with their own version of the module... Anyway, someone must have done this somewhere :) TIA -- Do what thou wilt shall be the whole of the Law. Love is the law, love under will. PGP signature
Re: reloading PerlHandlers
Hi there, On Thu, 10 Aug 2000, Rafael Kitover wrote: Firstly, I apologize if this comes up frequently, I did try to find it in the archives/FAQs. Not terribly hard, apparently. But, when I tweak the code of a module I have to do an apachectl graceful or something, very annoying. (and perferctly normal:) http://perl.apache.org/guide 73, Ged.
Re: mod_perl rules! updated stats
On Thu, 10 Aug 2000, Billy Donahue wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10 Aug 2000, Randal L. Schwartz wrote:
Ask On 8 Aug 2000, Randal L. Schwartz wrote:
$VERSION = (qw$Revision: 1.6 $ )[-1];
Ask in 4 revisions you would have regretted that if you actually used
Ask the $VERSION for anything, no?
Then it's time for version 2! :)
This raises an interesting question...
Is it possible to integrate the new perl-5.6.0 `v4.2.20' version-quoting
with CVS tags?
That's easy. I always use the following code:
$Apache::VMonitor::VERSION = do { my @r = (q$Revision: 1.2 $ =~
/\d+/g); sprintf "%d."."%02d" x $#r, @r };
So now you add "v." in the format part and you are all set!
$Apache::VMonitor::VERSION = do { my @r = (q$Revision: 1.2 $ =~
/\d+/g); sprintf "v.%d."."%02d" x $#r, @r };
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: PerlCleanupHandler
Hi,
Michael Peppler wrote:
We're seeing a number of requests where the write from apache to the
client browser times out and the SIGALRM signal fires. Our
Apache::Registry scripts in that case don't clean up correctly,
leaving session lock files around, which of course causes that
particular session to be screwed up for a while.
My question is would a Cleanup handler still be called in this case?
( I'm asking because it's a large site, and I can't just add code left
and right... :-)
I've seen something similar - when the client browser times out,
execution seems to stop mid-Print statement, and mod_Perl gets ready for
the next request, without cleaning up objects present (or, at least,
without calling -DESTROY).
IIRC, "END" blocks are called by mod_Perl, rather than Perl itself,
since Perl normally calls them only when the interpreter is about to
shut down. END blocks still get called in this situation, so if you run
foo.pl and manage to hit stop before it's printed its output...
my $object = new Foo::Bar;
# blah blah blah
print "The answer is ", $object-answer;
sub END { warn "bye!\n" };
and in Bar.pm
sub DESTROY { warn "outta here!\n" };
... you get "bye!" in the error log, but not "outta here!".
This obviously plays merry hell with database handles on transactioned
databases, session locks, etc.
I don't know for sure if SIGALRM is involved in this, though that seems
plausible.
My guess is that if END gets called, so will a cleanup handler.
More disturbingly, there seem to be very occasional cases where the
cleanup stuff doesn't do what's expected of it, so I suggest you keep an
eye on what's happening. Our current workaround - not a good one - is to
kill $$ when objects don't get cleaned up correctly.
Hope this helps...
--
Tim Sweetman
A L Digital
"When in Rome, burn it!"
Re: reloading PerlHandlers
In-Reply-To: 2810230556.A628@isis But, when I tweak the code of a module I have to do an apachectl graceful or something, very annoying. perldoc Apache::StatINC and read the guide: http://perl.apache.org/guide/ Jon
RFC: Apache::Reload
This dates back to discussions nearly a year ago now, from Randal's
initial Stonehenge::Reload, and Doug saying he'd like to see a more
generic Apache::Reload that got rid of the necessity to call reload_me in
your own code... Anyway, I needed this facility too, since I wanted
modules to be able to just "use Apache::Reload" and have them reloaded,
without having to call something myself in some sort of
handler() function, because 90% of my modules don't use a handler() entry
point... So I came up with Apache::Reload based mostly on Apache::StatINC
and partly on Stonehenge::Reload, here's the code, comments welcome:
package Apache::Reload;
use strict;
$Apache::Reload::VERSION = '0.01';
my %Stat; # = ($INC{"Apache/Reload.pm"} = time);
my %INCS;
sub import {
my $class = shift;
my ($package,$file) = (caller)[0,1];
$package =~ s/::/\//g;
$package .= ".pm";
warn "Apache::Reload: $package loaded me\n";
if (grep /^off$/, @_) {
delete $INCS{$package};
}
else {
$INCS{$package} = $file;
}
}
sub handler {
my $r = shift;
my $do_undef = ref($r)
(lc($r-dir_config("UndefOnReload") || '') eq
'on');
my $DEBUG = ref($r) (lc($r-dir_config("ReloadDebug") || '') eq
'on');
while (my($key, $file) = each %INCS) {
local $^W;
warn "Apache::Reload: Checking mtime of $key\n" if $DEBUG;
my $mtime = (stat $file)[9];
warn("Apache::Reload: Can't locate $file\n"),next
unless defined $mtime and $mtime;
unless (defined $Stat{$file}) {
$Stat{$file} = $^T;
}
if ($mtime $Stat{$file}) {
if ($do_undef and $key =~ /\.pm$/) {
require Apache::Symbol;
my $class =
Apache::Symbol::file2class($key);
$class-Apache::Symbol::undef_functions(undef, 1);
}
delete $INC{$key};
require $key;
warn("Apache::Reload: process $$ reloading
$key\n")
if $DEBUG;
}
$Stat{$file} = $mtime;
}
return 1;
}
1;
__END__
=head1 NAME
Apache::Reload - Reload this module on each request (if modified)
=head1 SYNOPSIS
In httpd.conf:
PerlInitHandler Apache::StatINC
Then your module:
package My::Apache::Module;
use Apache::Reload;
sub handler { ... }
1;
=head1 DESCRIPTION
This module is an adaptation of Randall Schwartz's Stonehenge::Reload
module that attempts to be a little more intuitive and makes the usage
easier. Like Apache::StatINC it must be installed as an Init Handler,
but unlike StatINC it must also be used by the module you want reloading.
If you want to temporarily turn off reloading of a module (which is
slightly problematic since it won't happen until the next hit on the
same server because of the way this thing works) you can use the 'off'
option:
use Apache::Reload 'off';
Obviously you wouldn't do that generally, but it can be useful if you
intend to make large changes to a particular module.
=head1 AUTHOR
Matt Sergeant, [EMAIL PROTECTED]
=head1 SEE ALSO
Apache::StatINC, Stonehenge::Reload
=cut
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
RE: Apache::Reload
you may have missed the conversation yesterday on modperl-dev, but just to
recap...
it just came up that Apache::Symbol::undef_functions really isn't needed any
more. That is, 5.004+ avoids the manditory 'subroutine redefined' warnings
and makes then not-manditory. Thus local $^W stops the warnings. I was just
dealing with this with Dispatch.pm and have already removed it in the next
version. Also, the presence of Apache::Symbol is up in the air in 2.0,
possibly to be included for back-compat, though...
just FYI
--Geoff
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 11, 2000 7:13 AM
To: [EMAIL PROTECTED]
Subject: RFC: Apache::Reload
This dates back to discussions nearly a year ago now, from Randal's
initial Stonehenge::Reload, and Doug saying he'd like to see a more
generic Apache::Reload that got rid of the necessity to call
reload_me in
your own code... Anyway, I needed this facility too, since I wanted
modules to be able to just "use Apache::Reload" and have them
reloaded,
without having to call something myself in some sort of
handler() function, because 90% of my modules don't use a
handler() entry
point... So I came up with Apache::Reload based mostly on
Apache::StatINC
and partly on Stonehenge::Reload, here's the code, comments welcome:
package Apache::Reload;
use strict;
$Apache::Reload::VERSION = '0.01';
my %Stat; # = ($INC{"Apache/Reload.pm"} = time);
my %INCS;
sub import {
my $class = shift;
my ($package,$file) = (caller)[0,1];
$package =~ s/::/\//g;
$package .= ".pm";
warn "Apache::Reload: $package loaded me\n";
if (grep /^off$/, @_) {
delete $INCS{$package};
}
else {
$INCS{$package} = $file;
}
}
sub handler {
my $r = shift;
my $do_undef = ref($r)
(lc($r-dir_config("UndefOnReload") || '') eq
'on');
my $DEBUG = ref($r)
(lc($r-dir_config("ReloadDebug") || '') eq
'on');
while (my($key, $file) = each %INCS) {
local $^W;
warn "Apache::Reload: Checking mtime of $key\n"
if $DEBUG;
my $mtime = (stat $file)[9];
warn("Apache::Reload: Can't locate $file\n"),next
unless defined $mtime and $mtime;
unless (defined $Stat{$file}) {
$Stat{$file} = $^T;
}
if ($mtime $Stat{$file}) {
if ($do_undef and $key =~ /\.pm$/) {
require Apache::Symbol;
my $class =
Apache::Symbol::file2class($key);
$class-Apache::Symbol::undef_functions(undef, 1);
}
delete $INC{$key};
require $key;
warn("Apache::Reload: process $$ reloading
$key\n")
if $DEBUG;
}
$Stat{$file} = $mtime;
}
return 1;
}
1;
__END__
=head1 NAME
Apache::Reload - Reload this module on each request (if modified)
=head1 SYNOPSIS
In httpd.conf:
PerlInitHandler Apache::StatINC
Then your module:
package My::Apache::Module;
use Apache::Reload;
sub handler { ... }
1;
=head1 DESCRIPTION
This module is an adaptation of Randall Schwartz's Stonehenge::Reload
module that attempts to be a little more intuitive and makes the usage
easier. Like Apache::StatINC it must be installed as an Init Handler,
but unlike StatINC it must also be used by the module you
want reloading.
If you want to temporarily turn off reloading of a module (which is
slightly problematic since it won't happen until the next hit on the
same server because of the way this thing works) you can use the 'off'
option:
use Apache::Reload 'off';
Obviously you wouldn't do that generally, but it can be useful if you
intend to make large changes to a particular module.
=head1 AUTHOR
Matt Sergeant, [EMAIL PROTECTED]
=head1 SEE ALSO
Apache::StatINC, Stonehenge::Reload
=cut
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
libc.so.6 ??
I am installing mod_perl using mod_perl-1.24-4.i386.rpm, but i have a failed dependency, it is looking for libc.so.6. I cant find this anywhere, i can only source libc.so.5 , can some1 tell me where i can find this please ? , thanks Regards, P.
[ANNOUNCE] DB_File-Lock-0.04.tar.gz (bugfix release)
Hi, The URL http://www.davideous.com/dbfilelock/DB_File-Lock-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DH/DHARRIS/DB_File-Lock-0.04.tar.gz size: 6488 bytes md5: a948d5213826eef0b335617531330387 This module was originally developed to provide proper locking for DB_File for use with mod_perl. For more info about DB_File locking see: http://perl.apache.org/guide/dbm.html#Flawed_Locking_Methods_Which_Mus From the Changes file: 0.04 Fri Aug 11 09:08:48 EDT 2000 - Three good fixes from Robert Mathews [EMAIL PROTECTED]. (Thanks to him for submitting a patch!) In his own words: (1) The first one is nothing big: test 16 fails with BerkeleyDB v1.85 on solaris 5.6. This seems to be due to the fact that we're creating a database (and therefore writing to it), but it's only read-locked. (2) The second is that TIEHASH assumes that SUPER::TIEHASH will succeed. If it doesn't, the lockfile gets left open, and DESTROY is never called to close it. (3) I ran into one other issue: umask isn't restored if sysopen on the lockfile fails. Fixed that too. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
Re:[OT][JOB] mod_perl coders welcome at Quios
On Thu, 10 Aug 2000, Tom Mornini wrote: I've recently been promoted to Manager, Engineering at Quios. Congratulations, Tom. __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Apache::Session manpage
With 1.50 Apache::Session::DBI is gone, but I still see it in the manpage. I was just confused by this a few hours. Is it already scheduled for removal? I'm using 1.51. -kenneth
parsing SSI in cgi scripts?
Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) /Vlad
Win32: system() calls with STDOUT re-directed
I've finally solved a problem which I've had for a long time which may be of interest. I know some people looked at it for me at the time, including Randy Kobes. The problem was that the following script did not correctly execute it's system() call. The ip.txt file was never written and the status was set to 256. Running under CGI the file was written and the status was 0. (The problem never occurred if STDOUT from the ipconfig program is not re-directed to a file.) $| = 1; $pg = "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; $pg .= "The system call exited with status $status.\n"; print $pg; I've found that since re-building everything with the inclusion of mod_ssl (2.6.5) the problem goes away! I kept everything else the same (Perl 5.6.0, Apache 1.3.12, mod_perl 1.24 on NT4 SP6). I wonder if this is anything to do with the EAPI (extended API) which mod_ssl patches the Apache core code with, since I don't actually need to *use* mod_ssl, just build with it - i.e. I don't even need to have a "LoadModule ssl_module modules/ApacheModuleSSL.dll" line in my httpd.conf file! It could also explain why other people were unable to re-produce my problem. Randy: I think you looked at this for me around the beginning of April and couldn't re-produce it. Do you think you had mod_ssl included in your build? Does this have any other implications for mod_perl??? Does mod_perl need the EAPI like mod_ssl does (at least on Win32)??? Steve Hay
RE: parsing SSI in cgi scripts?
check out Apache::Filter + Apache::SSI - both on CPAN --Geoff -Original Message- From: Vladislav Safronov [mailto:[EMAIL PROTECTED]] Sent: Friday, August 11, 2000 11:59 AM To: [EMAIL PROTECTED] Subject: parsing SSI in cgi scripts? Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) /Vlad
socket buffering and the need for front-end proxies
[ feel free to use any of this in the mod_perl guide... ]
I've seen in previous threads about sockets and buffering that there was
some confusion in the area, and that it was not clear in anyone's mind
just which socket operations in the server (write(), close()) can block
when the client is on a slow link, and just what help the kernel
buffering gives. So I decided to do some tests, with little perl
scripts talking to each other (via IO::Socket's), and using strace -tt
-T for timing. This is all under Linux btw, with kernel 2.2.15.
This is pretty important, because it lets us decide whether a front-end
server is needed; if things can be setup so that the backend generates
the page, leaves the kernel to spoonfeed it to the slow client, and is
immediately free to go on, then a front-end reverse proxy shouldn't be
needed.
The tests consisted of a client process that connects to a server,
sleeps for a few seconds, then reads from the network. The server
write()s a configurable amount of data, and strace tells us how long the
write() calls took (I never saw close() block).
The results, depending on the size (n) of the written data, are:
n 57900 : less than 1.3ms
n = 6 : 6ms
n = 7 : 25ms
n 118000 : as long as the client's sleep()
This shows quite clearly that the server's kernel buffer is about 58k,
and the client's kernel read buffer is another 58k. This is a 10baseT
lan; to simulate a slow client, I added some sleep()s on both sides just
after the connection, and used them to pull the ethernet plug on the
client for a few seconds, so the first write() happens while the client
is disconnected. The results (measuring the write() blocking time
again) confirmed this:
n 57900 : less than 1.3ms
n 58000 : for as long as the client is disconnected, plus a few
tenths of second (interestingly enough, the delay here
is always an integer number of seconds; Linux must be
retrying its sends once a second).
These 58k are related to the socket's SO_SNDBUF, which is set by default
to 64k. This is good to know too: under Linux 2.2 there's a 6k
discrepancy between the SO_SNDBUF value and how much you can actually
write() without blocking.
This is all nicer than I was expecting: the kernel actually lets the
server do a write() followed by a close(), both in no time (less than
1ms), as long as the write length is less than the socket's SO_SNDBUF.
(I was sort of expecting close() to block until the data was sent).
Since SO_SNDBUFs are configurable (SendBufferSize in Apache, and
/proc/sys/net/core/wmem_{default,max} under Linux), then the obvious
conclusion would be, as long as your documents are of reasonable length
(say, less than 50k) and you tune /proc/sys/net/core/wmem_* and
SendBufferSize high enough, there shouldn't be any need for a front-end
server.
BUT, there's more!
Doing the same tests again, but with an actual Apache as the server, and
with keep-alives turned off (as they should generally be with mod_perl),
it turns out Apache does a lingering close, which is a 2-second select
for read on the client socket. On a fast lan, the client gets the
"Connection: close", reads the data, closes the socket, in a few tenths
of seconds at most. On a slow connection, you can't be sure. My guess
is that the client won't close its socket until it has read the data,
which can easily take a few seconds, so Apache's lingering close would
time out and Apache would wait the 2 seconds, then close() the socket
and go on to the next client.
So the "less obvious" conclusion seems to be that a proxy server is
worth it, if and only if lingering closes are actually lingering for a
significant amount of time in average. 2 seconds is significantly
longer than the time it takes to process a request, after all.
Has anyone looked into that? If not, I can try to find a moment to log
the lingering_close times on a real server...
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
Re: proxying name-based virtual hosts
On Thu, Aug 10, 2000 at 12:08:53PM -0500, Dan Rench wrote: I ended up adding this to mod_proxy_add_forward.c: ap_table_set(r-headers_in, "X-Original-Host", ap_table_get(r-headers_in, "Host")); (right after the line that adds the "X-Forwarded-For" header). [ ... ] thanks, that is more or less what it was thinking of doing, it's good to know in advance that it works :) -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Exceptions section dropped?
I went to patch the exceptions section of the guide 1.22, and found it gone... Has it been dropped permanently or been misplaced? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Strange error in log: Attempt to free unreferenced scalar.
Hello all! I have the following problem with Apache mod_perl and MySQL. We have written Web chat server based on: FreeBSD+Apache+mod_perl+MySQL. Hardware: 2xPIII 550, 1Gb RAM Also there are PostgreSQL and exim for other tasks on that machine. We use 2 httpd scheme: one "light" for handling static content (without mod_perl) and another one with mod_perl. First uses proxy to pass requests to /script directory to mod_perl enabled "heavy" httpd - httpd.modperl. I have test program called "Load Emulator" that can send HTTP requests with certain rate. I sends 5 requests/sec to chat scripts. First all things are good. But suddenly httpd.modperl begin to spawn and reach the maximum number of processes that I set - 50. This means that summary memory usage of httpd.modperl processes is about 500M! Then "heavy" Apache stop to respond to clients - I run my browser and see "Proxy Error". When I stop Load Emulator, such situation continue in about a 5-10 minutes, then httpd.modperl processes begin to die. During this mysqld eats about 5-10% CPU and 140M RAM. I see strange error in httpd.modperl error log : Attempt to free unreferenced scalar. No line number, no script name, nothing more. Maybe someone knows, what's the matter and how I can solve such strange problem? Sincerely yours, Vladimir Buyanov, senior web-developer Agama Internet Systems http://www.aport.ru http://www.agama.com
Re: Apache::ASP the case of disappearing prolog
Yes, this is a xml parser bug, I'll check this out in a couple weeks when I get back from vacation. --Joshua --- Dmitry Beransky [EMAIL PROTECTED] wrote: Consider the following markup: %@language="PerlScript"% % my $prolog= '?xml version="1.0" encoding="ISO-8859-1"? !DOCTYPE xform [ !ATTLIST string name ID #REQUIRED !ATTLIST group name ID #REQUIRED ]'; % html body Prolog: pre%=$Server-HTMLEncode($prolog)%/pre /body /html when I run this, the XML declaration is missing in the output. I think this is somehow related to the XMLSubsParser. Not sure if my diagnosis is correct, but I can fix the problem by breaking the declaration into two pieces. I think this should be considered a bug. Cheers Dmitry __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Re: parsing SSI in cgi scripts?
[EMAIL PROTECTED] (Vladislav Safronov) wrote: Hi, Is there way for processing SSI commands in perl? (my templates may contains SSI commands, so what should I do - just type in real html or process them somehow?) Check out Apache::SSI. It can solve the problem. Can be used with Apache::Filter or by instantiating an Apache::SSI object directly.
Re: RFC: Apache::Reload
On Fri, 11 Aug 2000, Matt Sergeant wrote: This dates back to discussions nearly a year ago now, from Randal's initial Stonehenge::Reload, and Doug saying he'd like to see a more generic Apache::Reload that got rid of the necessity to call reload_me in your own code... Anyway, I needed this facility too, since I wanted modules to be able to just "use Apache::Reload" and have them reloaded, without having to call something myself in some sort of handler() function, because 90% of my modules don't use a handler() entry point... So I came up with Apache::Reload based mostly on Apache::StatINC and partly on Stonehenge::Reload, here's the code, comments welcome: I'm going to take a lack of negative replies as positive... I'll upload to CPAN later. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Strange error in log: Attempt to free unreferenced scalar.
Hi, On Fri, Aug 11, 2000 at 11:16:10PM +0400, Vladimir Buyanov wrote: I have the following problem with Apache mod_perl and MySQL. We have written Web chat server based on: FreeBSD+Apache+mod_perl+MySQL. Hardware: 2xPIII 550, 1Gb RAM Also there are PostgreSQL and exim for other tasks on that machine. We use 2 httpd scheme: one "light" for handling static content (without mod_perl) and another one with mod_perl. First uses proxy to pass requests to /script directory to mod_perl enabled "heavy" httpd - httpd.modperl. I have test program called "Load Emulator" that can send HTTP requests with certain rate. I sends 5 requests/sec to chat scripts. First all things are good. But suddenly httpd.modperl begin to spawn and reach the maximum number of processes that I set - 50. This means that summary memory usage of httpd.modperl processes is about 500M! Fifty seems like a heck of a lot of heavy apaches. Chances are you'd only hit that number when Bad Things are happening and a number that high just makes things worse. What happens if you change maxclients to ... ten, say? Then "heavy" Apache stop to respond to clients - I run my browser and see "Proxy Error". When I stop Load Emulator, such situation continue in about a 5-10 minutes, then httpd.modperl processes begin to die. During this mysqld eats about 5-10% CPU and 140M RAM. Sounds like your heavy web pages are taking too long to generate. I'd be inclined to blame any sql in there - find which queries are taking too much time and tune them. This is probably best discussed on a MySQL list, though... :-) Attempt to free unreferenced scalar. Yeah, we get those too. I don't know what they are either. *grin* Running without perlfreshrestart/graceful-restarts seems to help, but this cure is worse than the disease - we just put up with the slight memory leaks associated with the occasional graceful restart and do a hard restart every week or two. It's only a minor niggle and someday I'll sort it out! All the best, Wesley.
Re: Apache 1.3.12/mod_perl 1.24/Perl 5.6.0 crash
Let me try this again.
Recap:
I have Apache 1.3.12 using mod_perl 1.24 as a DSO, built with Perl 5.6.0
using Apache::AutoIndex 0.08 which is running on Linux 2.2.14.
Everything works fine, until, I `apachectl stop`, then add the following to
the httpd.conf:
PerlModule Apache::AutoIndex
When I do `bin/httpd -X` Linux does a core dump.
Has anyone tried this configuration with AutoIndex.pm with either
successful or with problems?
The following is the gdb bt listing:
=
(gdb) bt
Program received signal SIGSEGV, Segmentation fault.
0x8054b09 in ap_remove_module ()
(gdb) bt
#0 0x8054b09 in ap_remove_module ()
#1 0x8054bdf in ap_remove_loaded_module ()
#2 0x804f2cc in unload_module ()
#3 0x805126e in run_cleanups ()
#4 0x804f910 in ap_clear_pool ()
#5 0x8060683 in standalone_main ()
#6 0x8060f23 in main ()
#7 0x2ab304a5 in __libc_start_main () from /lib/libc.so.6
#8 0x815b in ?? ()
Cannot access memory at address 0xe853.
The following is tail end of a verbose strace ouput during a core dump.
=
open("/usr/local/apache/logs/error_log.test", O_WRONLY|O_APPEND|O_CREAT,
0666) = 4
fcntl(4, F_DUPFD, 15) = 15
close(4)= 0
fcntl(15, F_GETFL) = 0x401 (flags O_WRONLY|O_APPEND)
fstat(15, {st_mode=S_IFREG|0644, st_size=13212, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,0) =
0x2aac
_llseek(15, 0, [0], SEEK_CUR) = 0
dup2(15, 2) = 2
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/usr/local/apache/conf/apache-mime.types", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=7374, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=7374, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,0) =
0x2aac8000
read(4, "# This is the default mime.types"..., 4096) = 4096
read(4, "m.EXT\napplication/vnd.osa.netdep"..., 4096) = 3278
brk(0x848) = 0x848
read(4, "", 4096) = 0
close(4)= 0
munmap(0x2aac8000, 4096)= 0
open("/usr/local/apache/logs/access_log.test", O_WRONLY|O_APPEND|O_CREAT,
0644)= 4
fcntl(4, F_DUPFD, 15) = 16
close(4)= 0
getpid()= 1404
time(NULL) = 965956118
close(16) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
munmap(0x2ad9d000, 14288) = 0
munmap(0x2ae0a000, 16308) = 0
munmap(0x2ae0e000, 13712) = 0
munmap(0x2ae12000, 22668) = 0
munmap(0x2ada1000, 9064)= 0
munmap(0x2ae18000, 46408) = 0
munmap(0x2ae24000, 29000) = 0
munmap(0x2ae2c000, 9736)= 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
=
The following is the tail end of a mod_perl PERL_TRACE output:
=
5: _compile();
entering CGI::_compile
665:my($func) = $AUTOLOAD;
666:my($pack,$func_name);
667:{
668:local($1,$2); # this fixes an obscure variable
suicide problem.
668:local($1,$2); # this fixes an obscure variable
suicide problem.
669:$func=~/(.+)::([^:]+)$/;
670:($pack,$func_name) = ($1,$2);
671:$pack=~s/::SUPER$//;# fix another obscure problem
673:unless defined(${"$pack\:\:AUTOLOADED_ROUTINES"});
672:$pack = ${"$pack\:\:AutoloadClass"} ||
$CGI::DefaultClass
675:my($sub) = \%{"$pack\:\:SUBS"};
675:my($sub) = \%{"$pack\:\:SUBS"};
676:unless (%$sub) {
682: my($code) = $sub-{$func_name};
684: $code = "sub $AUTOLOAD { }" if (!$code and
$func_name eq 'DESTROY');
685: if (!$code) {
695: die "Undefined subroutine $AUTOLOAD\n" unless $code;
696: eval "package $pack; $code";
697: if ($@) {
702:CORE::delete($sub-{$func_name}); #free storage
703:return "$pack\:\:$func_name";
exited CGI::_compile
2: foreach (@_) {
exited CGI::AUTOLOAD for CGI::_compile_all
exited CGI::_setup_symbols
exited CGI::compile
46: 1;
3:
entering Config::DESTROY
exited Config::DESTROY
entering IO::Handle::DESTROY
exited IO::Handle::DESTROY
Carp::(/usr/local/lib/perl5/5.6.0/Carp.pm:97):
97: { local $@; require Carp::Heavy; } # XXX fix require to not
clear $@?
Carp::(/usr/local/lib/perl5/5.6.0/Carp.pm:97):
97: { local $@; require Carp::Heavy; } # XXX fix require to not
clear
Re: Apache 1.3.12/mod_perl 1.24/Perl 5.6.0 crash
At 03:59 PM 8/11/00 -0700, you wrote: Just curious, but how did you build 5.6.0? Running 5.6.0 and mdo_perl dso, I got the same thing. Have you tried compiling it statically? On 11 Aug 2000, at 16:52, George Sanderson wrote: Let me try this again. Recap: I have Apache 1.3.12 using mod_perl 1.24 as a DSO, built with Perl 5.6.0 using Apache::AutoIndex 0.08 which is running on Linux 2.2.14. Everything works fine, until, I `apachectl stop`, then add the following to the httpd.conf: PerlModule Apache::AutoIndex When I do `bin/httpd -X` Linux does a core dump. I really like the modular nature of DSO. One benifit from the DSO is that, I can just rebuild mod_perl independently of httpd. I normally build a production and a debug version of mod_perl then start up httpd on a differnt port to toubleshoot problems. I have tried the static build in the past but not resently. Do you know if there is more success one way or the other (static vr. DSO)? I've attached the Perl 5.6.0 config.sh file. For mod_perl I used a makepl_args.mod_perl file in the src root as follows: EVERYTHING=1 #PERL_DEBUG=1 #PERL_TRACE=1 USE_APXS=1 WITH_APXS=/usr/bin/apxs #DO_HTTPD=1 #NO_HTTPD=1 #PREP_HTTPD=1 APACHE_PREFIX=/usr/local/apache APACHE_SRC=/usr/src/apache_1.3.12/src #!/bin/sh # # This file was produced by running the Configure script. It holds all the # definitions figured out by Configure. Should you modify one of these values, # do not forget to propagate your changes by running "Configure -der". You may # instead choose to run each of the .SH files by yourself, or "Configure -S". # # Package name : perl5 # Source directory : . # Configuration time: Fri Aug 11 12:29:20 CDT 2000 # Configured by : george # Target system : linux estore.xorgate.com 2.2.14 #3 sat jan 15 08:41:41 cst 2000 i586 unknown Author='' Date='$Date' Header='' Id='$Id' Locker='' Log='$Log' Mcc='Mcc' RCSfile='$RCSfile' Revision='$Revision' Source='' State='' _a='.a' _exe='' _o='.o' afs='false' alignbytes='4' ansi2knr='' aphostname='/bin/hostname' api_revision='5' api_subversion='0' api_version='5' api_versionstring='5.005' ar='ar' archlib='/usr/local/lib/perl5/5.6.0/i586-linux' archlibexp='/usr/local/lib/perl5/5.6.0/i586-linux' archname64='' archname='i586-linux' archobjs='' awk='awk' baserev='5.0' bash='' bin='/usr/bin' bincompat5005='undef' binexp='/usr/bin' bison='' byacc='byacc' byteorder='1234' c='' castflags='0' cat='cat' cc='gcc' cccdlflags='-fpic' ccdlflags='-rdynamic -Wl,-rpath,/usr/local/lib/perl5/5.6.0/i586-linux/CORE' ccflags='-fno-strict-aliasing -I/usr/local/include' ccsymbols='__GNUC_MINOR__=91 __i386=1 __i386__=1 __i686=1 __i686__=1 __linux=1 __linux__=1 __pentiumpro=1 __pentiumpro__=1 __unix=1 __unix__=1 cpu=i386 machine=i386 pentiumpro=1 system=posix system=unix' cf_by='george' cf_email='[EMAIL PROTECTED]' cf_time='Fri Aug 11 12:29:20 CDT 2000' charsize='1' chgrp='' chmod='' chown='' clocktype='clock_t' comm='comm' compress='' contains='grep' cp='cp' cpio='' cpp='cpp' cpp_stuff='42' cppccsymbols='__ELF__=1 __GNUC__=2 i386=1 i686=1 linux=1 unix=1' cppflags='-fno-strict-aliasing -I/usr/local/include' cpplast='-' cppminus='-' cpprun='gcc -E' cppstdin='gcc -E' cppsymbols='__GNUC_MINOR__=91 _POSIX_C_SOURCE=199506 _POSIX_SOURCE=1 __STDC__=1 __i386=1 __i386__=1 __i686=1 __i686__=1 __linux=1 __linux__=1 __unix=1 __unix__=1' crosscompile='undef' cryptlib='' csh='csh' d_Gconvert='gcvt((x),(n),(b))' d_PRIEldbl='define' d_PRIFldbl='define' d_PRIGldbl='define' d_PRIX64='define' d_PRId64='define' d_PRIeldbl='define' d_PRIfldbl='define' d_PRIgldbl='define' d_PRIi64='define' d_PRIo64='define' d_PRIu64='define' d_PRIx64='define' d_access='define' d_accessx='undef' d_alarm='define' d_archlib='define' d_atolf='undef' d_atoll='define' d_attribut='define' d_bcmp='define' d_bcopy='define' d_bincompat5005='undef' d_bsd='undef' d_bsdgetpgrp='undef' d_bsdsetpgrp='undef' d_bzero='define' d_casti32='undef' d_castneg='define' d_charvspr='undef' d_chown='define' d_chroot='define' d_chsize='undef' d_closedir='define' d_const='define' d_crypt='define' d_csh='define' d_cuserid='define' d_dbl_dig='define' d_difftime='define' d_dirnamlen='undef' d_dlerror='define' d_dlopen='define' d_dlsymun='undef' d_dosuid='undef' d_drand48proto='define' d_dup2='define' d_eaccess='undef' d_endgrent='define' d_endhent='define' d_endnent='define' d_endpent='define' d_endpwent='define' d_endsent='define' d_endspent='define' d_eofnblk='define' d_eunice='undef' d_fchmod='define' d_fchown='define' d_fcntl='define' d_fd_macros='define' d_fd_set='define' d_fds_bits='undef' d_fgetpos='define' d_flexfnam='define' d_flock='define' d_fork='define' d_fpathconf='define' d_fpos64_t='undef' d_fs_data_s='undef' d_fseeko='define' d_fsetpos='define' d_fstatfs='define' d_fstatvfs='define' d_ftello='define' d_ftime='undef' d_getcwd='define' d_getfsstat='undef' d_getgrent='define' d_getgrps='define' d_gethbyaddr='define' d_gethbyname='define' d_gethent='define'
Re: Apache 1.3.12/mod_perl 1.24/Perl 5.6.0 crash
George Sanderson wrote: Do you know if there is more success one way or the other (static vr. DSO)? i'd say that most of us are building statically. there have been a lot more problems with DSO builds than static ones. I've attached the Perl 5.6.0 config.sh file. For mod_perl I used a makepl_args.mod_perl file in the src root as follows: EVERYTHING=1 #PERL_DEBUG=1 #PERL_TRACE=1 USE_APXS=1 WITH_APXS=/usr/bin/apxs #DO_HTTPD=1 #NO_HTTPD=1 #PREP_HTTPD=1 APACHE_PREFIX=/usr/local/apache APACHE_SRC=/usr/src/apache_1.3.12/src perl.cfgName: perl.cfg Type: Plain Text (text/plain) -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: RFC: Apache::Reload
[EMAIL PROTECTED] (Matt Sergeant) wrote: On Fri, 11 Aug 2000, Matt Sergeant wrote: This dates back to discussions nearly a year ago now, from Randal's initial Stonehenge::Reload, and Doug saying he'd like to see a more generic Apache::Reload that got rid of the necessity to call reload_me in your own code... Anyway, I needed this facility too, since I wanted modules to be able to just "use Apache::Reload" and have them reloaded, without having to call something myself in some sort of handler() function, because 90% of my modules don't use a handler() entry point... So I came up with Apache::Reload based mostly on Apache::StatINC and partly on Stonehenge::Reload, here's the code, comments welcome: I'm going to take a lack of negative replies as positive... I'll upload to CPAN later. Hi Matt, Is it possible that this functionality should be integrated into Apache::StatInc? Perhaps with a couple of new directives to control behavior? That would be preferable to starting a new module, I think.
Fw: Apache::DBI using 'reauthenticate' instead of caching
Gentlemen: Have you had any time to look at this? I'm attatching my modified version of Apache::DBI. Please send me your comments and concerns as I would like to send this out to the mod_perl and DBI community very shortly. I thank you for your time! - Original Message - From: Jeff Horn To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Tuesday, June 20, 2000 7:50 PM Subject: RFC: Apache::DBI using 'reauthenticate' instead of caching Gentlemen: John Groenveld suggested that I run this by each of you. I have made a hack to Apache::DBI which uses the Oracle specific DBD call to $dbh-func($user, $pwd, 'reauthenticate') to maintain a single connection per Oracle database and then simply reauthenticate on the existing connection. This turns out to be 5-6 times faster than initiating a brand new connect for each script. Now, this is slower than straight Apache::DBI in an environment where the same connect string is used for every script running on a web server. However, it is a definite win in situations where database level security is being used and there are large numbers of logins! If you have any time to look at this I'd be most appreciative. I'd like to contribute this to CPAN as soon as I run it by a few more people and add a few bells and whistles. Your suggestions as to what to name the new module would also be appreciated. Currently it's implemented as a replacement for Apache::DBI (and steals the name), but before I submit it I want to rename the module (perhaps to something like Apache::DBI::Reauth). One problem that needs to be addressed before making this generally available is that I need to set DBI attributes back to their defaults and then reset any specified in the connect string before returning the database handle. This is not a problem in my current environment, but will be in a general environment. Any other problems you see with the code are appreciated! Thank you so much for your valuable time! -- Jeff Horn DBI.pm
RE: Apache::DBI using 'reauthenticate' instead of caching
very interesting. I might suggest a config option to toggle the functionality within Apache::DBI instead of a new module entirely. Or maybe including it as another module within the Apache::DBI distribution. I don't know how everyone else feels, but all the stuff in the Apache:: namespace is generic and this being largly Apache::DBI except for an Oracle specific enhancement doesn't sound like it warrants it's own thing. But certainly don't let me be the final word :) your enhancement, if user configurable within Apache::DBI, might make it possible to jump between cached or reauthenticatedconnectionson a vhosts basis. Now that's cool... BTW, I did submit a (rather ugly)fixfor a (minor but important to me) bug in Apache::DBI way back in december - it was never implemented by the author for unknown reasons - see http://marc.theaimsgroup.com/?l=apache-modperlm=94699007507299w=2for the details if you are interested. --Geoff -Original Message-From: Jeff Horn [mailto:[EMAIL PROTECTED]]Sent: Friday, August 11, 2000 1:57 PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: Fw: Apache::DBI using 'reauthenticate' instead of caching Gentlemen: Have you had any time to look at this? I'm attatching my modified version of Apache::DBI. Please send me your comments and concerns as I would like to send this out to the mod_perl and DBI community very shortly. I thank you for your time! - Original Message - From: Jeff Horn To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Tuesday, June 20, 2000 7:50 PM Subject: RFC: Apache::DBI using 'reauthenticate' instead of caching Gentlemen: John Groenveld suggested that I run this by each of you. I have made a hack to Apache::DBI which uses the Oracle specific DBD call to $dbh-func($user, $pwd, 'reauthenticate') to maintain a single connection per Oracle database and then simply reauthenticate on the existing connection. This turns out to be 5-6 times faster than initiating a brand new connect for each script. Now, this is slower than straight Apache::DBI in an environment where the same connect string is used for every script running on a web server. However, it is a definite win in situations where database level security is being used and there are large numbers of logins! If you have any time to look at this I'd be most appreciative. I'd like to contribute this to CPAN as soon as I run it by a few more people and add a few bells and whistles. Your suggestions as to what to name the new module would also be appreciated. Currently it's implemented as a replacement for Apache::DBI (and steals the name), but before I submit it I want to rename the module (perhaps to something like Apache::DBI::Reauth). One problem that needs to be addressed before making this generally available is that I need to set DBI attributes back to their defaults and then reset any specified in the connect string before returning the database handle. This is not a problem in my current environment, but will be in a general environment. Any other problems you see with the code are appreciated! Thank you so much for your valuable time! -- Jeff Horn
Re: DBD-Oracle and mod_perl
On Wed, Jul 26, 2000 at 01:54:51PM +0100, Tommy Wareing wrote: On Wed, Jul 26, 2000 at 08:27:06AM -0400, Geoffrey Young wrote: hi everyone... I was just wondering if anyone has been able to get the newer releases of DBD-Oracle to work under mod_perl? that is, using DBD-Oracle 1.04, 1.05, and 1.06, under perl 5.005 (RH6.0 standard) and DBI-1.14 I get consistently non-working results, but only when running under mod_perl. If I revert to 1.03, all is fine again... Tim's changed the Makefile.PL to include $::opt_b = 1; # try to use Oracle's own 'build' rule (it used to default to 0). Unfortunately, this has the side effect of requiring you to set LD_LIBRARY_PATH to load the libararies, and to my knowledge (not very much knowledge), there's no way to actually set this value back to 0, other than editing the script. The real problem is that for some reason the generated Makefile no longer has a -R$ORACLE_HOME/lib option on the linker command line. (Which means that the built shared object doesn't 'remember' where to find the library at runtime.) I've not had time to investigate why 'Makefile.PL -b' has that effect. I'd welcome anyone else looking into it. Tim.
