Question about mod_perl startup script
I am getting up and running a server that wants mod_perl. The instructions
talks about a startup script. I'm very new, so I don't know how I'm
supposed to get this step completed.
Do I copy the provided script to a location? Do I edit an existing script?
Do I edit some configuration file?
Thank you.
The instructions I'm following is quoted below, it is from
http://doc.otrs.org/1.1/html/install-cli.html#INSTALL-CLI-WEBSERVER
You may want to use a mod_perl startup script. Compiled modules on startup
(speed!)! Use the mod_perl startup script which comes with otrs
(scripts/apache-perl-startup.pl).
- Change the default startup script location of your httpd to
$OTRS_HOME/scripts/apache-perl-startup.pl in httpd.conf
[...]
# load all otrs modules
Perlrequire /opt/otrs/scripts/apache-perl-startup.pl
[...]
Edit the scripts/apache-perl-startup.pl script:
- Establish datababase connections on process startup (httpd).
[...]
use Apache ();
use Apache::DBI ();
Apache::DBI-connect_on_init('DBI:mysql:otrs', 'otrs', 'some-pass');
# Apache::DBI-connect_on_init($data_source, $username, $auth, \%attr)
[...]
- Change the otrs lib dir (if needed)!
[...]
# --
# set otrs lib path!
# --
use lib /path/to/otrs/;
use lib /path/to/otrs/Kernel/cpan-lib;
[...]
Nice! You will love mod_perl! ,-)
--
Wes Plate
Automatic Duck, Inc.
http://www.wesplate.com
http://www.automaticduck.com
How do you set vars via interactive startup?
Hi there,
I'm trying to figure out how one would set vars via a startup.pl script or
using PerlSections. I want to set a var on startup where I'll be prompted
and a var that I can retrieve via $r-dir_config('FOO') will get me that
value.
I've tried endless ideas, none of which are working
The most promising is using PerlSections:
Perl
use Apache::PerlSections();
$Apache::Server::SaveConfig = 1;
if ($Apache::Server::Starting) {
print Enter some value you don't want written down: ;
$mytmp::value = STDIN;
chomp $mytmp::value;
} else {
print value = '$mytmp::value'\n;
push @PerlSetVar, [Foo = $mytmp::value];
}
print STDERR Apache::PerlSections-dump();
/Perl
This is listed on
http://www.geocrawler.com/archives/3/182/2002/11/0/10255638/ and is an
example by Stas Bekman. For me, it only works if I run a single httpd via
-X (I set this in apachectl). It's something to do with the double start,
which this example is supposed to overcome.
Other things I've tried are using HTTPD=/usr/sbin/httpd `moduleargs`
$OPTIONS -c $PERLSETVAR where $PERLSETVAR is set via $2
apachectl start foopass
PERLSETVAR=PerlSetVar FOO $2
But I'm not the best shell programmer, and somehow the shell program
munges the PerlSetVar line. If I take the same output and run it via
command line:
/usr/sbin/httpd -DHAVE_SETENVIF -DHAVE_CERN_META -DHAVE_EXPIRES
-DHAVE_ACCESS -DHAVE_ASIS -DHAVE_NEGOTIATION -DHAVE_AUTH -DHAVE_IMAP
-DHAVE_USERTRACK -DHAVE_INFO -DHAVE_SSL -DHAVE_AUTH_DBM -DHAVE_AUTH_DB
-DHAVE_VHOST_ALIAS -DHAVE_ACTIONS -DHAVE_LOG_CONFIG -DHAVE_LOG_AGENT
-DHAVE_MMAP_STATIC -DHAVE_PROXY -DHAVE_PERL -DHAVE_MIME_MAGIC
-DHAVE_EXAMPLE -DHAVE_STATUS -DHAVE_PHP4 -DHAVE_LOG_REFERER -DHAVE_ALIAS
-DHAVE_MIME -DHAVE_SPELING -DHAVE_AUTOINDEX -DHAVE_USERDIR
-DHAVE_UNIQUE_ID -DHAVE_REWRITE -DHAVE_CGI -DHAVE_INCLUDE -DHAVE_DIR
-DHAVE_ENV -DHAVE_AUTH_ANON -DHAVE_DIGEST -DHAVE_HEADERS -c 'PerlSetVar
PASS foo'
It works, but that's not a good solution.
I've tried things like a set method that sets a class variable of the
handler I'm calling in startup.pl.. doesn't work.
So, I'm stumped. Any ideas? I'd be so greatful!
--
Patrick Galbraith
Senior Software Developer
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: How do you set vars via interactive startup?
On Wed, 2003-07-16 at 17:39, Patrick Galbraith wrote: I'm trying to figure out how one would set vars via a startup.pl script or using PerlSections. Is there a reason you can't just put it in a global? The dir_config() stuff is really for when you want to config something specific to a directory or virtual host. I've tried things like a set method that sets a class variable of the handler I'm calling in startup.pl.. doesn't work. Something like this doesn't work? $Some::Package::Foo = 7; - Perrin
Re: How do you set vars via interactive startup?
Yes, if I hardcode it, fine, but not via reading STDIN into a var, and then setting whatever to that var. On 16 Jul 2003, Perrin Harkins wrote: On Wed, 2003-07-16 at 17:39, Patrick Galbraith wrote: I'm trying to figure out how one would set vars via a startup.pl script or using PerlSections. Is there a reason you can't just put it in a global? The dir_config() stuff is really for when you want to config something specific to a directory or virtual host. I've tried things like a set method that sets a class variable of the handler I'm calling in startup.pl.. doesn't work. Something like this doesn't work? $Some::Package::Foo = 7; - Perrin -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Addition of directory to @INC variable via startup script/mod_perl
I currently have the following
configuration in my httpd.conf file:
PerlRequire
/usr/local/apache/conf/startup.pl Alias /perl/
/usr/local/apache/cgi-bin PerlTaintCheck
On PerlWarn
On PerlFreshRestart On
PerlTransHandler Apache::SessionManager PerlFreshRestart
On
Location
/perl SetHandler
perl-script PerlSendHeader On
PerlHandler Apache::Registry
Options
ExecCGI /Location
And here are the contents of the startup.pl
script:
#!/usr/bin/perl
use strict;
use lib
qw(/usr/local/apache/require);
use
Apache::Registry(); use CGI(); use
CGI::Session(); use CGI::Carp(); use
DBI(); use Net::LDAP();
$ENV{MOD_PERL} or die
"not running under mod_perl!";
1;
When I stop/start the server and run a
script with the following code:
foreach $item (@INC)
{ print ($item .
"br"); }
I only get the output:
/usr/local/lib/perl5/5.8.0/sun4-solaris
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl .
?? I can't seem to find any rhyme or
reason why the directory "/usr/local/apache/require" isn't on the @INC
array?
Any help is greatly
appreciated.according to all documentation I can find this should actually
work. I'm hoping that I'm doing something terribly stupid :).
thnx,
~j
Re: Addition of directory to @INC variable via startup script/mod_perl
Jason Jolly wrote:
When I stop/start the server and run a script with the following code:
foreach $item (@INC) {
print ($item . br);
}
I only get the output:
/usr/local/lib/perl5/5.8.0/sun4-solaris
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
.
?? I can't seem to find any rhyme or reason why the directory
/usr/local/apache/require isn't on the @INC array?
When do you run that script? And why do you have PerlFreshRestart on?
- Perrin
Re: [MP2] bug report startup and XML::LibXML
Hi !
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux
and it works
just fine.
I tested it with libxml2-2.4.23 and XML::LibXML 1.52
and it still segfaults.
this looks suspicious as address: 0xabababab, as you have
traced it. So it
could be a bug in the ActiveState's perl or is it a standard
one?
it is perl 58 cpan source I have rebuilt all myself debug
but the bug also happens with asperl 58
here is more precicion, I have followed the trace starting with
perl_croak :
segfault
Perl_sv_setpvn(interpreter * 0x00e7f024, sv * 0xabababab,
Perl_sv_vsetpvfn(interpreter * 0x00e7f024, sv * 0xabababab,
Perl_vmess(interpreter * 0x00e7f024, const char * 0x2818fac0
Perl_vcroak(interpreter * 0x00e7f024, const char * 0x2818fac
Perl_croak(interpreter * 0x00e7f024, const char * 0x2818fac0
`string')
---
in perl_croak
Perl_croak(interpreter * 0x00e1a024, const char * 0x2818fac0
`string') line 1350 + 17 bytes
[...]
void
Perl_croak(pTHX_ const char *pat, ...)
{
va_list args;
va_start(args, pat);
vcroak(pat, args); LINE CALLED
/* NOTREACHED */
va_end(args);
}
[...]
variable state:
+ args 0x0006efe4
+ args0x0006eff8 p
+ pat 0x2818fac0 Bizarre SvTYPE [%ld]
in perl_vcroak
Perl_vcroak(interpreter * 0x00e1a024, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
void
Perl_vcroak(pTHX_ const char* pat, va_list *args)
{
char *message;
HV *stash;
GV *gv;
CV *cv;
SV *msv;
STRLEN msglen;
if (pat) {
msv = vmess(pat, args); LINE CALLED pat and
args unchanged
if (PL_errors SvCUR(PL_errors)) {
sv_catsv(PL_errors, msv);
message = SvPV(PL_errors, msglen);
SvCUR_set(PL_errors, 0);
}
else
in perl_vmess
Perl_vmess(interpreter * 0x00e7f024, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1096
[...]
Perl_vmess(pTHX_ const char *pat, va_list *args)
{
(***)SV *sv = mess_alloc();
static char dgd[] = during global destruction.\n;
COP *cop;
sv_vsetpvfn(sv, pat, strlen(pat), args, Null(SV**), 0, Null
(bool*));
if (!SvCUR(sv) || *(SvEND(sv) - 1) != '\n') {
/*
[...]
( *** )sv is set to point to 0xabababab at this point of
program
so maybe the mess_alloc() function has failed in some way
inside mess_alloc():
STATIC SV *
S_mess_alloc(pTHX)
{
1SV *sv;
2XPVMG *any;
3if (!PL_dirty)
return sv_2mortal(newSVpvn(,0));
4if (PL_mess_sv)
return PL_mess_sv;
/* Create as PVMG now, to avoid any upgrading later */
New(905, sv, 1, SV);
Newz(905, any, 1, XPVMG);
SvFLAGS(sv) = SVt_PVMG;
SvANY(sv) = (void*)any;
SvREFCNT(sv) = 1 30; /* practically infinite */
PL_mess_sv = sv;
return sv;
}
at line 1 sv gets the following value :
- sv 0x00e7f470
sv_any 0xabababab
sv_refcnt 2880154539
sv_flags2880154539
function is exited by line 4 PL_mess_sv but I dont see its
value anywhere
hope this is clear
thanks
pascal
Accédez au courrier électronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,13 /mn) ; tél : 08 92 68 13 50 (0,34/mn)
Re: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote: Hi ! and as suggested : LIBXML2.DLL VERSION 2.4.26 XML::LibXML version 1.52 I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works just fine. I tested it with libxml2-2.4.23 and XML::LibXML 1.52 and it still segfaults. I can't reproduce the problem, and just looking at the source doesn't click anything. May be try posting your research to p5p? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[MP2] bug report startup and XML::LibXML
Hi
here is a revised complete report bug
Hi
on
SERVER_SOFTWARE: Apache/2.0.44 (Win32) mod_perl/1.99_08-dev
Perl/v5.8.0
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
everything rebuild debug
test code
---
use testxml(); (in startup.pl)
testxml
---
package testxml;
use strict;
use warnings;
use XML::LibXML();
my $base='c:/apache2/mason';
our $promod=
XML::LibXML-new-parse_string(?xml version=\1.0\?
doc/doc);
print tostring: ,$promod-toString ;
1;
problem is
output ok but apache segfault
---
here is a complete debug trace (this one is certified exact)
---
source in perl5.8.0\sv.c line 4020
[...]
void
Perl_sv_setpvn(pTHX_ register SV *sv, register const char *ptr,
register STRLEN len)
{
register char *dptr;
SV_CHECK_THINKFIRST(sv); line that makes the segfault
if (!ptr) {
(void)SvOK_off(sv);
return;
}
[...]
--
variables values
*dptr 0
len 0
ptr 0
sv (cannot be evaluated)
stack trace
Perl_sv_setpvn(interpreter * 0x00d84344, sv * 0xabababab, const
char * 0x28194f90 `string', unsigned int 0) line 4020 + 3 bytes
Perl_sv_vsetpvfn(interpreter * 0x00d84344, sv * 0xabababab,
const char * 0x2818fac0 `string', unsigned int 20, char * *
0x0006efe4, sv * * 0x, long 0, char * 0x) line
7629 + 20 bytes
Perl_vmess(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1096 + 40 bytes
Perl_vcroak(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
Perl_croak(interpreter * 0x00d84344, const char * 0x2818fac0
`string') line 1350 + 17 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0006f6e8,
clone_params * 0x0006fdf0) line 9297 + 26 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x009133e8,
clone_params * 0x0006fdf0) line 9203 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00906c8c,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00906ca4,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00906c68,
clone_params * 0x0006fdf0) line 9283 + 22 bytes
Perl_gp_dup(interpreter * 0x00d84344, gp * 0x008fba94,
clone_params * 0x0006fdf0) line 8698 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008f8614,
clone_params * 0x0006fdf0) line 9142 + 22 bytes
Perl_he_dup(interpreter * 0x00d84344, he * 0x008e62d8, char 1,
clone_params * 0x0006fdf0) line 118 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0023fb5c,
clone_params * 0x0006fdf0) line 9233 + 43 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008c813c,
clone_params * 0x0006fdf0) line 9140 + 22 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008c4950,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008c4968,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008c4944,
clone_params * 0x0006fdf0) line 9283 + 22 bytes
Perl_gp_dup(interpreter * 0x00d84344, gp * 0x008cd49c,
clone_params * 0x0006fdf0) line 8698 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x008c4980,
clone_params * 0x0006fdf0) line 9142 + 22 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0092ba80,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0092bb04,
clone_params * 0x0006fdf0) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0092ba8c,
clone_params * 0x0006fdf0) line 9283 + 22 bytes
Perl_gp_dup(interpreter * 0x00d84344, gp * 0x00930114,
clone_params * 0x0006fdf0) line 8698 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0092baf8,
clone_params * 0x0006fdf0) line 9142 + 22 bytes
Perl_he_dup(interpreter * 0x00d84344, he * 0x0091cdf4, char 1,
clone_params * 0x0006fdf0) line 118 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00847d40,
clone_params * 0x0006fdf0) line 9233 + 43 bytes
Perl_gp_dup(interpreter * 0x00d84344, gp * 0x0084bad4,
clone_params * 0x0006fdf0) line 8696 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00843c8c,
clone_params * 0x0006fdf0) line 9142 + 22 bytes
Perl_he_dup(interpreter * 0x00d84344, he * 0x008488e4, char 1,
clone_params * 0x0006fdf0) line 118 + 20 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00843c80,
clone_params * 0x0006fdf0) line 9233 + 43 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00a45c18,
clone_params * 0x0006fdf0) line 9140 + 22 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x00a45c30,
clone_params * 0x0006fdf0) line 9274 + 22 bytes
Perl_gp_dup(interpreter * 0x00d84344,
Re: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote:
Hi
here is a revised complete report bug
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works
just fine.
[...]
output ok but apache segfault
---
here is a complete debug trace (this one is certified exact)
---
source in perl5.8.0\sv.c line 4020
[...]
void
Perl_sv_setpvn(pTHX_ register SV *sv, register const char *ptr,
register STRLEN len)
{
register char *dptr;
SV_CHECK_THINKFIRST(sv); line that makes the segfault
if (!ptr) {
(void)SvOK_off(sv);
return;
}
[...]
Perl_sv_setpvn(interpreter * 0x00d84344, sv * 0xabababab, const
char * 0x28194f90 `string', unsigned int 0) line 4020 + 3 bytes
Perl_sv_vsetpvfn(interpreter * 0x00d84344, sv * 0xabababab,
this looks suspicious as address: 0xabababab, as you have traced it. So it
could be a bug in the ActiveState's perl or is it a standard one?
const char * 0x2818fac0 `string', unsigned int 20, char * *
0x0006efe4, sv * * 0x, long 0, char * 0x) line
7629 + 20 bytes
Perl_vmess(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1096 + 40 bytes
Perl_vcroak(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
Perl_croak(interpreter * 0x00d84344, const char * 0x2818fac0
`string') line 1350 + 17 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0006f6e8,
clone_params * 0x0006fdf0) line 9297 + 26 bytes
Though the good thing is that it happens on croak (something went wrong). So
perhaps you can check why does it happen in first place. I'd at the above frame.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ MP2] startup problem with XML::LibXML
hi what version of libxml2 should I use ? I tried to compile version 1.52 against versions libxml2-2.5.1 precompiled binary from xmlsoft test failed with segfault t\08findnodes.t list of failed 6-18 t\13dtd.t list of failed 11-12 if I nmake install nevertheless , apache startup problem remains. before that I tried to compile XML::LibXML 1.52 against a slightly prior version of libxml2 all test successful but the problem with apache startup remains. -- with XML::LibXML 1.54_3 more tests do not pass t\02parse...dubiousTest returned status 2 (wstat 512, 0x200)DIED. FAILED tests 221-460Failed 240/460 tests, 47.83% okayt\08findnodes...dubiousTest returned status 5 (wstat 1280, 0x500)DIED. FAILED tests 6-35Failed 30/35 tests, 14.29% okayt\11memory..skipped all skipped: no reason givent\19encodingskipped all skipped: no reason givent\20extras..okt\23rawfunctionsokFailed Test Stat Wstat Total Fail Failed List of Failed---t\02parse.t 2 512 460 240 52.17% 221-460t\08findnodes.t 5 1280 35 30 85.71% 6-352 tests skipped. - With XML::LibXML 1.53 t\08findnodesdubiousTest returned status 5 (wstat 1280, 0x500)DIED. FAILED tests 6-18Failed 13/18 tests, 27.78% okayt\11memory...skipped all skipped: no reason givent\13dtd..FAILED tests 11-12Failed 2/16 tests, 87.50% okayt\19encoding.skipped all skipped: no reason given Failed Test Stat Wstat Total Fail Failed List of Failed---t\08findnodes.t 5 1280 18 13 72.22% 6-18t\13dtd.t 16 2 12.50% 11-122 tests skipped.
Re: [ MP2] startup problem with XML::LibXML
On Sun, 26 Jan 2003, pascal barbedor wrote: hi what version of libxml2 should I use ? I tried to compile version 1.52 against versions libxml2-2.5.1 precompiled binary from xmlsoft test failed with segfault t\08findnodes.t list of failed 6-18 t\13dtd.tlist of failed 11-12 if I nmake install nevertheless , apache startup problem remains. I also found XML::LibXML had problems on Win32 against libxml2-2.5.1. before that I tried to compile XML::LibXML 1.52 against a slightly prior version of libxml2 all test successful but the problem with apache startup remains. [ ... ] I found that libxml2-2.4.26 worked OK with XML::LibXML's tests, but not latter versions (eg, 2.4.30). Christian Glahn, in a recent post on the perl-xml mailing list, also saw such problems, so it's not a Windows specific thing. I just tried making up a static XML::LibXML/XML::LibXSLT, to see if that would help any, but this still causes problems when used in a startup file. -- best regards, randy
[ MP2] startup problem with XML::LibXML
PROBLEM :
APACHE SEGFAULT WITH XML::LibXML on
WIN32
I use all in one perl + apache + modperl2 RK
binaries
but I replace c:\perl\bin\perl58.dll with
perl58.dll obtained after separately(and succesfully) compiling perl with vc6
DEBUG so that I get symbols in
perl58.dll
so the call stack gives line number in source (see
below)
everything works normally as far as I tried
prepared scripts in RK distribution, but my test.pm makes an APACHE
SEGFAULT
when used from startup.pl.
mytest.pm program
---
package mytest;
use warnings;
use XML::LibXML();
use strict;
our
$test=XML::LibXML-new-parse_string("?xml version='1.0'
encoding='iso-8859-1' ?doc/doc");
print $test-toString();
1;
-
perl mytest.pm output ok
USE from a regular CGI WORKS
USE from a registry CGI works
USE from a modperl handler (mason)
works
!!! use test(); from startup.pl output ok BUT
produces just after apache segfault
thanks
pascal
REPORT output
SERVER_SOFTWARE: Apache/2.0.43 (Win32)
mod_perl/1.99_08-dev Perl/v5.8.0 WINXP
windbg output
(590.7b4): Access violation - code c005 (first
chance)
call stack
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 00060006 , clone_params* param = 0006fdf8 )+0xf (CONV: cdecl)
[..\sv.c @ 9020]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0006f750 , clone_params* param = 0006fdf8 )+0x1252 (CONV: cdecl)
[..\sv.c @ 9262]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0095f00c , clone_params* param = 0006fdf8 )+0xeac (CONV: cdecl)
[..\sv.c @ 9203]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 00946ae0 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 00946af8 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 00946abc , clone_params* param = 0006fdf8 )+0x14a2 (CONV: cdecl)
[..\sv.c @ 9283]
perl58!Perl_gp_dup(interpreter* my_perl = 01732e54
, gp* gp = 009549c4 , clone_params* param = 0006fdf8 )+0x213 (CONV: cdecl)
[..\sv.c @ 8698]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0095110c , clone_params* param = 0006fdf8 )+0x8e6 (CONV: cdecl)
[..\sv.c @ 9142]
perl58!Perl_he_dup(interpreter* my_perl = 01732e54
, he* e = 0093e3ac , char shared = 0x1 '', clone_params* param = 0006fdf8
)+0x18e (CONV: cdecl) [..\hv.c @ 118]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0089ed58 , clone_params* param = 0006fdf8 )+0x10d4 (CONV: cdecl)
[..\sv.c @ 9233]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0091fc58 , clone_params* param = 0006fdf8 )+0x88b (CONV: cdecl)
[..\sv.c @ 9140]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0091fb64 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0091fbb0 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0091fb58 , clone_params* param = 0006fdf8 )+0x14a2 (CONV: cdecl)
[..\sv.c @ 9283]
perl58!Perl_gp_dup(interpreter* my_perl = 01732e54
, gp* gp = 009281a4 , clone_params* param = 0006fdf8 )+0x213 (CONV: cdecl)
[..\sv.c @ 8698]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0091fbc8 , clone_params* param = 0006fdf8 )+0x8e6 (CONV: cdecl)
[..\sv.c @ 9142]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0089a620 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0089a6a4 , clone_params* param = 0006fdf8 )+0xe3b (CONV: cdecl)
[..\sv.c @ 9199]
perl58!Perl_sv_dup(interpreter* my_perl = 01732e54
, sv* sstr = 0089a62c , clone_params* param = 0006fdf8 )+0x14a2 (CONV: cdecl)
[..\sv.c @ 9283]
perl58!Perl_gp_dup(interpreter* my_perl = 01732e54
, gp* gp = 009872f4 , clone_params* param = 0006fdf8 )+0x213 (CONV: cdecl)
[..\sv.c @ 8698]
vc6 debug output
unhandled exception in apache.exe (mscvrt.dll)
access violation c005
call stack
MSVCRT! 77c42fc4()
Perl_savepvn(interpreter * 0x016172cc, const char *
0x008b846c, long 23281824) line 926 + 17 bytes
Perl_mg_dup(interpreter * 0x016172cc, magic *
0x01629f80, clone_params * 0x0006fdf8) line 8755 + 32 bytes
Perl_sv_dup(interpreter * 0x016172cc, sv *
0x0006f750, clone_params * 0x0006fdf8) line 9261 + 22 bytes
Perl_sv_dup(interpreter * 0x016172cc, sv *
0x0094920c, clone_params * 0x0006fdf8) line 9203 + 34 bytes
Perl_sv_dup(interpreter * 0x016172cc, sv *
0x00933630, clone_params * 0x0006fdf8) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x016172cc, sv *
0x00933648, clone_params * 0x0006fdf8) line 9199 + 34 bytes
Perl_sv_dup(interpreter * 0x016172cc, sv *
0x0093360c, clone_params * 0x0006fdf8) line 9283 + 22 bytes
Re: [ MP2] startup problem with XML::LibXML
it is version 1.54 pascal - Original Message - From: Matt Sergeant [EMAIL PROTECTED] To: pascal barbedor [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 8:00 PM Subject: Re: [ MP2] startup problem with XML::LibXML On Saturday, Jan 25, 2003, at 09:49 Europe/London, pascal barbedor wrote: PROBLEM : APACHE SEGFAULT WITH XML::LibXML on WIN32 What version of XML::LibXML? Try version 1.52, not 1.53 which is very buggy. Matt.
server startup shutdown
I have XML file and don`t want parse/serialize on each request how implement this: 1) XML parsed on startup 2) All modules work whith same object 3) XML serialize on server shutdown P.S. Apache 2 mod_perl 2
Re: server startup shutdown
[EMAIL PROTECTED] wrote: I have XML file and don`t want parse/serialize on each request how implement this: 1) XML parsed on startup 2) All modules work whith same object It doesn't look to me like you can share objects across threads effectively at this time. You can share a hash ref, but that doesn't share things tha are referenced within that hash and it doesn't share the blessing. I think you will need to do this using standard data sharing methods, like IPC::MM or MLDBM::Sync. 3) XML serialize on server shutdown That sounds dangerous. What happens if your server crashes or otherwise shuts down abnormally? You will lose everything. Much safer to write your updates to disk, even if you only do it with Storable or MLDBM::Sync and then transform it back to XML later. - Perrin
[mp2] doing PerlSetVar from a startup handler
Hi -
I'm trying to get mason running under mod_perl 2,
but this is a mod_perl question. I need to have the
following set:
PerlSetVar MasonArgsMethod CGI
When I configure mason in httpd.conf w/o a startup handler,
everything is fine.
With a handler, even with the PerlSetVar before the
'require' for the handler in the conf file, CGI is NOT
set.
Question: how can I PerlSetVar from the perl code in the
handler? I see:
push @{ $Location{/}-{PerlSetVar} }, [ foo = 'bar' ];
in the mp1 docs - looks good - but where do I get the %Location
hash? Can't seem to find that.
Aloha = Beau.
RE: [mp2] doing PerlSetVar from a startup handler
Stas -
I finally found what was happening; the startup script
(which I miscalled a 'handler') invoked by a 'PerlRequire'
directive in httpd.conf creates, among other things, a
HTML::Mason::ApacheHandler object. One of the arguments
to it's new constructor is 'args_method', which, when
set to 'CGI' uses CGI instead of Apache::Request. I don't
know how the magic of the PerlSetVar = args_method when
mason is configured w/o a startup script, but the point
is mute, as it is up and running.
I will ponder further after my deadlines are met ;)
Aloha = Beau.
PS: why do I always get two duplicate messages from you?
PPS:
HOURLY WEATHER
100 AM HST THU DEC 5 2002
OAHU-
CITY SKY/WX TMP DP RH WIND PRES
HONOLULU CLEAR 68 63 84 NW3 30.04F
Chilly tonight!!!
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 12:48 AM
To: Beau E. Cox
Cc: Modperl
Subject: Re: [mp2] doing PerlSetVar from a startup handler
Beau E. Cox wrote:
Hi -
I'm trying to get mason running under mod_perl 2,
but this is a mod_perl question. I need to have the
following set:
PerlSetVar MasonArgsMethod CGI
When I configure mason in httpd.conf w/o a startup handler,
everything is fine.
What do you mean by the startup handler? a startup file?
With a handler, even with the PerlSetVar before the
'require' for the handler in the conf file, CGI is NOT
set.
I'm not familiar with mason, so please provide a short example that
reproduces the problem (w/o mason if possible).
Question: how can I PerlSetVar from the perl code in the
handler? I see:
push @{ $Location{/}-{PerlSetVar} }, [ foo = 'bar' ];
in the mp1 docs - looks good - but where do I get the %Location
hash? Can't seem to find that.
In 1.0 outside Perl you would go as:
package Apache::ReadConfig;
push @{ $Location{/}-{PerlSetVar} }, [ foo = 'bar' ];
but 2.0's support Perl sections support is incomplete as far as I know.
Doug implemented the base and Philippe was working on the rest, but he
is on vacation now, so expect him to complete it once he comes back (in
January I believe)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segmentation fault using a startup file
Ged Haywood wrote: On 27 Nov 2002, Jan Theofel wrote: Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? Sure. Many (linux|other) systems nowadays rely on Apache and Perl to do the UI to the system. Therefore they sometimes (always?) patch or change these tools to do what they want them to do. And when you want to add your own things collisions might happen. Therefore if you want to keep the system intact, build your own Apache and your own Perl in a different directory. You especially want this if you are a developer that need to make sure that the product works with various versions. e.g. I have: % ls ~/perl/ 5.005_03 5.6.0 5.6.0-ithread 5.6.1 5.6.1-ithread 5.8.0 5.8.0-ithread blead blead-ithread % ls ~/httpd/ 1.3 2.0 prefork prefork-apreq threaded worker Of course you probably don't need them all, but you get the idea. the only caveat of installing your own Apache is that you can't use port 80, if the system's Apache uses it. A simple rewrite rule solves this problem. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segmentation fault using a startup file
Hello, Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple which I use togeather with mod_perl. This seems to be a knowen problem but without a known solution. All I could find is that you can either: 1. Compile your own apache 2. Use another XML parser perl module Is someone here with another solution? Thanks, Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Re: segmentation fault using a startup file
Hi there, On 27 Nov 2002, Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple [snip] All I could find is that you can either: 1. Compile your own apache [snip] What is it about compiling your own Apache that troubles you? 73, Ged.
Re: segmentation fault using a startup file
Hello, Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: On 27 Nov 2002, Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple [snip] All I could find is that you can either: 1. Compile your own apache [snip] What is it about compiling your own Apache that troubles you? It is a lot of work to do. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Re: segmentation fault using a startup file
Hi Jan, On 27 Nov 2002, Jan Theofel wrote: Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: What is it about compiling your own Apache that troubles you? It is a lot of work to do. Only the first couple of times. Takes me about two minutes nowadays. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? 73, Ged.
Re: segmentation fault using a startup file
On Wed, 27 Nov 2002, Ged Haywood wrote: Date: Wed, 27 Nov 2002 20:56:01 + (GMT) From: Ged Haywood [EMAIL PROTECTED] To: Jan Theofel [EMAIL PROTECTED] Cc: mod_perl mailinglist [EMAIL PROTECTED] Subject: Re: segmentation fault using a startup file Hi Jan, On 27 Nov 2002, Jan Theofel wrote: Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: What is it about compiling your own Apache that troubles you? It is a lot of work to do. Only the first couple of times. Takes me about two minutes nowadays. I agree. The first few times I compiles anything on Unix, I thought Wow, this is hard. Now I understand how things fit together and why it's a Good Thing to compile your own stuff. I feel dirty now when I use RPMs of Perl, Apache, or vi. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? A few months ago I tried out some different Linux distros. I liked Debian a lot until I got this wierd feeling about system dependencies on their own Perl. I ditched it within hours of that as I felt that it might prove easy to break the system. If you feel that you can't compile your own Apache on SuSE, you should probably consider a different distro for your web server and rely on those other nice bits on systems where you can do without the flexibility of compiling your own stuff. What will you do when the next security hole is found in Apache and you can't upgrade for fear of breaking your system? ky
RE: segmentation fault using a startup file
Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple which I use togeather with mod_perl. This seems to be a knowen problem but without a known solution. It was a known problem with older versions of Apache. Specifically, the Apache build process statically linked in expat (for mod_dav?) and XML::Parser dynamically loaded expat causing a symbol conflict/segfault. My understanding is that modern builds of Apache no longer bundle expat but use the system supplied one so both Apache and XML::Parser share the dynamically loaded one - which of course is the 'right answer'. I'm not sure what version that change came in at (1.3.22 rings a bell) although I guess it's possible that SUSE may have forced a static linkage. What version of XML::Simple are you using? If it is 1.08 or earlier, then the expat conflict is almost certainly your problem. You could upgrade to 1.08_01 which allows you to use any SAX parser (eg: XML::LibXML) instead of expat/XML::Parser. If you're already running version 1.08_01 and you have SAX installed then work out which parser module you're using (the last one in lib/XML/SAX/ParserDetails.ini). Try selecting a different one (by swapping the order around in the ini file). Regards Grant
segmentation fault using a startup file
Hello,
I have another problem using Perl::PerlRun with a startup file in
apache. The line added to the apache configuration file was:
PerlRequire /home/www/[...]/shop/engine/apachestartup.pl
(Re)starting apache results in the following segmentation fault:
--- snip ---
mailgate:/home/www/[...]/shop/engine # /etc/init.d/apache start
Starting httpd [ Mailman PERL PHP4 Nagios ]/etc/init.d/apache: line 202:
14959 Segmentation fault $HTTPD_BIN $INET6 -t -f
/etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21
Syntax
OK
failed
mailgate:/home/www/[...]/shop/engine #
--- snap ---
In the startup file I just load some libraries as my book tells me that
the time to run the scripts will be shorter this way. (Later I want to
add Apache::DBI for a persistante database connection.)
As soon as I remove the comment one of the modules which have a # at
their line, I get the segmantation fault. (All modules named eq* are my
own modules for that shop.)
--- snip ---
#!/usr/bin/perl -w
$ENV{MOD_PERL} or die ERROR: not running under mod_perl.\n;
use lib /home/www/[...]/shop/engine/;
use strict;
# use these Perl modules
use Apache::PerlRun;
# use Apache::DBI;
use CGI;
use URI::Escape;
use File::Basename;
use Digest::MD5;
use IO::Scalar;
use XML::Parser;
use Storable;
use XML::Simple;
use XML::Writer;
use Crypt::GeneratePassword;
use MIME::QuotedPrint;
use Mail::Sendmail;
use Text::Iconv;
# use these own Perl modules
use eqcore;
# use eqtools;
# use eqdbtools;
# use eqdebug;
# use eqtemplate;
# use pago;
return 1;
--- snap ---
Here are the versions of the installed software:
# rpm -q apache
apache-1.3.23-142
# rpm -q mod_perl
mod_perl-1.26-347
# rpm -q perl
perl-5.6.1-159
(Perl 5.6.x is needed for some other modules which have nothing to do
with this shop.)
Thanks,
Jan
--
Jan Theofel Fon: +49 (7 11) 48 90 83 - 0
ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50
Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de
__
Inflex - eMail Scanning and Protection
Queries to: [EMAIL PROTECTED]
Re: segmentation fault using a startup file
On 25 Nov 2002, Jan Theofel wrote:
Hello,
I have another problem using Perl::PerlRun with a startup file in
apache. The line added to the apache configuration file was:
PerlRequire /home/www/[...]/shop/engine/apachestartup.pl
(Re)starting apache results in the following segmentation fault:
[ .. ]
As soon as I remove the comment one of the modules which have a # at
their line, I get the segmantation fault. (All modules named eq* are my
own modules for that shop.)
--- snip ---
#!/usr/bin/perl -w
$ENV{MOD_PERL} or die ERROR: not running under mod_perl.\n;
use lib /home/www/[...]/shop/engine/;
use strict;
# use these Perl modules
use Apache::PerlRun;
# use Apache::DBI;
Do you have the latest DBI (1.30), and also the latest
appropriate DBD::* driver? If not, try upgrading to see if that
helps.
--
best regards,
randy kobes
RE: segmentation fault using a startup file
Yeah, Randy, I second the motion.
We know that DBI 1.28 does _NOT_ work!
Aloha = Beau.
-Original Message-
From: Randy Kobes [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 25, 2002 7:34 AM
To: Jan Theofel
Cc: mod_perl mailinglist
Subject: Re: segmentation fault using a startup file
On 25 Nov 2002, Jan Theofel wrote:
Hello,
I have another problem using Perl::PerlRun with a startup file in
apache. The line added to the apache configuration file was:
PerlRequire /home/www/[...]/shop/engine/apachestartup.pl
(Re)starting apache results in the following segmentation fault:
[ .. ]
As soon as I remove the comment one of the modules which have a # at
their line, I get the segmantation fault. (All modules named eq* are my
own modules for that shop.)
--- snip ---
#!/usr/bin/perl -w
$ENV{MOD_PERL} or die ERROR: not running under mod_perl.\n;
use lib /home/www/[...]/shop/engine/;
use strict;
# use these Perl modules
use Apache::PerlRun;
# use Apache::DBI;
Do you have the latest DBI (1.30), and also the latest
appropriate DBD::* driver? If not, try upgrading to see if that
helps.
--
best regards,
randy kobes
perlsetvar sometimes fails at server startup
Hi
on win32 with perl 561/modperl 1.27-01 dev
httpd.conf
Perl
[..]
$PerlSetvar='var foo'; (set outside any container in
httpd.conf)
$Perlrequire='startup.pl';
[...]
/Perl
then inside a module used in startup.pl
use Apache();
my $s=Apache-server ; (ok)
my $base=$s-dir_config('var') (no error);
$base is undef...
I had noticed this behaviour already but sometimes it
disappears and sometimes it reappears .
is there a particular order to follow ?
(persetvar directive before perlrequire startup.pl ? which is
the case here anyway)
best regards
pascal
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)
modifying @INC at startup and version of perl used
Hi,
This is probably a luser error as I am quite new to this malarkey, however I have been
experimenting for a while without progress now. I need to know how to find out exactly
which version of perl mod_perl is configured to use, and if this can be changed as a
non-root user, and how to set the INC.
I have a simple startup script that prints INC, which prints
INC: /sbcimp/run/pd/perl/5.005_03/lib/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib/site_perl
this makes me think I am running 5.005_03?
In the conf file I have
PerlSetEnv PERL5LIB /sbcimp/run/pd/perl/5.6.1/lib:/sbcimp/run/pd/cpan/5.6.1-2002.06/lib
but this does not seem to update the INC. (I've also tried combinations of PERLLIB
and SetEnv etc).
When this is set however I get the following errors
Can't locate object method boot via package mod_perl at
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris/Apache/Constants.pm line 8.
and
[Thu Aug 29 10:41:12 2002] [error] syntax error at
/sbcimp/run/pd/perl/5.6.1/lib/warnings.pm line 306, near {^
syntax error at /sbcimp/run/pd/perl/5.6.1/lib/warnings.pm line 311, near {^
etc, which is making me think I am mixing incompatible perl binaries and modules.
Does that seem reasonable, and if so what can I do to use perl 5.6.1?
Many thanks for your time.
jamie
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Re: modifying @INC at startup and version of perl used
Jamie,
Use the perl internal variables to figure out what version you're running under: $]
and $^V
Use these whether you're running perl or mod_perl. You might want to direct questions
relating to perl in general to the perl beginners list.
Please see perldoc perlvar for more details.
~mark.
On Thu, Aug 29, 2002 at 10:44:15AM +0100, [EMAIL PROTECTED] wrote:
Hi,
This is probably a luser error as I am quite new to this malarkey, however I have
been experimenting for a while without progress now. I need to know how to find out
exactly which version of perl mod_perl is configured to use, and if this can be
changed as a non-root user, and how to set the @INC.
I have a simple startup script that prints @INC, which prints
@INC: /sbcimp/run/pd/perl/5.005_03/lib/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib/site_perl
this makes me think I am running 5.005_03?
In the conf file I have
PerlSetEnv PERL5LIB
/sbcimp/run/pd/perl/5.6.1/lib:/sbcimp/run/pd/cpan/5.6.1-2002.06/lib
but this does not seem to update the @INC. (I've also tried combinations of PERLLIB
and SetEnv etc).
When this is set however I get the following errors
Can't locate object method boot via package mod_perl at
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris/Apache/Constants.pm line 8.
and
[Thu Aug 29 10:41:12 2002] [error] syntax error at
/sbcimp/run/pd/perl/5.6.1/lib/warnings.pm line 306, near {^
syntax error at /sbcimp/run/pd/perl/5.6.1/lib/warnings.pm line 311, near {^
etc, which is making me think I am mixing incompatible perl binaries and modules.
Does that seem reasonable, and if so what can I do to use perl 5.6.1?
Many thanks for your time.
jamie
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
RE: modifying @INC at startup and version of perl used
Thanks, but, didn't think i was a beginner... this is more of a mod_perl question
because I'm aware of how to set @INC etc for normal perl scripts. Anyway I tried your
advice, but, from perldoc perlvar:
$]
The use of this variable is deprecated
and for $^V:
Use of uninitialized value at blah.pl line 7.
So are you forced to use the version of perl that was chosen when mod_perl was
installed? Guess so, am trying to do a local non-root install of apache and mod_perl
to see if this is so.
Thanks for the help,
jamie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 29 August 2002 11:22
To: Echlin, Jamie
Cc: [EMAIL PROTECTED]
Subject: Re: modifying @INC at startup and version of perl used
Jamie,
Use the perl internal variables to figure out what version
you're running under: $] and $^V
Use these whether you're running perl or mod_perl. You might
want to direct questions relating to perl in general to the
perl beginners list.
Please see perldoc perlvar for more details.
~mark.
On Thu, Aug 29, 2002 at 10:44:15AM +0100, [EMAIL PROTECTED] wrote:
Hi,
This is probably a luser error as I am quite new to this
malarkey, however I have been experimenting for a while
without progress now. I need to know how to find out exactly
which version of perl mod_perl is configured to use, and if
this can be changed as a non-root user, and how to set the @INC.
I have a simple startup script that prints @INC, which prints
@INC: /sbcimp/run/pd/perl/5.005_03/lib/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris
/sbcimp/run/pd/perl/5.005_03/lib/site_perl
this makes me think I am running 5.005_03?
In the conf file I have
PerlSetEnv PERL5LIB
/sbcimp/run/pd/perl/5.6.1/lib:/sbcimp/run/pd/cpan/5.6.1-2002.06/lib
but this does not seem to update the @INC. (I've also tried
combinations of PERLLIB and SetEnv etc).
When this is set however I get the following errors
Can't locate object method boot via package mod_perl at
/sbcimp/run/pd/perl/5.005_03/lib/site_perl/sun4-solaris/Apache/
Constants.pm line 8.
and
[Thu Aug 29 10:41:12 2002] [error] syntax error at
/sbcimp/run/pd/perl/5.6.1/lib/warnings.pm line 306, near {^
syntax error at /sbcimp/run/pd/perl/5.6.1/lib/warnings.pm
line 311, near {^
etc, which is making me think I am mixing incompatible perl
binaries and modules.
Does that seem reasonable, and if so what can I do to use perl 5.6.1?
Many thanks for your time.
jamie
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the
contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any
securities or
related financial instruments.
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Re: modifying @INC at startup and version of perl used
[EMAIL PROTECTED] wrote: [...] So are you forced to use the version of perl that was chosen when mod_perl was installed? Guess so, am trying to do a local non-root install of apache and mod_perl to see if this is so. It helps to RTFM: http://perl.apache.org/docs/1.0/guide/install.html#Should_I_Rebuild_mod_perl_if_I_have_Upgraded_Perl_ http://perl.apache.org/docs/1.0/guide/install.html#Installation_Without_Superuser_Privileges __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: modifying @INC at startup and version of perl used
Actually I was in the process of reading your very useful piece on how to create a non-root install. Problem is, there is a hell of a lot of FM to read. anyway, ta -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 29 August 2002 12:01 To: Echlin, Jamie Cc: [EMAIL PROTECTED] Subject: Re: modifying @INC at startup and version of perl used [EMAIL PROTECTED] wrote: [...] So are you forced to use the version of perl that was chosen when mod_perl was installed? Guess so, am trying to do a local non-root install of apache and mod_perl to see if this is so. It helps to RTFM: http://perl.apache.org/docs/1.0/guide/install.html#Should_I_Reb uild_mod_perl_if_I_have_Upgraded_Perl_ http://perl.apache.org/docs/1.0/guide/install.html#Installation _Without_Superuser_Privileges __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
RE: modifying @INC at startup and version of perl used
Hi Jamie -- So are you forced to use the version of perl that was chosen when mod_perl was installed? Guess so, am trying to do a local non-root install of apache and mod_perl to see if this is so. Yes -- you are bound to use the version of Perl which was compiled into Apache. If you want to upgrade Perl it is necessary to re-compile Apache/mod_perl. On that note, I have created a mostly-automatic build system to compile Apache with both mod_perl and mod_ssl. You can download the Makefile (and source tarballs, if you need) from here: http://www.erlbaum.net/Apache-Perl-SSL/ It's pretty raw, but it works for me. I can build a consistent Apache/mod_perl/mod_ssl from source, usually with one command: $ make build This will also allow you to build as a NON-ROOT user. It was designed to do so as a primary function. Let me know if you find this useful! Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Apache-server-dir_config-{DocumentRoot} is null on startup
Hi,
On a Apache/1.3.23 (Unix) mod_perl/1.26, if I check
Apache-server-dir_config during server startup, I find it is empty !!
Dumper shows it is bless( {}, 'Apache::Table' ).
Shouldn't the conf file key/value pairs be available in this Apache::Table
during a server startup ? Apache-server-dir_config(any key) is empty.
Also ...
How else can i find the server-document_root ?
Please mail me directly as I am not on the list. and TIA :-)
regards
srp
Re: Apache-server-dir_config-{DocumentRoot} is null on startup
How else can i find the server-document_root ? e.g: Apache-server_root_relative(htdocs); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Fascinating segfault at Apache startup
Come to think of it, this is exactly what I did on my RedHat 7.2 system -- grabbed a Perl 5.6.1 RPM without noticing that it was for RedHat 7.3. It installed fine, and Perl worked okay, so why not? Thanks for straightening this up, Eric -- as Chip said, everything should have worked fine with the Perl RPM if I had done it correctly. Thanks. :) Jeremy Weatherford [EMAIL PROTECTED] http://xidus.net On Fri, 21 Jun 2002, E Kolve wrote: I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric
Re: Fascinating segfault at Apache startup
Zac Morris [EMAIL PROTECTED] writes:
Honestly though Chip I have to pipe up here.
I was a gung ho RedHat supporter when I first got involved in the
linux world, and I still believe with it's RPMs and GUI tools it's
still the best for both new users and corporate environments, but
man, if you wanna do something that not the EXACT OS version-RPM
based software version, (hmmm, like DEVELOPMENT) you are SERIOUSLY
screwed with RPM more times than not.
It depends. Usually it isn't RPM that is the problem, it's the
-other- software you've installed with RPM. Dependencies tend to be
an all-or-nothing affair, though, which makes the situation more
complicated.
So I have spent the last FIVE full days about 10 hours a day setting
up redhat 7.3 (sans as many of the RPMs as I could possible get away
with). Now granted perl 5.6.1 was one of the RPMs I *did* install,
as was sendmail (since Redhat has REALLY whacked that one up with
the assumed workstation mode, but I at least know how to FIX
that), but my apache, mod_perl, java, tomcat, etc I built entirely
from source utilizing my /opt/{appname} everything all together
strategy.
I now have a pretty swank lil server setup here. I just
successfully tested my perl/DBD::Pg connections and i'll confirm
jdbc to Pg tomorrow and I'll be set for some major develpment
efforts.
I'm not familiar with tomcat, so I can't really comment on it
specifically. But, before I came to Red Hat, I was a compile from
source guy, even on production servers. Lots of reasons, but one was
that I didn't know RPM. It seemed like a hassle to deal with it for
little things, etc... so I didn't.
My personal suggestion would be to try to work with the default OS
instead of against it. Sometimes this is impossible, but sometimes it
isn't so bad. For instance, instead of compiling straight from
source, you could take our RPMs, modify them (such as making apache
live in /opt), maybe throw in a more recent version, and see how it
works. Likewise, building tomcat, java, etc, as RPMs may save you
time later when you need to rebuild a box, or clone the system, or
should disaster strike. Recompiling, checking dependencies by hand,
etc, really is time consuming. But, of course, so is learning RPM :)
It definitely is a difficult road. Having travelled it myself,
though, I find it to be tremendously better than how I used to do
things. It depends on your own personal preferences, though, as well
as company policies, your peers' skillsets, etc. No one answer fits
everything, but I really do think that package management of some kind
(RPMs, debian, etc) offers many superiorities over recompiling from
source. YMMV :) There's no one single answer (too much context), but
in general, whatever OS you use, it usually is easier to work with it
and the tools it provides than against it.
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied. The rest of this thread
points out a few issues, though, but I think that tends to be issues
with other perl modules that have shared library components. If you
(or anyone else!) have specific failures or test cases you've seen,
though, I'll look into it and see if it is something we can fix.
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
Red Hat, Inc.
Re: Fascinating segfault at Apache startup
I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric Jeremy Weatherford wrote: Hello, I'm trying to build a minimal Apache+mod_perl, sort of a 'Perl-Server', as mentioned in the mod_perl guide. Here's the end result: [root@omics root]# cd /usr/local/apache-perl/bin [root@omics bin]# ./httpd () gets absurdforkSegmentation fault [root@omics bin]# I'll start trying to debug this, but I'm not too confident in my ability to gather any more useful information, so I thought I'd ask if anybody has seen this before. I can't find any references to this message on the web (always scary), but maybe someone knows what's going on here. My configuration so far: perl-5.6.1-34.99.6 RPM from RedHat 7.2 # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.17-0.13smp, archname=i386-linux uname='linux daffy.perf.redhat.com 2.4.17-0.13smp #1 smp fri feb 1 10:30:48 est 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-109)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: Built under linux Compiled at Apr 1 2002 12:23:22 @INC: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl . apache-1.3.24, mod_perl-1.27 cd /usr/src/mod_perl-1.27 perl Makefile.PL \ APACHE_SRC=../apache-perl-1.3.24/src \ NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 \ EVERYTHING=1 make make install cd ../apache-perl-1.3.24 ./configure --prefix=/usr/local/apache-perl \ --disable-module=autoindex \ --disable-module=imap \ --disable-module=include \ --disable-module=log_config \ --disable-module=alias \ --disable-module=auth \ --disable-module=cgi \ --disable-module=env \ --disable-module=userdir \ --activate-module=src/modules/perl/libperl.a make make install src/httpd -l http_core.c mod_mime.c mod_negotiation.c mod_status.c mod_dir.c mod_asis.c mod_actions.c mod_access.c mod_setenvif.c mod_perl.c Any help would be appreciated... Thanks, Jeremy Weatherford [EMAIL PROTECTED] http://xidus.net
Re: startup for Apache 2.0/mod_perl 1.99
At 05:55 24.04.2002, Stas Bekman wrote: Chuck Goehring wrote: Stas/Everyone, To follow up. With the starting and stopping of Apache and looking at the log, I see entries like Child 1032: Waiting for 250 worker threads to exit. I was gettiong Low virtual memory errors from Win/2000, so I added ThreadsPerChild 24 to the http.conf. This makes it stop quicker and use a whole lot less memory. Also, the error at the browser comes back faster. Why did you have it set to 250 in first place? For testing set it to just a few to have the minimal overhead. The default (on Win32 Apache anyways) is 250. So it's what people will usually keep if they don't know about it. Maybe a note in the docs? -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: startup for Apache 2.0/mod_perl 1.99
Stas,
That made it work! Your my hero!. That also made the script that accesses
Oracle work as well. We've staved off the IIS beast for another day!
I'm not familiar with the testing stuff except when Doug had me run the
t/report thing.. I'm a CGI guy rather that an apache handler/C language
type.
The 250 was the built-in default value. I hadn't set anything related to
threads because I haven't read any of that yet. Just trying to get things
basically working. The high memory consumption and sluggish response may
have been aggravated by the missing directive and this machine only has
128MB memory. It's running on my workstation that has many applications
open all the time.
Thanks for the help.
Chuck
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Chuck Goehring [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, April 23, 2002 8:53 PM
Subject: Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote:
You're right. I'm getting impatient and jumping ahead. Pasted directly
from your post, restarted Apache and get same thing
[Tue Apr 23 12:16:54 2002] [notice] Parent: Created child process 2560
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Child process is running
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Acquired the start
mutex.
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Starting 250 worker
threads.
[Tue Apr 23 12:17:46 2002] [error] 2560: ModPerl::Registry: `Can't call
method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line
433.
It is referring to the IF statement:
if ($MOD_PERL) {
$query_string = Apache-request-args;
} else {
$query_string = $ENV{'QUERY_STRING'} if defined
$ENV{'QUERY_STRING'};
$query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
}
I know what was missing.
add 'PerlOptions +GlobalRequest', like so:
Location /perl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options ExecCGI
PerlSendHeader On
PerlOptions +GlobalRequest
/Location
http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/config/co
nfig.html#PerlOptions_Directive
# GlobalRequest
Setup the global request_rec for use with Apache-request
Sorry for missing this one, I'm not used to it yet :)
Also I'd like to repeat that the 2.0 test suite is the best place to
learn how, before the docs will be completed.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
At 19:31 24.04.2002, Chuck Goehring wrote: That made it work! Your my hero!. That also made the script that accesses Oracle work as well. We've staved off the IIS beast for another day! Great! I'm not familiar with the testing stuff except when Doug had me run the t/report thing.. I'm a CGI guy rather that an apache handler/C language type. What he meant is that the test scripts in t/ contain many examples of mod_perl 2.0 configuration and use. Look at the *.pm files which show various handlers being used. That should give you an idea of what to do. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: startup for Apache 2.0/mod_perl 1.99
Stas,
First, there was no mod_perl 1.2x installed on this machine. I didn't think
I would need it, but I'm guessing.
This was as you say. The Location /perl didn't aggree with the registry
loaded in startup. That fixed that problem but now it complains about
CGI.pm as follows:
[Tue Apr 23 10:10:00 2002] [error] 2676: ModPerl::Registry: `Can't call
method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433.
As you suggested, the use Apache::compat; is in startup. It had no effect.
Here is location in http.conf
LoadModule perl_module modules/mod_perl.so
Alias /perl e:/Apache2/cgi-perl
PerlRequire e:\apache2\conf\startup.cgi
# Access.conf
Location /perl
# Below for .js files
AllowOverride FileInfo
# Below changed from Set to Add to accomodate .js files
# Vaguely recall some problem on newsgroups but?
# don't use this one SetHandler perl-script
AddHandler perl-script .cgi
#PerlHandler Apache::Registry
PerlHandler ModPerl::Registry
PerlResponseHandler ModPerl::Registry
Options ExecCGI
allow from 206.128.139
PerlSendHeader On
/Location
== Here is startup.cgi
#! /perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w
use strict;
#use Apache ();
use Apache2 ();
use Apache::compat;
use ModPerl::Registry;
use DBI();
use CGI qw(-compile :cgi);
use Carp();
use DBI();
use CGI qw(-compile :cgi);
1;
__END__
=== Here's the test program:
#! c:/perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w
use Apache2 ();
use Apache::compat;
use ModPerl::Registry;# use Apache::Registry;
use CGI qw/:standard :html3/;
use CGI::Carp qw(fatalsToBrowser);
use DBI(); # use Apache::DBI();
$cgiOBJ = new CGI;
$dataSource = dbi:Oracle:dis.world; # put your DSN here
$dataSource = dbi:Oracle:rciora; # put your DSN here
$userName = 'terminals'; # you know what goes here
$password = ''; # and here
$dbh = DBI-connect($dataSource, $userName, $password)
or die $DBI::errstr;
print $cgiOBJ-header(-expires='-1d'),
$cgiOBJ-start_html(-TITLE='oracle test.pl',
-BGCOLOR='#FF');
print start herehr;
$sql = SELECT * FROM terminals.assets where substr(asset_part_no,1,1) =
'B';
$sth = $dbh-prepare($sql) || die $dbh-errstr;
$rc = $sth-execute || die $sth-errstr;
while (($firstField, $anotherField) = $sth-fetchrow_array){
print $firstField: $anotherFieldbr\n;
}
warn $DBI::errstr if $DBI::err;
$sth-finish;
$dbh-disconnect;
print hrend here;
print $cgiOBJ-end_html;
Thanks for any input.
Chuck
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Chuck Goehring [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, April 22, 2002 7:26 PM
Subject: Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote:
To all,
Having trouble configuring Apache 2.0 with mod_perl. Don't know if I
need compat or not.
My Apache 1.x/mod_perl 1.24 startup starts like this:
use strict;
use Apache ();
use Apache::Registry;
use Apache::DBI();
use CGI qw(-compile :cgi);
use Carp();
That didn't fly on Apache 2.0.35/mod_perl 1.99 (snapshot). Trying to
get something equivalent working.
If you want to use the old registry, the above missing:
use Apache2 ();
use Apache::compat;
Below doesn't work with or without
Apache::compat.
use strict;
use Apache2 ();
use Apache::compat;
use ModPerl::Registry;# use Apache::Registry;
#use Apache2::DBI(); # use Apache::DBI();
use DBI();
use CGI qw(-compile :cgi);
looks good to me. You don't show your Location config. Does it include
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
??
Apache error log id like so (last line):
[Mon Apr 22 18:00:58 2002] [error] failed to resolve handler
`Apache::Registry'
Apache::Registry? Above you said you are using ModPerl::Registry. Check
your config. I suggest to grep for Apache::Registry.
Apache::DBI (for 2.0 wasn't ported yet, and available for those seeking
interesting challenges)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote: Stas, First, there was no mod_perl 1.2x installed on this machine. I didn't think I would need it, but I'm guessing. This was as you say. The Location /perl didn't aggree with the registry loaded in startup. That fixed that problem but now it complains about CGI.pm as follows: [Tue Apr 23 10:10:00 2002] [error] 2676: ModPerl::Registry: `Can't call method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433. It's a very bad idea to try to find the problem without reducing the setup to a bare minimum. Does the very basic setup work for you? If it does, start from here and add things till you hit the problem. httpd.conf: --- LoadModule perl_module modules/mod_perl.so Alias /perl e:/Apache2/cgi-perl PerlRequire e:\apache2\conf\startup.cgi Location /perl SetHandler perl-script PerlResponseHandler ModPerl::Registry Options ExecCGI PerlSendHeader On /Location startup.pl: --- #! /perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w use strict; use Apache2 (); use Apache::compat; and a test script: #! c:/perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w use ModPerl::Registry; use CGI; $q = new CGI; print $q-header, $q-start_html(), 'Hello', $q-end_html(); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
You're right. I'm getting impatient and jumping ahead. Pasted directly
from your post, restarted Apache and get same thing
[Tue Apr 23 12:16:54 2002] [notice] Parent: Created child process 2560
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Child process is running
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Acquired the start mutex.
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Starting 250 worker threads.
[Tue Apr 23 12:17:46 2002] [error] 2560: ModPerl::Registry: `Can't call
method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433.
It is referring to the IF statement:
if ($MOD_PERL) {
$query_string = Apache-request-args;
} else {
$query_string = $ENV{'QUERY_STRING'} if defined $ENV{'QUERY_STRING'};
$query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
}
In CGIpm up at line 148 there is this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{'GATEWAY_INTERFACE'}
($MOD_PERL = $ENV{'GATEWAY_INTERFACE'} =~ /^CGI-Perl\//))
{
$| = 1;
require Apache;
}
Do I need to define 'GATEWAY_INTERFACE', or is it provided automatically by
mod_perl? This is on Win2000.
Thanks
Chuck
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Chuck Goehring [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, April 23, 2002 11:12 AM
Subject: Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote:
Stas,
First, there was no mod_perl 1.2x installed on this machine. I didn't
think
I would need it, but I'm guessing.
This was as you say. The Location /perl didn't aggree with the
registry
loaded in startup. That fixed that problem but now it complains about
CGI.pm as follows:
[Tue Apr 23 10:10:00 2002] [error] 2676: ModPerl::Registry: `Can't call
method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line
433.
It's a very bad idea to try to find the problem without reducing the
setup to a bare minimum.
Does the very basic setup work for you? If it does, start from here and
add things till you hit the problem.
httpd.conf:
---
LoadModule perl_module modules/mod_perl.so
Alias /perl e:/Apache2/cgi-perl
PerlRequire e:\apache2\conf\startup.cgi
Location /perl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options ExecCGI
PerlSendHeader On
/Location
startup.pl:
---
#! /perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w
use strict;
use Apache2 ();
use Apache::compat;
and a test script:
#! c:/perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w
use ModPerl::Registry;
use CGI;
$q = new CGI;
print $q-header,
$q-start_html(),
'Hello',
$q-end_html();
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
Stas/Everyone, To follow up. With the starting and stopping of Apache and looking at the log, I see entries like Child 1032: Waiting for 250 worker threads to exit. I was gettiong Low virtual memory errors from Win/2000, so I added ThreadsPerChild 24 to the http.conf. This makes it stop quicker and use a whole lot less memory. Also, the error at the browser comes back faster. I added use Apache::compat; to the test program after use ModPerl::Registry; hoping it would stop it from complaining about CGI.pm. But, I still get Error 500 in the browser and [error] 2724: ModPerl::Registry: `Can't call method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433. in the log. The build I'm using is modperl-2.0_2002042700.tar.gz. I tried adding PerlModule Apache2 to http.conf right after LoadModule perl_module modules/mod_perl.so and I get a Application Error/memory could not be read. The same CGI.pm error appears in the log. Also, the CGI.pm I have is dated 03/03/2001 and came with perl 5.6.1. Thanks Chuck - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Chuck Goehring [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 23, 2002 11:12 AM Subject: Re: startup for Apache 2.0/mod_perl 1.99 Chuck Goehring wrote: Stas, First, there was no mod_perl 1.2x installed on this machine. I didn't think I would need it, but I'm guessing. This was as you say. The Location /perl didn't aggree with the registry loaded in startup. That fixed that problem but now it complains about CGI.pm as follows: [Tue Apr 23 10:10:00 2002] [error] 2676: ModPerl::Registry: `Can't call method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433. It's a very bad idea to try to find the problem without reducing the setup to a bare minimum. Does the very basic setup work for you? If it does, start from here and add things till you hit the problem. httpd.conf: --- LoadModule perl_module modules/mod_perl.so Alias /perl e:/Apache2/cgi-perl PerlRequire e:\apache2\conf\startup.cgi Location /perl SetHandler perl-script PerlResponseHandler ModPerl::Registry Options ExecCGI PerlSendHeader On /Location startup.pl: --- #! /perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w use strict; use Apache2 (); use Apache::compat; and a test script: #! c:/perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -w use ModPerl::Registry; use CGI; $q = new CGI; print $q-header, $q-start_html(), 'Hello', $q-end_html(); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote:
You're right. I'm getting impatient and jumping ahead. Pasted directly
from your post, restarted Apache and get same thing
[Tue Apr 23 12:16:54 2002] [notice] Parent: Created child process 2560
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Child process is running
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Acquired the start mutex.
[Tue Apr 23 12:16:58 2002] [notice] Child 2560: Starting 250 worker threads.
[Tue Apr 23 12:17:46 2002] [error] 2560: ModPerl::Registry: `Can't call
method args on an undefined value at c:/perl/5.6.1/lib/CGI.pm line 433.
It is referring to the IF statement:
if ($MOD_PERL) {
$query_string = Apache-request-args;
} else {
$query_string = $ENV{'QUERY_STRING'} if defined $ENV{'QUERY_STRING'};
$query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
}
I know what was missing.
add 'PerlOptions +GlobalRequest', like so:
Location /perl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options ExecCGI
PerlSendHeader On
PerlOptions +GlobalRequest
/Location
http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/config/config.html#PerlOptions_Directive
# GlobalRequest
Setup the global request_rec for use with Apache-request
Sorry for missing this one, I'm not used to it yet :)
Also I'd like to repeat that the 2.0 test suite is the best place to
learn how, before the docs will be completed.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote: Stas/Everyone, To follow up. With the starting and stopping of Apache and looking at the log, I see entries like Child 1032: Waiting for 250 worker threads to exit. I was gettiong Low virtual memory errors from Win/2000, so I added ThreadsPerChild 24 to the http.conf. This makes it stop quicker and use a whole lot less memory. Also, the error at the browser comes back faster. Why did you have it set to 250 in first place? For testing set it to just a few to have the minimal overhead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
startup for Apache 2.0/mod_perl 1.99
To all,
Having trouble configuring Apache 2.0 with
mod_perl. Don't know if I need compat or not.
My Apache 1.x/mod_perl 1.24 startup starts like
this:
use strict;use Apache ();use
Apache::Registry;use Apache::DBI();use CGI qw(-compile :cgi);use
Carp();
That didn't fly on Apache 2.0.35/mod_perl 1.99
(snapshot). Trying to get something equivalent working. Below
doesn't work with or without Apache::compat.
use strict;use Apache2 ();use
Apache::compat;use ModPerl::Registry; # use
Apache::Registry;
#use Apache2::DBI();
# use Apache::DBI();use DBI();use CGI qw(-compile :cgi);
Apacheerrorlog id like so (last
line):
...
[Mon Apr 22 18:00:23 2002] [notice] Parent: Child
process exited successfully.[Mon Apr 22 18:00:38 2002] [notice] Parent:
Created child process 2560[Mon Apr 22 18:00:46 2002] [notice] Child 2560:
Child process is running[Mon Apr 22 18:00:46 2002] [notice] Child 2560:
Acquired the start mutex.[Mon Apr 22 18:00:46 2002] [notice] Child 2560:
Starting 250 worker threads.[Mon Apr 22 18:00:58 2002] [error] failed to
resolve handler `Apache::Registry'
From perl -V:
@INC:
c:/perl/5.6.1/lib/MSWin32-x86-multi-thread
c:/perl/5.6.1/lib
c:/perl/site/5.6.1/lib/MSWin32-x86-multi-thread
c:/perl/site/5.6.1/lib .
Test program:
#!
c:/perl/5.6.1/bin/MSWin32-x86-multi-thread/perl.exe -wuse CGI qw/:standard
:html3/;use CGI::Carp qw(fatalsToBrowser); use DBI(); # use
Apache::DBI();$cgiOBJ = new CGI;
$dataSource
= "dbi:Oracle:rciora"; # put your DSN
here$userName
= 'terminals';
$password
= 'xxx'; $dbh = DBI-connect($dataSource, $userName, $password)
or die $DBI::errstr;
print
$cgiOBJ-header(-expires='-1d'),
$cgiOBJ-start_html(-TITLE='oracle
test.pl',
-BGCOLOR='#FF');
print "start herehr";$sql = "SELECT *
FROM terminals.assets where substr(asset_part_no,1,1) = 'B'";$sth =
$dbh-prepare($sql) || die $dbh-errstr;$rc = $sth-execute ||
die $sth-errstr;while (($firstField, $anotherField) =
$sth-fetchrow_array){ print
"$firstField: $anotherFieldbr\n";}warn $DBI::errstr if
$DBI::err;$sth-finish;
# disconnect from
database$dbh-disconnect;
print "hrend here";
print $cgiOBJ-end_html;
Re: startup for Apache 2.0/mod_perl 1.99
Chuck Goehring wrote: To all, Having trouble configuring Apache 2.0 with mod_perl. Don't know if I need compat or not. My Apache 1.x/mod_perl 1.24 startup starts like this: use strict; use Apache (); use Apache::Registry; use Apache::DBI(); use CGI qw(-compile :cgi); use Carp(); That didn't fly on Apache 2.0.35/mod_perl 1.99 (snapshot). Trying to get something equivalent working. If you want to use the old registry, the above missing: use Apache2 (); use Apache::compat; Below doesn't work with or without Apache::compat. use strict; use Apache2 (); use Apache::compat; use ModPerl::Registry;# use Apache::Registry; #use Apache2::DBI(); # use Apache::DBI(); use DBI(); use CGI qw(-compile :cgi); looks good to me. You don't show your Location config. Does it include SetHandler perl-script PerlResponseHandler ModPerl::Registry ?? Apache error log id like so (last line): [Mon Apr 22 18:00:58 2002] [error] failed to resolve handler `Apache::Registry' Apache::Registry? Above you said you are using ModPerl::Registry. Check your config. I suggest to grep for Apache::Registry. Apache::DBI (for 2.0 wasn't ported yet, and available for those seeking interesting challenges) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: startup vs. child initialization question
Also, I read about issues of database handlers becoming unstable across forks. So should I place this initialization information into a perl child init handler? See the connect_on_init() method in the Apache::DBI docs. We use PerlSetVar's for this where I work. That's how I would do it too, for anything that might vary by virtual host. - Perrin
startup vs. child initialization question
Hi! I had a question regarding where I should be placing global configuration options in mod_perl. Here's the qweekie scenario: I want to load a configuration file of various options (such as db arguments, system directories, db connections, etc.) into a hash or perl object global to Apache so that my mod_perl handlers have access to this variable/object, kinda like the %ENV variable except that I wish to keep these pieces of information separate from the %ENV variable. Initially, I thought about loading this configuration information in a startup script and using the PerlRequire directive to load this script. However, since doing this code will run under root privileges, would it be a good idea to place this type of information in this file? Also, I read about issues of database handlers becoming unstable across forks. So should I place this initialization information into a perl child init handler? Second if I want to utilize virtual hosting on a single machine with mod_perl loaded into certain hosts, what would this situation do in terms of allowing those hosts to access these variables? What should I do if I want a kind of separate configuration environment per virtual host in mod_perl and to load that configuration environment up before a request to improve performance? Thanks! -- Spring Break pics and more on CollegeClub.com! Catch all the photos, fun and festivities. http://navisite.collegeclub.com/springbreak/
Re: startup vs. child initialization question
On Sun, 31 Mar 2002 12:43:45 -0800 (PST) [EMAIL PROTECTED] wrote:
Hi! I had a question regarding where I should be placing global
configuration options in mod_perl. Here's the qweekie scenario:
I want to load a configuration file of various options (such as db
arguments, system directories, db connections, etc.) into a hash or
perl object global to Apache so that my mod_perl handlers have access
to this variable/object, kinda like the %ENV variable except that I
wish to keep these pieces of information separate from the %ENV
variable. Initially, I thought about loading this configuration
information in a startup script and using the PerlRequire directive to
load this script. However, since doing this code will run under root
privileges, would it be a good idea to place this type of information
in this file? Also, I read about issues of database handlers becoming
unstable across forks. So should I place this initialization
information into a perl child init handler?
Second if I want to utilize virtual hosting on a single machine with
mod_perl loaded into certain hosts, what would this situation do in
terms of allowing those hosts to access these variables? What should
I do if I want a kind of separate configuration environment per
virtual host in mod_perl and to load that configuration environment up
before a request to improve performance?
We use PerlSetVar's for this where I work. It goes something like this:
Location /foo
SetHandler perl-script
PerlHandler MyHandler::Foo
PerlSetVar DatabaseName foo
PerlSetVar DatabaseUser foouser
PerlSetVar DatabasePass foo$secret
/Location
In the code we grab these variables like so:
sub handler {
my $r = shift;
my %vars = ();
$vars{dbname} = $r-dir_config('DatabaseName');
$vars{dbuser} = $r-dir_config('DatabaseUser');
$vars{dbpass} = $r-dir_config('DatabasePass');
}
We actually have 10 or so common configuration parameters on most of
of our modules so we move all of our $r-dir_configs into an init()
subroutine.
Anyway... this might be one way to attack your problem, as you can
then use different parameters on each virtual host.
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
Re: Apache::DBI startup?
On Wed, 20 Mar 2002, Stas Bekman wrote: Doug Silver wrote: I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Yes see http://perl.apache.org/guide/databases.html#Debugging_Apache_DBI Actually, that's what I had it on: [Wed Mar 20 10:45:16 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0 mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations 30460 Apache::DBI PerlChildInitHandler 30461 Apache::DBI PerlChildInitHandler 30462 Apache::DBI PerlChildInitHandler 30463 Apache::DBI PerlChildInitHandler 30464 Apache::DBI PerlChildInitHandler [Wed Mar 20 10:45:16 2002] [notice] Accept mutex: flock (Default: flock) From my startup.pl: # choose debug output: 0 = off, 1 = quiet, 2 = chatty $Apache::DBI::DEBUG = 2; I guess I just wanted some confirmation on how the DBI was able to establish the connection without a database or username specified. Guess it's working, which is the main issue. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Apache::DBI startup?
I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Thanks. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Apache::DBI startup?
Doug Silver wrote: I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Yes see http://perl.apache.org/guide/databases.html#Debugging_Apache_DBI -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Apache::DBI startup failure
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
And here's what happens:
[Thu Mar 14 14:28:35 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0
mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations
13336 Apache::DBI PerlChildInitHandler
13337 Apache::DBI PerlChildInitHandler
13338 Apache::DBI PerlChildInitHandler
13339 Apache::DBI PerlChildInitHandler
13340 Apache::DBI PerlChildInitHandler
[Thu Mar 14 14:28:35 2002] [notice] Accept mutex: flock (Default: flock)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13338 exit signal Segmentation fault (11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13339 exit signal Segmentation fault (11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13337 exit signal Segmentation fault (11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13336 exit signal Segmentation fault (11)
[Thu Mar 14 14:28:36 2002] [notice] child pid 13340 exit signal Segmentation fault (11)
If I don't use the connect_on_init stuff, I can run a test script fine with those
exact db parameters.
Any suggestions?
Thanks!
--
~
Doug Silver
Network Manager
Quantified Systems, Inc
~
Re: Apache::DBI startup failure
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
And here's what happens:
[Thu Mar 14 14:28:35 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0
mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations
13336 Apache::DBI PerlChildInitHandler
13337 Apache::DBI PerlChildInitHandler
13338 Apache::DBI PerlChildInitHandler
13339 Apache::DBI PerlChildInitHandler
13340 Apache::DBI PerlChildInitHandler
[Thu Mar 14 14:28:35 2002] [notice] Accept mutex: flock (Default: flock)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13338 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13339 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13337 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13336 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:36 2002] [notice] child pid 13340 exit signal Segmentation fault
(11)
If I don't use the connect_on_init stuff, I can run a test script fine with those
exact db parameters.
Any suggestions?
Thanks!
--
~
Doug Silver
Network Manager
Quantified Systems, Inc
~
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
signature.asc
Description: This is a digitally signed message part
Re: Apache::DBI startup failure
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI-connect_on_init(dbi:pg:demo,demo);
This doesn't:
Apache::DBI-connect_on_init(dbi:Pg:demo,demo);
That's right, putting 'dbi:pg' in lowercase made it work. I looked through
some old newsgroup stuff and saw someone using Postgres had it similar to
that.
Here's some further debugging information for the developers:
perl -v = v5.6.1 on i386-freebsd (FreeBSD 4.4)
# pkg_info |egrep -i dbi|postgres
p5-Apache-DBI-0.88 DBI persistent connection, authentication and authorization
p5-DBD-Pg-1.01 Provides access to PostgreSQL databases through the DBI
p5-DBI-1.20 The perl5 Database Interface. Required for DBD::* modules
postgresql-7.1.3A robust, next generation, object-relational DBMS
-doug
On 14 Mar 2002, Brendan W. McAdams wrote:
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
[Fwd: Re: Apache::DBI startup failure]
Weird, although I bet if you had straced the apache processes you would
have seen the File not found.
For some reason I recall DBD Drivers being case sensitive.
On Thu, 2002-03-14 at 20:06, Doug Silver wrote:
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI-connect_on_init(dbi:pg:demo,demo);
This doesn't:
Apache::DBI-connect_on_init(dbi:Pg:demo,demo);
That's right, putting 'dbi:pg' in lowercase made it work. I looked through
some old newsgroup stuff and saw someone using Postgres had it similar to
that.
Here's some further debugging information for the developers:
perl -v = v5.6.1 on i386-freebsd (FreeBSD 4.4)
# pkg_info |egrep -i dbi|postgres
p5-Apache-DBI-0.88 DBI persistent connection, authentication and authorization
p5-DBD-Pg-1.01 Provides access to PostgreSQL databases through the DBI
p5-DBI-1.20 The perl5 Database Interface. Required for DBD::* modules
postgresql-7.1.3A robust, next generation, object-relational DBMS
-doug
On 14 Mar 2002, Brendan W. McAdams wrote:
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI
modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
signature.asc
Description: This is a digitally signed message part
Adding information to Virtual Hosts in a startup file...
Hi,
I'd like to add a location directives dynamically at startup to a VirtualHost using a
startup script.
I've been trying:
$Apache::ReadConfig::VirtualHost{'127.0.0.1:80'}-{Location}-{'/'} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Hello',
};
which doesn't work ... while
$Apache::ReadConfig::Location{'/'} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Hello',
};
works but clobbers other information already stored in other VirtualHosts. I
specifically need to patch into one virtual host out of possibly many.
The configuration of the various machines is out of my control which is why I was
going with the Apache::ReadConfig approach.
Thanks
-Chris
What do these messages mean on startup
I am getting these error messages when I restart apache on a new mod perlinstall.Starting httpd: Subroutine export redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 35.Subroutine name redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 46.Subroutine Apache::Constants::__AUTOLOAD redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 14.Subroutine Apache::Constants::SERVER_VERSION redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 14.Subroutine Apache::Constants::SERVER_BUILT redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 14.Subroutine Apache::Constants::DECLINE_CMD redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 14.Subroutine Apache::Constants::DIR_MAGIC_TYPE redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 14.Constant subroutine OK redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm line 65535.Constant subroutine DECLINED redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Constant subroutine DONE redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Constant subroutine NOT_FOUND redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Constant subroutine FORBIDDEN redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Constant subroutine AUTH_REQUIRED redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Constant subroutine SERVER_ERROR redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 65535.Subroutine AUTOLOAD redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 30.Constant subroutine AUTH_REQUIRED redefined at /usr/lib/perl5/5.6.0/Carp.pmline 4Constant subroutine DONE redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Constant subroutine SERVER_ERROR redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Constant subroutine NOT_FOUND redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Constant subroutine FORBIDDEN redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Constant subroutine OK redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Constant subroutine DECLINED redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 4Subroutine handler redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 27.Subroutine compile redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 174.Subroutine parse_cmdline redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 190.Subroutine DESTROY redefined at/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 214.[ OK ]Here is my perl conf file.Alias /perl/ /home/www/perl/PerlModule Apache::RegistryLocation /perlSetHandler perl-scriptPerlHandler Apache::RegistryOptions ExecCGIallow from allPerlSendHeader On/Location#This bit of code, causes apache to exit gracefully on any request forMicroshit files: nimbda fighterPerlModule Apache::ConstantsLocationMatch "\.(ida|exe|dll|asp)$"SetHandler perl-scriptPerlInitHandler Apache::Constants::DONE/LocationMatchPerlRequire /etc/httpd/conf/perl_conf/startup.plPerlFreshRestart OnPerlWarn OnThe server appears to have started.Should or can I just disreguard these messages.thanksJohn michael
Re: What do these messages mean on startup
John Michael wrote: I am getting these error messages when I restart apache on a new mod perl install. http://perl.apache.org/guide/troubleshooting.html#Constant_subroutine_XXX_redefine Something forces the code reloading since Apache restarts itself on the start. make sure to run the latest mod_perl, as PerlModule/Require used to call the code twice (fixed now). Also I heartly suggest not to use 5.6.0 and move onto 5.6.1. Whenever you report a problem, make sure to check the SUPPORT file and give us all the details about your system. Starting httpd: Subroutine export redefined at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Constants.pm line 35. [snip] Subroutine DESTROY redefined at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 214. [ OK ] Here is my perl conf file. Alias /perl/ /home/www/perl/ PerlModule Apache::Registry Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader On /Location #This bit of code, causes apache to exit gracefully on any request for Microshit files: nimbda fighter PerlModule Apache::Constants LocationMatch \.(ida|exe|dll|asp)$ SetHandler perl-script PerlInitHandler Apache::Constants::DONE /LocationMatch PerlRequire /etc/httpd/conf/perl_conf/startup.pl PerlFreshRestart On PerlWarn On The server appears to have started. Should or can I just disreguard these messages. this is not a problem, but by upgrading you can get rid of these. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Modules `use`d by PerlModule vanishing after startup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have recently been working on a framework for moving our applications to mod_perl but I've run into a very odd problem. I load our program's main Apache handler, with: PerlModule IQGroup::IQCoordinator And then set it up as a PerlHandler for a virtual host. But when I attempt to load the program, it fails and throws this into the error log: [Thu Aug 9 14:29:05 2001] [error] Can't locate object method GetCurrentRequest via package IQGroup::Core::ApacheRequest (perhaps you forgot to load IQGroup::Core::ApacheRequest?) at /usr/lib/perl5/5.6.1/IQGroup/IQCoordinator.pm line 60. Except it IS being loaded, it's the first module `use`d by our PerlHandler. A trace on the Apache process even shows the module being read at startup. When I insert Apache::Status and take a look at the symbol table, it shows the IQGroup::Core::ApacheRequest namespace, but with no symbols in it! Even more odd, the modules that it in turn uses DO show up, all symbols intact. Now, if I load the handler in the startup file: use IQGroup::IQCoordinator; then everything loads properly, although I get a slew of subroutine blah redefined messages in the error log when it hits the PerlModule directive. This doesn't seem like intended behavior (nothing I read suggests it's supposed to work like this)...so what's eating my module's symbol table? - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBO3Lr3gOGqGs0PadnEQLHTACgrvUHoQSRdUDYntXkzmnCOapDy5MAn2Ex HIvS8i793nzDBqowJ/EMf7T9 =0PSY -END PGP SIGNATURE-
Problem Locating DB_File.PM at startup of perl script
Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? James
Re: Problem Locating DB_File.PM at startup of perl script
James McKim [EMAIL PROTECTED] said something to this effect on 07/18/2001: Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? What are the permissions on /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm? Can the owner of the httpd process read the file? (darren) -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
Re: Problem Locating DB_File.PM at startup of perl script
Interesting question. The file owner is root. However, I actually launched the perl cgi from the shell as root and got the error message, so I'm not sure that matching the file owner with the owner of the httpd process would make much difference (yet). James darren chamberlain wrote: James McKim [EMAIL PROTECTED] said something to this effect on 07/18/2001: Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? What are the permissions on /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm? Can the owner of the httpd process read the file? (darren) -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
Re: Problem Locating DB_File.PM at startup of perl script
BTW, executing the script seemed to be able to locate CGI, DBI, and POSIX just fine. James darren chamberlain wrote: James McKim [EMAIL PROTECTED] said something to this effect on 07/18/2001: Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? What are the permissions on /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm? Can the owner of the httpd process read the file? (darren) -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
Re: Problem Locating DB_File.PM at startup of perl script
Hi James, The loadable object is not the .pm file, it's the binary compiled object file that DB_File.pm needs to bootstrap. Sounds like you need to reinstall the module. [EMAIL PROTECTED] (James McKim) wrote: Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? James ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Problem Locating DB_File.PM at startup of perl script
Ken, Thanks for your reply. It does makes sense, eventhough I'm new to perl modules and their implementation. BTW, do you know what that file would be named? I installed it under perl 5.6.0, but when I try to install it under 5.6.1 I get the error (which seems to be a linker error) /usr/bin/ld: cannot find -ldb. A bit of research lead me to some mention of needing a libdb2 version, but I haven't gotten to deep into it yet and am hoping that I can use my previous installation of DB_File (under 5.6.0) for now. Cheers, James Ken Williams wrote: Hi James, The loadable object is not the .pm file, it's the binary compiled object file that DB_File.pm needs to bootstrap. Sounds like you need to reinstall the module. [EMAIL PROTECTED] (James McKim) wrote: Hi all, I've run into a very frustrating problem. I'm getting the old Can't locate loadable object for module... error, yet the file does exist in the @INC path. Here's some system output: --- [Wed Jul 18 12:18:04 2001] pickcity.cgi: Can't locate loadable object for module DB_File in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at /var/pickcity/htdocs/pickcity.cgi line 12 [Wed Jul 18 12:18:04 2001] pickcity.cgi: Compilation failed in require at /var/pickcity/htdocs/pickcity.cgi line 12. [Wed Jul 18 12:18:04 2001] pickcity.cgi: BEGIN failed--compilation aborted at /var/pickcity/htdocs/pickcity.cgi line 12. [root@localhost DB_File]# ls /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm /usr/local/lib/perl5/5.6.1/i686-linux/DB_File.pm [root@localhost DB_File]# -- Anyone have any ideas as to why perl can't seem to find the file eventhough the system, clearly, can? James ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Accessing server config during parent startup
On Tuesday 10 July 2001 05:42, Doug MacEachern wrote: On Mon, 9 Jul 2001, Robin Berjon wrote: cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); try s-lookup_defaults instead of s-module_config see also: modperl-2.0/src/modules/perl/modperl_pcw.c where you can see howto access all of the config apache has parsed. the same logic should work with 1.x, just need to s/apr_pool_t/pool/g and the like. Thanks Doug, the first option works like a charm :) And I'm far too scared already what with all this finding out about XS and all to apply the second one immediately, but I definitely will once I get a better grasp of these things. Thanks a lot ! -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. -- Dirk Gently (Douglas Adams)
Knowing the current VirtualHost at server startup
Hi, I've been looking around for a way for a Perl section (or code called from it, or perhaps even loaded through PerlModule) to know the current VirtualHost in which it is, at server startup (ie without a request object handy). Apache-server returns the main server object (or so it seems, that would appear to be logical) and I know that I can use $s-next to get a chain of server objects, but I can't seem to find a way in C or in Perl to know about the current server. Is there such a thing ? Thanks, -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- What I like about deadlines is the lovely whooshing sound they make as they rush past. --Douglas Adams
Re: Knowing the current VirtualHost at server startup
On Tue, 10 Jul 2001, Robin Berjon wrote:
Hi,
I've been looking around for a way for a Perl section (or code called from
it, or perhaps even loaded through PerlModule) to know the current
VirtualHost in which it is, at server startup (ie without a request object
handy).
Apache-server returns the main server object (or so it seems, that would
appear to be logical) and I know that I can use $s-next to get a chain of
server objects, but I can't seem to find a way in C or in Perl to know about
the current server.
Apache-server will point to the current VirtualHost with this patch..
--- src/modules/perl/perl_config.c 2001/06/19 03:12:45 1.110
+++ src/modules/perl/perl_config.c 2001/07/11 02:46:32
@@ -1744,7 +1744,15 @@
ENTER_SAFE(parms-server, parms-pool);
MP_TRACE_g(mod_perl_dump_opmask());
-perl_eval_sv(code, G_DISCARD);
+
+{
+SV *server_sv = perl_get_sv(Apache::__SERVER, FALSE);
+IV ptr = SvIVX(SvRV(server_sv));
+SvIVX(SvRV(server_sv)) = (IV)parms-server;
+perl_eval_sv(code, G_DISCARD);
+SvIVX(SvRV(server_sv)) = (IV)ptr;
+}
+
LEAVE_SAFE;
{
Accessing server config during parent startup
Hi, I'm having trouble trying to access server config directives during parent startup. Basically, I've got a module which needs to access a configuration directive in order to compile some non-Perl files to Perl while the server starts and before children are created so that the code they generate will stay shared. The directive I need access to is defined by AxKit, so I can play with the source code that defines it to make it available to Perl at that time. In order to access the configuration, I'm using (in a nutshell): cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); where s is an Apache::Server object mapped to T_PTROBJ in the typemap. The code is working and now returns a cfg that exists but hasn't been initialised, ie it is as if no directives had been read at all (or so it seems). However, it is clear that the code is called after the directives have been read. This may all be due to a problem in my code, but before I go on and go insane, I wondered if using the server object thus has any chance of working, and if there is a description of the right way to do this somewhere. Thanks ! -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Oops. My Brain just hit a bad sector.
RE: Accessing server config during parent startup
-Original Message- From: Robin Berjon [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Accessing server config during parent startup Hi, I'm having trouble trying to access server config directives during parent startup. Basically, I've got a module which needs to access a configuration directive in order to compile some non-Perl files to Perl while the server starts and before children are created so that the code they generate will stay shared. The directive I need access to is defined by AxKit, so I can play with the source code that defines it to make it available to Perl at that time. In order to access the configuration, I'm using (in a nutshell): cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); I only just skimmed the sources, but I don't think it is possible. AxKit populates the per-dir config, not the per-server config, and you need a request record to dig out the per-dir config. interesting to see what Matt says, though... --Geoff
Re: Accessing server config during parent startup
On Monday 09 July 2001 18:09, Geoffrey Young wrote: From: Robin Berjon [mailto:[EMAIL PROTECTED]] In order to access the configuration, I'm using (in a nutshell): cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); I only just skimmed the sources, but I don't think it is possible. AxKit populates the per-dir config, not the per-server config, and you need a request record to dig out the per-dir config. Yes, that much I know (there's a lot more to it, but I tried to boil it down to a simple description in order to make it palatable). Having a request object at server startup is not possible, or would be a hack which I'd rather avoid. I added a server config creator which is an exact copy of the per-directory config creator to the module struct, except that it takes a server_rec as its second arg instead of a string. Perhaps I need to do something with that server_rec (eg set the module config on it instead of simply returning it), but I wasn't able to find anything helpful in the Apache docs (I might have missed though, pointers welcome). interesting to see what Matt says, though... Matt probably won't be back for a while, which is why I'm posting here instead of pestering him directly on #axkit ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- The only sensible way to estimate the stability of a Windows server is to power it down and try it out as a step ladder. -- Robert Crawford, in the Monastery
Re: Accessing server config during parent startup
On Monday 09 July 2001 19:38, Robin Berjon wrote: On Monday 09 July 2001 18:09, Geoffrey Young wrote: From: Robin Berjon [mailto:[EMAIL PROTECTED]] In order to access the configuration, I'm using (in a nutshell): cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); I added a server config creator which is an exact copy of the per-directory config creator to the module struct, except that it takes a server_rec as its second arg instead of a string. Perhaps I need to do something with that server_rec (eg set the module config on it instead of simply returning it), but I wasn't able to find anything helpful in the Apache docs (I might have missed though, pointers welcome). It would seem (if I understand correctly) that my cfg is only finally initialized after the server merge and dir merge have been called, but that unfortunately Perl sections are called before that... Can anyone confirm this ? And if it is the case, is there a way I can work around that problem, eg by defining some handler code to be called after merging but before children are created ? Thanks ! -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Always remember you're unique just like everyone else.
Re: Accessing server config during parent startup
On Mon, 9 Jul 2001, Robin Berjon wrote: cfg = (axkit_dir_config *) ap_get_module_config(s-module_config, XS_AxKit); try s-lookup_defaults instead of s-module_config see also: modperl-2.0/src/modules/perl/modperl_pcw.c where you can see howto access all of the config apache has parsed. the same logic should work with 1.x, just need to s/apr_pool_t/pool/g and the like.
Re: startup
On Wed, 27 Jun 2001, Purcell, Scott wrote:
Hello Stas,
I think somehow my question got out of sync with the answer. My question
was, if I do a use cgi qw(-compile: all) in my startup (which I have done),
do I still need to put a use cgi in each of my .pl files? I have read
through the docs, and the book, but as a rookie to mod-perl these kinds of
questions are hard for me to get a handle on. I assume the answer is yes,
but instead of actually reloading the module that it would check the cache
and use that? Am I on the right track. Also, there is quite a bit of
documentation out there, could you point me to the one that talks about
this?
Scott, please keep the questions at the list, wheneven someone or I can
answer we will do it. You minimize your chances to get answered when you
try to do it in private.
As I said, the guide covers this question. Here is the direct URL:
http://perl.apache.org/guide/config.html#The_Confusion_with_use_in_the_
Here is a link to the notes in my previous reply to you:
http://perl.apache.org/guide/performance.html#Preloading_Perl_Modules_at_Serve
I hope I am not offending you by asking,
Sincerely
Scott
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 27, 2001 11:10 AM
To: Purcell, Scott
Cc: mod_perl list
Subject: Re: Startup.pl File Q
On Wed, 27 Jun 2001, Issac Goldstand wrote:
Actually, I believe that it helps to do a use cgi qw(-compile: all) as
this
will pre-compile the entire module (which makes it go a bit faster for
it's
first request).
As Issac correctly said, but usually you don't want :all, but only the tag
groups that you really need. Scott, please refer to the guide, it explain
what, how and why. Including memory measurement with different configs.
Issac
- Original Message -
From: Purcell, Scott [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 27, 2001 17:29
Subject: Startup.pl File Q
Mod_perl version: 1.25_01-dev
Perl version: 5.6.1
Apache Version: 1.3.20
OS:NT
I am in the apache book and I am doing some hacking. In my startup.pl
file,
I put 'use CG qw(:standard); along with some other modules.
Anyway, then I typed that little dittie below, and commented out the
$use
CGI (since I thought it would be loaded in the startup.pl file).
It does not work. Are the items in the startup.pl file only used with
handlers?
Thanks
Scott
### code below just for reference #
#! /usr/local/bin/perl
#use CGI qw(:standard);
use strict;
my $name = param('name') || 'Anonymous';
print header(),
start_html(-title='Yo!',-bgcolor='blue'),
h1(Hello $name),
p(
To change your name, enter it into the text field below and press,
em(change name.)
),
start_form(),
Name: ,textfield(-name='name',-value='Anonymous'),
submit(-value='Change Name'),
end_form(),
hr(),
end_html();
Scott Purcell
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Startup behavier of Filter::Util::Call and DBI
Hi all, I just updated our development system to some recent versions... Perl 5.6.0-5.6.1, Apache 1.3.14-1.3.19, mod_perl 1.24_1-1.25, DBI 1.14-1.15, Filter 1.19-1.23 (+16 others). Now this is what I get at server startup: # /opt/apache/bin/apachectl start startup.pl: starting (0) /opt/apache/bin/apachectl start: httpd started startup.pl: starting (1) Subroutine Filter::tee::import redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/tee.pm line 11. Subroutine filter_read_exact redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 24. Subroutine filter_add redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 44. Subroutine Filter::Util::Call::filter_read redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 59. Subroutine Filter::Util::Call::real_import redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 59. Subroutine Filter::Util::Call::filter_del redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 59. Subroutine Filter::Util::Call::unimport redefined at /opt/perl/lib/site_perl/5.6.1/aix/Filter/Util/Call.pm line 59. startup.pl: starting (2) DBI handle cleared whilst still active at /opt/perl/lib/site_perl/5.6.1/aix/DBI.pm line 207. dbih_clearcom (h 0x20189a90, com 0x2066cac8): FLAGS 0x211: COMSET Warn ShowErrorStatement AutoCommit TYPE 1 PARENT undef KIDS 0 (0 active) IMP_DATA undef in 'DBD::DB2::dr' [Tue May 8 11:59:41 2001] [notice] Apache/1.3.19 (Unix) mod_perl/1.25 mod_ssl/2.8.3 OpenSSL/0.9.6 configured -- resuming normal operations Note: We don't use Apache::DBI, for the childs we do connection caching ourselves and in the parent (startup.pl) we bootstrap a lot of ressources from the DB to RAM (and disconnect!). Now I've got 4 questions: 1.) What can I do about the Subroutine Filter... redefined messages in the 2nd startup cycle and on further restarts. (They are new with the upgrade.) 2.) What can I do about the DBI handle cleared message in the 3rd startup cycle. (This is not related to the upgrade.) 3.) Why is startup.pl executed THREE times? I thought it would be executed only twice (with PerlFreshRestart ON)? 4.) Why do the redefineds come up in the 2nd startup and on further restarts and the DBI in the 3rd only? Thankscu Michael Jacob
Re: Read file at startup, access data during request?
On Thu, 29 Mar 2001, Richard Anderson wrote:
I want to read and parse a file when Apache mod_perl starts and have access to the
data while my mod_perl methods are processing the request. The most obvious approach
(to me) is to put the reading/parsing code at the beginning of my mod_perl module,
outside of my methods, and load the data into a package array variable that my
methods can access during request processing.
However, I want to put the pathname of the file (relative to ServerRoot) in the
httpd.conf file as a PerlSetVar. I don't see any way to access the value of a
PerlSetVar until the request phase. In other words, in the module code that runs at
startup time, I want to do this:
my $file = $r-server_root_relative($r-dir_config('SharedSecretKeyFile'));
except I don't have the Apache Request object ($r).
Am I completely on the wrong track? Is there some way to access a PerlSetVar
without the request object?
How about this: httpd.conf:
Perl
use My::Preload;
My::Preload::init('SharedSecretKeyFile');
/Perl
But you can do this as well:
my $s = Apache-server;
my $file = $s-dir_config('SharedSecretKeyFile');
The former seems simpler to me...
and it's pretty much all in the guide :)
_
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://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Read file at startup, access data during request?
I want to read and parse a file when Apache mod_perl starts and have access to the
data while my mod_perl methods are processing the request. The most obvious approach
(to me) is to put the reading/parsing code at the beginning of my mod_perl module,
outside of my methods, and load the data into a package array variable that my methods
can access during request processing.
However, I want to put the pathname of the file (relative to ServerRoot) in the
httpd.conf file as a PerlSetVar. I don't see any way to access the value of a
PerlSetVar until the request phase. In other words, in the module code that runs at
startup time, I want to do this:
my $file = $r-server_root_relative($r-dir_config('SharedSecretKeyFile'));
except I don't have the Apache Request object ($r).
Am I completely on the wrong track? Is there some way to access a PerlSetVar without
the request object?
Richard Anderson, Ph.D. www.unixscripts.com
Perl / Java / SQL / Unix [EMAIL PROTECTED]
Raycosoft, LLC Seattle, WA, USA
Re: mod_perl startup sequence?
Title: mod_perl startup sequence? From: Drew Wilson To: [EMAIL PROTECTED] Sent: Monday, 05 March, 2001 08:24 PM Subject: mod_perl startup sequence? I'm confused about when mod_perl loads Perl Modules. It appears my perl module gets loaded twice: once when the log writes to stdout, and once when the log message is written to error-log. I would expect my module to only get loaded once. Why twice? To help me trace loading, I added "print STDERR" statements to my .conf file and my perl module. To my surprise, log messages go to the console, and messages go the log file 30 milliseconds later. Also, the Apache::Server::Starting is 1 first time through, and 0 the second time through. NOTE: PerlFreshRestart is NOT defined. For example, this appears on my console: # .conf started at 983839924.241642, Starting = 1, ReStarting=0 # wierd.pm started at 983839924.274978, Starting = 1, ReStarting=0 # .conf finished at 983839924.277637 And this appears in my error-log: # .conf started at 983839924.285614, Starting = 0, ReStarting=0 # wierd.pm started at 983839924.292273, Starting = 0, ReStarting=0 # .conf finished at 983839924.294823 Notice the difference in execution times (1st ends at 983839924.277637 and the 2nd one starts at 983839924.285614). I have a similar confusion.My httpd.conf opens with LoadModule perl_module modules/mod_perl.soPerl open FIL, "c:\\a.txt"; print FIL "\nStart httpd.conf pid=$$"; close FIL;/PerlAfter starting Apache I have the following in c:\a.txtStart httpd.conf pid=2144Start httpd.conf pid=2144Start httpd.conf pid=2072startup.pl is also run three times.The config is win2k, apache 1.3.17, mod_perl 1.25. The taskmanager shows two apache.exe's running and two cidaemons. I could understand a fallback apache, bit I cannot see why the code is executed twice for the same pid.Can someone explain this behaviour - or tell me where I should go to read about it. (politely!-)TVM - Paul Cotter
mod_perl startup sequence?
Title: mod_perl startup sequence? I'm confused about when mod_perl loads Perl Modules. It appears my perl module gets loaded twice: once when the log writes to stdout, and once when the log message is written to error-log. I would expect my module to only get loaded once. Why twice? To help me trace loading, I added print STDERR statements to my .conf file and my perl module. To my surprise, log messages go to the console, and messages go the log file 30 milliseconds later. Also, the Apache::Server::Starting is 1 first time through, and 0 the second time through. NOTE: PerlFreshRestart is NOT defined. For example, this appears on my console: # .conf started at 983839924.241642, Starting = 1, ReStarting=0 # wierd.pm started at 983839924.274978, Starting = 1, ReStarting=0 # .conf finished at 983839924.277637 And this appears in my error-log: # .conf started at 983839924.285614, Starting = 0, ReStarting=0 # wierd.pm started at 983839924.292273, Starting = 0, ReStarting=0 # .conf finished at 983839924.294823 Notice the difference in execution times (1st ends at 983839924.277637 and the 2nd one starts at 983839924.285614). Here's my simplified .conf Perl use Time::HiRes qw( time ); print STDERR # .conf started at . time() . \n; /Perl PerlModule wierd.pm Location /my_wierd SetHandler perl-script PerlHandler wierd /Location Perl use Time::HiRes qw( time ); print STDERR # .conf finished at . time() . \n; /Perl And here's my simplified wierd.pm package wierd; use strict; use Time::HiRes qw( time ); print STDERR # wierd.pm loaded at . time() . \n; return 1; TIA, drew ==
Re: dir_config at startup: I know what doesn't work, so what does?
On Mon, 22 Jan 2001, Christopher L. Everett wrote:
variable at server startup, using my startup.pl:
...
$config{DBI_DSN} = Apache-server-dir_config('DBI_DSN');
...
PerlSetVar DBI_DSN "DBI:mysql:exchange_db"
is your PerlSetVar before or after PerlRequire for startup.pl?
it must come before for your code to work, which it should, works just
fine for me.
dir_config at startup: I know what doesn't work, so what does?
All:
I want to specify things like MySQL login info, names of tables
containing
user login information. I'd like to do it by putting it all into a
class
variable at server startup, using my startup.pl:
my $Account_Interface = $Exchange::MyAccount-init;
Then inside Exchange::MyAccount::init,
we have code like this:
$config{DBI_DSN} = Apache-server-dir_config('DBI_DSN');
and then of course we have the corresponding
PerlSetVar DBI_DSN "DBI:mysql:exchange_db"
What I'm running into is that dir_config always returns undef, no matter
what:
- PerlSetVars inside or outside the Location tag
- dir_config called at server startup or child startup
I've used dir_config before, but only at the PerlHandler level.
So what I'd like to know is: is there any way of picking up
configuration
info from the httpd-perl.conf at server startup? Picking all this stuff
up with the first request isn't always the most desirable way of doing
it,
especially if processing the directives takes any appreciable amount of
time. Putting config info into other files just spreads out what should
be in a single place.
Thanks,
Christopher Everett
Re: dir_config at startup: I know what doesn't work, so what does?
"Christopher L. Everett" wrote: So what I'd like to know is: is there any way of picking up configuration info from the httpd-perl.conf at server startup? If you don't need to have different configurations for each virtual host or directory, you could just use globals. Perl $MyConfig::DBI_DSN = 'foobar'; /Perl - Perrin
Re: prob with dir_config at server startup
the per_dir_configs (i.e. Location PerlSetVar) are not accessabled from
the Apache::Server. They are only accessable from
Apache::Request::dir_config. It makes sense if you think about it - a
per_dir config can be different for each Location. If you need any config
values in a PerlInitHandler, you need to specify them outside the location
tags.
sterling
"T.J. Mather" wrote:
I'm having a problem accessing PerlSetVar variables with
Apache-server-dir_config at server startup. I'm using the lastest
versions of mod_perl 1.24_01 and apache (1.3.14).
The problem occurs when I use PerlSetVar inside a Directory, Location or
Files section:
in httpd.conf:
Location /
PerlSetVar PKIT_ROOT /home/tjmather/Apache-PageKit/eg
/Location
perl startup code:
my $pkit_root = Apache-server-dir_config('PKIT_ROOT');
# $pkit_root = undef
But if I remove the Location directive, then it works fine:
in httpd.conf:
PerlSetVar PKIT_ROOT /home/tjmather/Apache-PageKit/eg
perl startup code:
my $pkit_root = Apache-server-dir_config('PKIT_ROOT');
# $pkit_root = '/home/tjmather/Apache-PageKit/eg'
Any ideas?
prob with dir_config at server startup
I'm having a problem accessing PerlSetVar variables with
Apache-server-dir_config at server startup. I'm using the lastest
versions of mod_perl 1.24_01 and apache (1.3.14).
The problem occurs when I use PerlSetVar inside a Directory, Location or
Files section:
in httpd.conf:
Location /
PerlSetVar PKIT_ROOT /home/tjmather/Apache-PageKit/eg
/Location
perl startup code:
my $pkit_root = Apache-server-dir_config('PKIT_ROOT');
# $pkit_root = undef
But if I remove the Location directive, then it works fine:
in httpd.conf:
PerlSetVar PKIT_ROOT /home/tjmather/Apache-PageKit/eg
perl startup code:
my $pkit_root = Apache-server-dir_config('PKIT_ROOT');
# $pkit_root = '/home/tjmather/Apache-PageKit/eg'
Any ideas?
Re: 1.24 to 1.24_01 spinning httpds on startup (solved)
On Tue, 28 Nov 2000, Michael J Schout wrote: About a month or 2 ago, I had posted a problem where I tried to upgrade from: ... And reported that after doing this, my httpds would spin on startup. When I turned on MOD_PERL_TRACE=all, it was showing that it was stuck in an infinite loop processing configuration stuff. I posted the mod_perl trace for it as well. I have finally gotten a chance to revisit this and it turns out that what was causing problems was that I had in my httpd.conf: Perl $PerlRequire = '/some/path/file.pl'; /Perl this has been fixed in the cvs tree.
Re: 1.24 to 1.24_01 spinning httpds on startup (solved)
On Tue, 28 Nov 2000, Michael J Schout wrote: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Hmn... Happens to me too after upgrading from 1.24 to 1.24_01 (Apache 1.3.12). #0 0x400fe7f9 in _IO_vfprintf (s=0xbf800474, format=0x81433b5 "_(eval %lu)", ap=0xbf80053c) at vfprintf.c:209 #1 0x4010c0b3 in _IO_vsprintf (string=0xbf80056c "", format=0x81433b5 "_(eval %lu)", args=0xbf80053c) at iovsprintf.c:47 #2 0x4010676f in sprintf (s=0xbf80056c "", format=0x81433b5 "_(eval %lu)") at sprintf.c:38 #3 0x811037c in Perl_pp_entereval () #4 0x80c9997 in perl_eval_sv () #5 0x808b9ee in perl_require_module () #6 0x808a126 in perl_section () #7 0x8089fac in perl_section_self_boot () #8 0x808816a in perl_cmd_require () #9 0x809ffd7 in ap_clear_module_list () #10 0x80a0423 in ap_handle_command () #11 0x8089b34 in perl_handle_command () #12 0x808a445 in perl_section () #13 0x8089fac in perl_section_self_boot () #14 0x808816a in perl_cmd_require () #15 0x809ffd7 in ap_clear_module_list () #16 0x80a0423 in ap_handle_command () #17 0x8089b34 in perl_handle_command () #18 0x808a445 in perl_section () #19 0x8089fac in perl_section_self_boot () [... repeating ...] I don't see any changes to the Perl configure code... Perl $PerlRequire = '/tmp/startup.pl'; /Perl $ cat /tmp/startup.pl warn "works?"; 1; - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.24 to 1.24_01 spinning httpds on startup (solved)
I think I remember a thread on dev that talked about this... http://archive.covalent.net/modperl-cvs/2000/09/0050.xml was maybe the cause of the change in behavior? HTH --Geoff -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 3:12 AM To: Michael J Schout Cc: [EMAIL PROTECTED] Subject: Re: 1.24 to 1.24_01 spinning httpds on startup (solved) On Tue, 28 Nov 2000, Michael J Schout wrote: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Hmn... Happens to me too after upgrading from 1.24 to 1.24_01 (Apache 1.3.12). #0 0x400fe7f9 in _IO_vfprintf (s=0xbf800474, format=0x81433b5 "_(eval %lu)", ap=0xbf80053c) at vfprintf.c:209 #1 0x4010c0b3 in _IO_vsprintf (string=0xbf80056c "", format=0x81433b5 "_(eval %lu)", args=0xbf80053c) at iovsprintf.c:47 #2 0x4010676f in sprintf (s=0xbf80056c "", format=0x81433b5 "_(eval %lu)") at sprintf.c:38 #3 0x811037c in Perl_pp_entereval () #4 0x80c9997 in perl_eval_sv () #5 0x808b9ee in perl_require_module () #6 0x808a126 in perl_section () #7 0x8089fac in perl_section_self_boot () #8 0x808816a in perl_cmd_require () #9 0x809ffd7 in ap_clear_module_list () #10 0x80a0423 in ap_handle_command () #11 0x8089b34 in perl_handle_command () #12 0x808a445 in perl_section () #13 0x8089fac in perl_section_self_boot () #14 0x808816a in perl_cmd_require () #15 0x809ffd7 in ap_clear_module_list () #16 0x80a0423 in ap_handle_command () #17 0x8089b34 in perl_handle_command () #18 0x808a445 in perl_section () #19 0x8089fac in perl_section_self_boot () [... repeating ...] I don't see any changes to the Perl configure code... Perl $PerlRequire = '/tmp/startup.pl'; /Perl $ cat /tmp/startup.pl warn "works?"; 1; - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.24 to 1.24_01 spinning httpds on startup (solved)
About a month or 2 ago, I had posted a problem where I tried to upgrade from: Redhat Linux 6.2, perl 5.6.0 Apache 1.3.12 mod_perl 1.24 mod_ssl 2.6.6 to Redhat Linux 6.2 perl 5.6.0 Apache 1.3.14 mod_perl 1.24_01 mod_ssl 2.7.1 And reported that after doing this, my httpds would spin on startup. When I turned on MOD_PERL_TRACE=all, it was showing that it was stuck in an infinite loop processing configuration stuff. I posted the mod_perl trace for it as well. I have finally gotten a chance to revisit this and it turns out that what was causing problems was that I had in my httpd.conf: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Anyways, I wanted to post this to the list in hopes that this might help others who may have stumbled onto this problem. Regards, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resurrection of startup SIGSEGV with latest CVS snapshot?
On Tue, 3 Oct 2000, Bruce W. Hoylman wrote:
Hello, Doug --
Thanks for the reply.
I have already applied this patch. The backtrace I provided was
producted by an httpd executable with the perl_util.c patch already
applied. The perl 5.6 patch from p5p was also in effect.
bruce, maybe this patch will cure?
From [EMAIL PROTECTED] Fri Oct 13 10:21:16 2000
Date: Sat, 07 Oct 2000 21:32:25 -0700
From: Gurusamy Sarathy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: CGI::Carp, use X, die in X.pm causes 0xc005 (APR#330)
On Fri, 21 Apr 2000 18:12:45 PDT, [EMAIL PROTECTED] wrote:
Full_Name: UENO Kojun
Version: ActivePerl 613
OS: Windows NT 4.0 SP 6
Submission from: (NULL) (210.141.46.3)
Following scripts cause the application error "c005 at address 78002f3e
(strlen)".
% perl x.pl
---x.pl---
#! perl
use CGI::Carp;
use lib '.';
use X;
---X.pm---
package X;
die;
1;
FYI, I just checked in the following fix for this problem. I'm afraid
it is somewhat in the nature of a hack. A proper fix would entail
eliminating save_re_context() and making the regular expression engine
reentrancy-safe, but I chickened out.
Sarathy
[EMAIL PROTECTED]
---8---
Change 7165 by gsar@onru on 2000/10/08 04:15:29
save_re_context() could reset PL_curcop to freed memory, causing core
dumps in code such as Cuse CGI::Carp; use something_that_calls_die;
Affected files ...
... //depot/perl/pp_ctl.c#227 edit
Differences ...
//depot/perl/pp_ctl.c#227 (text)
Index: perl/pp_ctl.c
--- perl/pp_ctl.c.~1~ Sat Oct 7 21:14:39 2000
+++ perl/pp_ctl.c Sat Oct 7 21:14:39 2000
@@ -1417,6 +1417,12 @@
LEAVE;
+ /* LEAVE could clobber PL_curcop (see save_re_context())
+* XXX it might be better to find a way to avoid messing with
+* PL_curcop in save_re_context() instead, but this is a more
+* minimal fix --GSAR */
+ PL_curcop = cx-blk_oldcop;
+
if (optype == OP_REQUIRE) {
char* msg = SvPVx(ERRSV, n_a);
DIE(aTHX_ "%sCompilation failed in require",
End of Patch.
Re: @INC startup under Win32
Carlos Ramirez wrote: Update your PATH evironment variable to include C:\Perl\lib Shouldn't it be PERL5LIB instead, since PATH is responsible for locating executables, not modules? "siberian.org" wrote: Can't location Cwd.pm in @INC (@INC contains C:/WINNT/system32/lib .) at
$r-dir_config at server startup?
Can I get the value of a PerlSetVar at startup?
# Main server config
PerlSetVar foo bar
VirtualHost 80
perl
package My::Handler;
use strict;
# Is there a way to get at 'foo'?
my $foo = Apache-dir_config('foo');
sub handler {
...
}
/perl
Perl*Handler My::Handler;
...
/virturalhost
Bill Moseley
mailto:[EMAIL PROTECTED]
Re: $r-dir_config at server startup?
On Wed, 11 Oct 2000, Bill Moseley wrote:
Can I get the value of a PerlSetVar at startup?
# Main server config
PerlSetVar foo bar
VirtualHost 80
perl
package My::Handler;
use strict;
# Is there a way to get at 'foo'?
my $foo = Apache-dir_config('foo');
Apache-server-dir_config('foo'); # IIRC
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
@INC startup under Win32
Caveat : I have built modperl on a gazillion unix boxes. This win32 is black magic to me so I have no idea what I am doing, I just need to get mod_perl running under NT desperately. That said, here is my current situation. Running ActiveState Perl build 618 Apache 1.3.12 I ppm'd the mod_perl.ppd from theoryx5.uwinnipeg.ca and it installed properly. I then add the LoadModule line to my httpd.conf When apache tries to startup it says : Can't location Cwd.pm in @INC (@INC contains C:/WINNT/system32/lib .) at (eval 1) line 1 Ok, so it can not find my libs which live in C:\Perl\lib. How do I get apache on startup to see the proper lib files? John-
Re: @INC startup under Win32
Update your PATH evironment variable to include C:\Perl\lib -Carlos "siberian.org" wrote: Caveat : I have built modperl on a gazillion unix boxes. This win32 is black magic to me so I have no idea what I am doing, I just need to get mod_perl running under NT desperately. That said, here is my current situation. Running ActiveState Perl build 618 Apache 1.3.12 I ppm'd the mod_perl.ppd from theoryx5.uwinnipeg.ca and it installed properly. I then add the LoadModule line to my httpd.conf When apache tries to startup it says : Can't location Cwd.pm in @INC (@INC contains C:/WINNT/system32/lib .) at (eval 1) line 1 Ok, so it can not find my libs which live in C:\Perl\lib. How do I get apache on startup to see the proper lib files? John- -- --- Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 --- -- Don't make me use uppercase
