More problems with custom config directives (LONG)
Hi there,
I'm another person in the short but persistent line of people who can't
seem to get custom configuration directives to work.
I'm working with the Eagle book on this, and I've read all the relevant
threads I can find in the list archives, but since I'm having a slightly
different problem from the one my fellow strugglers were having, the
advice given to them didn't work for me.
The symptom:
On starting httpd, I get this response:
Testing user file: NewConfigDirective argumentToDirective
I tried doing away with the PerlModule directive and using the workaround
suggested by Doug MacEachern on June 9 2000, which was to put these
statements in the conf file:
Perl
delete $INC{'/path/to/ConfigModule.pm'};
require ConfigModule;
/Perl
but when I do that, I get this:
Testing user file: delete $INC{'Apache/VI/Config.pm'}
In Makefile.PL I have:
package ConfigModule;
## ... (as directed by Eagle)
my @directives = (
{ name = 'NewConfigDirective',
errmsg = 'argument to config directive',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for `ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
According to the Eagle book, I should be able to get rid of the 'args_how'
line as long as I provide a prototype in the subroutine definition, but it
seems I can't.
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not registering the handler
for the new directive, which might explain why I'm getting a syntax error
in the httpd.conf file when the server starts. But what would be causing
that to happen? I'm afraid I'm not familiar enough with the MakeMaker
mechanism to figure out what's going on. Then again, I'm not sure that's
really the problem, so disregard it if you think it's a red herring.
Any advice anyone can give would be very much appreciated.
-mike
=
Details:
mod_perl version used is 1.23
perl version used is 5.005_03
apache version used is 1.3.11
$ perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.5-22, archname=i686-linux
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL'
ccflags ='-Dbool=char -DHAS_BOOL'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
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 -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=true, libperl=libperl.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/perl5/lib/5.00503/i686-linux/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Built under linux
Compiled at Aug 22 1999 14:02:34
@INC:
/usr/perl5/lib/5.00503/i686-linux
/usr/perl5/lib/5.00503
/usr/perl5/lib/site_perl/5.005/i686-linux
/usr/perl5/lib/site_perl/5.005
.
$ /usr/sbin/httpd -V
Server version: Apache/1.3.11 (Unix)
Server built: Feb 1 2000 21:17:00
Server compiled with
-D EAPI
-D EAPI_MM
-D EAPI_MM_CORE_PATH=/var/run/httpd.mm
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FCNTL_SERIALIZED_ACCEPT
default file locations cut
$ /usr/sbin/httpd -l
Compiled-in modules:
http_core.c
mod_so.c
mod_perl.c
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote:
-Original Message-
From: Michael Styer [mailto:[EMAIL PROTECTED]]
In Makefile.PL I have:
snip abbreviated makefile code listing
I'm assuming you have more than that... :-)
Yes. :)
It actually looks like this:
package ConfigModule;
use ExtUtils::MakeMaker;
use Apache::ExtUtils qw(command_table);
use Apache::src ();
my @directives = (
{ name = 'ConfigDirective',
errmsg = 'name of the handler module',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
command_table(\@directives);
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
## required makefile stuff
);
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for
`ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
That's because ConfigModule.pm isn't loaded at the time. You'd have to
require() it or use() it.
Even when the makefile is declared as 'package ConfigModule;' initally?
It seems strange that I would need to write 'package Foo; use Foo;'. Maybe
I don't understand how that works. Would I need a 'use lib ...' statment
there so Makefile.PL would know where to look for ConfigModule.pm?
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not
registering the handler for the new directive, which might explain why
I'm getting a syntax error in the httpd.conf file when the server
starts. But what would be causing that to happen? I'm afraid I'm not
familiar enough with the MakeMaker mechanism to figure out what's
going on. Then again, I'm not sure that's really the problem, so
disregard it if you think it's a red herring.
Are you getting a ConfigModule.xs file written and compiled OK?
Yeah, there don't seem to be any problems writing and compling
ConfigModule.xs. I can get through make, make test, and make install
without any problems; it's just when it comes to starting the server that
I run into the problem.
Details:
mod_perl version used is 1.23
There have been some fairly serious config directives bugs fixed since then.
I suggest an upgrade.
I'll look into it, but my sysadmins are worried that upgrading is going to
break, in strange and obscure ways, the multiple live commercial sites we
have running on our servers. Are there any resources available I might be
able to use to reassure them?
Thanks for your help.
-mike
--
Michael Styer [EMAIL PROTECTED]
phone: 020 7603 5723107 Shepherd's Bush Rd
fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
-Original Message-
From: Michael Styer [mailto:[EMAIL PROTECTED]]
Hi there,
I'm another person in the short but persistent line of people
who can't
seem to get custom configuration directives to work.
:-)
In Makefile.PL I have:
package ConfigModule;
## ... (as directed by Eagle)
my @directives = (
{ name = 'NewConfigDirective',
errmsg = 'argument to config directive',
args_how = 'TAKE1',
req_override = 'RSRC_CONF'
}
);
I'm assuming you have more than that... :-)
and in ConfigModule.pm I have:
sub NewConfigDirective ($$$) {
my ($cfg, $parms, $arg) = @_;
$cfg-{'NewConfigDirective'} = $arg;
}
One clue I've found as to where something might be going wrong is that
when I comment out the 'args_how' line in Makefile.PL and run 'perl
Makefile.PL' I get this error:
Can't determine prototype for
`ConfigModule::NewConfigDirective': at
/usr/perl5/lib/site_perl/5.005/i686-linux/Apache/ExtUtils.pm line 133.
That's because ConfigModule.pm isn't loaded at the time. You'd have to
require() it or use() it.
So it looks as though something isn't reading ConfigModule.pm on
WriteMakefile or on command_table and possibly not
registering the handler
for the new directive, which might explain why I'm getting a
syntax error
in the httpd.conf file when the server starts. But what would
be causing
that to happen? I'm afraid I'm not familiar enough with the MakeMaker
mechanism to figure out what's going on. Then again, I'm not
sure that's
really the problem, so disregard it if you think it's a red herring.
Are you getting a ConfigModule.xs file written and compiled OK?
Details:
mod_perl version used is 1.23
There have been some fairly serious config directives bugs fixed since then.
I suggest an upgrade.
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
-Original Message- From: Michael Styer [mailto:[EMAIL PROTECTED]] That's because ConfigModule.pm isn't loaded at the time. You'd have to require() it or use() it. Even when the makefile is declared as 'package ConfigModule;' initally? It seems strange that I would need to write 'package Foo; use Foo;'. Maybe I don't understand how that works. Would I need a 'use lib ...' statment there so Makefile.PL would know where to look for ConfigModule.pm? Nah, you can do require(ConfigModule.pm) and it'll work. Are you getting a ConfigModule.xs file written and compiled OK? Yeah, there don't seem to be any problems writing and compling ConfigModule.xs. I can get through make, make test, and make install without any problems; it's just when it comes to starting the server that I run into the problem. OK, can you describe the problem a little more clearly? The Testing user file bit doesn't seem to come from anywhere - any ideas where it's coming from??? Details: mod_perl version used is 1.23 There have been some fairly serious config directives bugs fixed since then. I suggest an upgrade. I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: More problems with custom config directives (LONG)
I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. The (possibly a slightly obvious point) way I'd recommend dealing with this is to test everything on your development machine(s), make sure it all works, and the upgrade hasn't broken anything, and then upgrade the live systems, with plans to revert if it all goes wrong, and so on - the same way you'd make any other serious upgrade to an important live system. If you don't have systems you can test everything out on, you have a serious problem and should probably deal with this first. Michael http://www.iii.co.uk Interactive Investor International is a leading UK Internet personal finance service that provides individuals with the capability to identify, compare, monitor and buy online a number of financial products and services. Interactive Investor Trading Limited, a subsidiary of Interactive Investor International plc, is regulated by the SFA.
RE: More problems with custom config directives (LONG)
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 22, 2001 6:41 AM To: 'Michael Styer'; Matt Sergeant Cc: [EMAIL PROTECTED] Subject: RE: More problems with custom config directives (LONG) [snip] I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. well, I think this really depends on your situation. directive handlers are not as robust as they could be, we all know that. but I've had Apache::Dispatch (which uses directive handlers) running in production since December without any issues. bottom line is (as always) never put anything into production that hasn't been sufficiently stressed in development. --Geoff
RE: More problems with custom config directives (LONG)
On Wed, 22 Aug 2001, Matt Sergeant wrote: OK, can you describe the problem a little more clearly? The Testing user file bit doesn't seem to come from anywhere - any ideas where it's coming from??? I had assumed it was coming from Apache, but your question made me suspicious. After a little digging, I discovered it's coming from a userv script that is used to restart development apache daemons so all us lowly developers don't need to have su priveleges ;). I won't bother you with the details, except to say it didn't permit adding config directives. Having fixed that, the server restarts fine, which means the new directives are getting read properly, but when I try to hit that development vhost with my browser the child segfaults. Which is where I'm stuck now. Details: mod_perl version used is 1.23 There have been some fairly serious config directives bugs fixed since then. I suggest an upgrade. I'll look into it, but my sysadmins are worried that upgrading is going to break, in strange and obscure ways, the multiple live commercial sites we have running on our servers. Are there any resources available I might be able to use to reassure them? No! They have every right to be concerned. Don't try this stuff on a live server, seriously. I do it on axkit.org (at least I did it on axkit.org when it was live), but there was never anything business critical on there except documentation. Don't worry, it's all happening on an isolated development server, I was just wondering whether there are any resources that indicate what things might break when upgrading from 1.23 to 1.24. But if I can't get this working soon time pressure will force me to use the functional but much less elegant PerlSetVar method, and an upgrade will be irrelevant. Any advice (from anyone) on how to fix the segfault problem would still be appreciated, though. Many thanks to all for the advice I've received already. -mike -- Michael Styer [EMAIL PROTECTED] phone: 020 7603 5723107 Shepherd's Bush Rd fax: 020 7603 2504 London W6 7LP
RE: More problems with custom config directives (LONG)
Don't worry, it's all happening on an isolated development server, I was just wondering whether there are any resources that indicate what things might break when upgrading from 1.23 to 1.24. But if I can't get this working soon time pressure will force me to use the functional but much less elegant PerlSetVar method, and an upgrade will be irrelevant. Any advice (from anyone) on how to fix the segfault problem would still be appreciated, though. you'll want to move to at least 1.25 with directive handlers (well, actually 1.24_01 IIRC) due to a major bug fix, the nature of which is escaping me this morning but can be found in the archives. --Geoff
