Re: am i heading for disaster... ?
I definitely didn't run out of disk space, so it must have been something
else. There were a number of funky things that happened over the course of
the build. The first time around, I made mod_perl, then made mod_ssl, and
had an error about util.o being out of sync with mod_ssl, so then I ran the
mod_perl make a second time, without cleaning first. Maybe the file got
erased in the process. The next time I ran apache make, I had a linker
error and had to set LD_LIBRARY_PATH explicitly to correct it. Maybe I
needed to do the same while building mod_perl.
But, knock on wood, the server hasn't choked yet, or behaved weirdly. Guess
I'll find out when it goes into production...
Thanks
- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Noam Solomon" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 12:39 PM
Subject: Re: am i heading for disaster... ?
> Noam Solomon wrote:
> > In the process of building apache_1.3.27 / mod_perl 1.3.27 /
> > openssl0.9.6g / mod_ssl mod_ssl-2.8.12-1.3.27 on a Solaris OS 2
> > UltraSparc, with Perl 5.8, the apache make failed because of an
> > undefined "url_delims". I was using the method where you build mod_ssl,
> > then build mod_perl, then configure apache, loading mod_perl statically.
> >
> > Anyway, I poked around and found that indeed the uri_delims.h file in
> > src/main was empty! So still in src/main, I manually ran "gcc
> > gen_uri_delims.c", then ran "a.out > uri_delims.h" to regenerate that
> > header file, and got this.
> >
> >
> > /* this file is automatically generated by gen_uri_delims, do not
> > edit */
> > static const unsigned char uri_delims[256] = {
> > T_NUL,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,T_HASH,0,0,0,0,
> > 0,0,0,0,0,0,0,T_SLASH,0,0,0,0,0,0,0,0,0,0,T_COLON,0,
> > 0,0,0,T_QUESTION,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> > };
> >
> > Then when I ran make again, everything was hunky-dory. Now what I want
> > to know is, why would this have happened in the first place? Is it a
> > sign that something is fundamentally wrong with the build, but I just
> > haven't seen it yet? Or should I just breathe easy and hope for the
best?
>
> I doubt this has anything to do with mod_perl. The build hasn't changed
> in years, so it must be some external glitch. For example you might have
> run out of disk space, so when it was writing the file it was zeroed.
>
>
> --
>
>
> _
> 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/
>
>
>
am i heading for disaster... ?
In the process of building apache_1.3.27 / mod_perl
1.3.27 / openssl0.9.6g / mod_ssl mod_ssl-2.8.12-1.3.27 on a Solaris OS 2
UltraSparc, with Perl 5.8, the apache make failed because of an undefined
"url_delims". I was using the method where you build mod_ssl, then build
mod_perl, then configure apache, loading mod_perl statically.
Anyway, I poked around and found that indeed the
uri_delims.h file in src/main was empty! So still in src/main, I
manually ran "gcc gen_uri_delims.c", then ran "a.out > uri_delims.h" to
regenerate that header file, and got this.
/* this file is automatically
generated by gen_uri_delims, do not edit */static const unsigned char
uri_delims[256] = {
T_NUL,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,T_HASH,0,0,0,0,
0,0,0,0,0,0,0,T_SLASH,0,0,0,0,0,0,0,0,0,0,T_COLON,0,
0,0,0,T_QUESTION,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
Then when I ran make again, everything was
hunky-dory. Now what I want to know is, why would this have happened in
the first place? Is it a sign that something is fundamentally wrong with
the build, but I just haven't seen it yet? Or should I just breathe easy
and hope for the best?
OS X 10.1.5 problem: alloc.c not compiling mod_perl-1.27 / apache_1.3.26
The subject more or less says it all. I've found one bug report online which is pretty similar, but does not say much about a solution: http://citadelle.intrinsec.com/mailing/current/HTML/ml_apache-server-bugs/0424.html The errors look like: alloc.c: in function 'spawn_child_core': alloc.c: 2291'STDIN_FILENO' undeclared alloc.c: 2297 'STDIN_FILENO' undeclared alloc.c: 2303 'STDIN_FILENO' undeclared The compile command is the basic: sudo perl Makefile.PL src="../apache_1.3.26/src" USE_APACI=1 EVERYTHING=1 DO_HTTPD=1 The one thing that is perhaps slightly unusual about the installation is that it's entirely offline. This is an unfortunate fact of the security conscious network environment I'm operating in.
Re: custom directives, again...
To solve the second problem (Apache::Icon not loading its directives properly), I ended up commenting out all the "AddModule" statements as well as the "ClearModuleList" statement in the httpd.conf fiile. I don't really know why this fixed the problem, but I suppose it's related to having statically compiled all the basic modules directly into the httpd binary. The answer came to me when I belatedly remembered having encountered a similar problem a couple months ago on my development server, where I had httpd dynamically loading its binaries, and the problem then turned out to be that I had some modules loading in the wrong order. Hope this helps someone somewhere down the line! - Original Message - From: "Per Einar Ellefsen" <[EMAIL PROTECTED]> To: "Noam Solomon" <[EMAIL PROTECTED]> Cc: "Mod-perl list" <[EMAIL PROTECTED]> Sent: Monday, June 17, 2002 6:37 PM Subject: Re: custom directives, again... > At 00:25 18.06.2002, Noam Solomon wrote: > >Thanks -- that got me over one hurdle! Next one: > > > >Syntax error on line 382 of /home/build/httpd/server/./conf/httpd.conf: > >Invalid command 'AddIconByEncoding', perhaps mis-spelled or defined by a > >module not included in the server configuration > >I've replaced the startup.pl call with: > > > > #PerlModule Apache::AutoIndex > > PerlModule Apache::OpenIndex > > PerlModule Apache::Icon > > PerlModule Apache::AuthCookie > >Switching on AutoIndex versus OpenIndex makes no difference. > > > >Any idea what could be going on here? I just tried reinstalling > >Apache::Icon, with > >no improvement. > > Sorry, I'm at a loss here. > > > > >Thanks
nightmare -- ignored custom directives
(Please disregrard previous message I hit send prematurely...) I'm writing again about the problem I was having yesterday with modules being unable to set their own custom directives. This is becoming my own private nightmare, and I am certain it is the result of a very stupid move I made: somehow in my initial grapplings, I upgraded from what I thought was mod_perl 1.24 to what I thought was mod_perl 1.26, with the new libraries installed, either fully or partially (I'm a bit unclear on this part), in the main PERL5LIB. At one point today I got a message: usr/local/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is version 1.27Perhaps you forgot to 'make install' or need to uninstall an old version?Found: /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pmFound: /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache.pmApache.pm version 1.26 required! which makes me wonder if maybe the supposed 1.26 I installed was really 1.27. Since noticing all of this, I've been frantically trying to rebuild modules, on the assumption that maybe one of them links with an outdated Apache::ExtUtils and somehow blocks other modules from linking in their directives to the command_table. Is this a possibility? If so, what is the best way to make sure I am starting with a good perl library that matches with the mod_perl linked into the httpd binary? Will I need to rebuild all modules that require Apache. Sorry for the sprawling message, and thanks in advance for any advice.
nightmare with custom directives being ignored
I'm writing again about the problem I was having yesterday with modules being unable to set their own custom directives. This is becoming my own private nightmare, and I am certain it is the result of a very stupid move I made: somehow in my initial grapplings, I upgraded from what I thought was mod_perl 1.24 to what I thought was mod_perl 1.26, with the new libraries installed, either fully or partially (I'm a bit unclear on this part), in the main PERL5LIB. At one point today I got a message:
Help - OpenIndexOptions / AutoIndex...
Also, if I try to load Apache::AutoIndex, and turn off mod_autoindex, the server won't accept the IndexOptions directive...
Help -- OpenIndexOptions
I'm installing a new site build on a production server, where I've built mod_perl 1.24 statically into Apache 1.20. Everything works nicely, except that one of the modules can't set it's own custom directives, and apache balks with a syntax error whenever it encounters one. I've tried moving all the PerlModule directives into a startup.pl file, with no effect. (from the error log:) Invalid command 'OpenIndexOptions', perhaps mis-spelled or defined by a module not included in the server configuration (from httpd -l:) Compiled-in modules: http_core.c mod_so.c mod_perl.c
Porting to OS X
Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
Apache::OpenIndex question
Hi,
Anyone know what might be going on in this error message?
[Tue Mar 12 12:03:59 2002] [error] [client 192.168.1.25]
Apache::OpenIndex internal error: NULL command
[Tue Mar 12 12:03:59 2002] [error] Can't use an undefined value as an
ARRAY reference at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/OpenIndex.pm line 566.
Here are lines 564-566...
sub plain_page {
my ($r,$args,$dirhandle,$mode,$isroot)=@_;
my $cfg = Apache::ModuleConfig->get($r);
my $ignore_regex = join('$|^',@{$cfg->{ignore}});
Thanks,
Noam Solomon
Re: big problems with GDBM / MLDBM on solaris
mucho gracia! Jonathan Swartz wrote: > One option is to switch to Berkeley DB (DB_File) - I believe it is much more > stable and maintained. Don't know how much data transfer that would involve, > though. > > > -Original Message- > > From: Noam Solomon [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 10, 2001 11:56 PM > > To: [EMAIL PROTECTED] > > Cc: Stas Bekman; Jonathan Swartz; Geoffrey Young; Desmond Poyser > > Subject: big problems with GDBM / MLDBM on solaris > > > > > > hopefully some of you have seen this before and can offer > > some advice. We have a site we've developed on linux > > boxes and are now moving it over to a solaris box. it runs > > mod_perl 1.25 / HTML-Mason 2.02 / Stronghold 3 / Perl 5.6.1 > > and uses GDBM_File for cacheing. We are getting lots of > > these all over the place: > > > > Can't locate object method "TIEHASH" via package "GDBM_File" > > > > It affects all of mason's cacheing as well as some critical routines > > we wrote ourselves. > > > > We installed libgdbm (1.8) on the system and it appears to > > run from the command line, although i still have my doubts > > about whether when we built PERL the dynamic loadable library > > paths were correct (we ended up running Configure and make > > with "LD_LIBRARY_PATH=/usr/local/lib" on the command line > > to get it working). > > > > Any idea what's up? Could it just be permission problems? > > Should we rebuild perl? It's pretty urgent, so any ideas would > > be greatly appreciated ASAP! > > > > -Noam > >
big problems with GDBM / MLDBM on solaris
hopefully some of you have seen this before and can offer some advice. We have a site we've developed on linux boxes and are now moving it over to a solaris box. it runs mod_perl 1.25 / HTML-Mason 2.02 / Stronghold 3 / Perl 5.6.1 and uses GDBM_File for cacheing. We are getting lots of these all over the place: Can't locate object method "TIEHASH" via package "GDBM_File" It affects all of mason's cacheing as well as some critical routines we wrote ourselves. We installed libgdbm (1.8) on the system and it appears to run from the command line, although i still have my doubts about whether when we built PERL the dynamic loadable library paths were correct (we ended up running Configure and make with "LD_LIBRARY_PATH=/usr/local/lib" on the command line to get it working). Any idea what's up? Could it just be permission problems? Should we rebuild perl? It's pretty urgent, so any ideas would be greatly appreciated ASAP! -Noam
Re: Problem with libapreq on RH 6.2
Hi, your system may have perl libraries installed in more than one place -- set the PERLLIB variable in the root profile to all the places perl modules may be (if you have multiple copies of perl, just stick together the @INC from the different ones, or pick one that works...). here's an example from a root .bash_profile on a machine that had that problem: PERLLIB="/usr/lib/perl5/5.6.0/i386linux:/usr/lib/perl5/5.6.0:/usr/lib/perl5/site_perl/5.6.0/i386-linux:/usr/lib/perl5/site_perl/5.6.0:/usr/lib/perl5/site_perl:/usr/local/lib/perl5/5.6.0/i586linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i586-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:.:/usr/local/lib/perl5/5.6.0/i686-linux:/usr/local/lib/perl5/5.6.0:/usr/local/lib/perl5/site_perl/5.6.0/i686-linux:/usr/local/lib/perl5/site_perl/5.6.0:/usr/local/lib/perl5/site_perl:." export ... PERLLIB ... -Noam x Andy Williams wrote: > I have seen mails flying around about a problem on RH using RPMs for > Apache/mod_perl and libapreq. > So I decided to build Apache (1.3.17), mod_perl (1.25) and libapreq > (0.31_03) from source. > > All installed without any suggestion of a problem. However, when I try to > run Apache (configured to use OpenInteract 1.05) I get the following > error: > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Request : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Request/Request.so' > for module Apache::Request: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 4. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > OpenInteract::Startup::require_module (236) >> --require error: > Apache::Cookie : Can't load > '/usr/lib/perl5/site_perl/5.005/i386-linux/auto/Apache/Cookie/Cookie.so' > for module Apache::Cookie: libapreq.so.0: cannot open shared object file: > No such file or directory at > /usr/lib/perl5/5.00503/i386-linux/DynaLoader.pm line 169, chunk 5. > > at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 > > Does anyone have any idea why this is happening? > > TIA > > Andy > > > > "Talkie Toaster: Given that God is infinite, and that the > Universe is also infinite, would you like a toasted tea > cake?" > >
DBI segmentation fault only in mod_perl
Hi,
I've been working with HTML::Mason and have been unable to connect
to mysql with DBI. There is a problem with the configuration on my
machine
such that perl won't check
/usr/local/lib/perl5/site_perl/5.6.0/i586-linux/ for
modules unless it's explicitly asked to. I don't really know why that
is or how
I would fix it.
In any case, if I make a file startup.pl like:
#
use lib "/usr/local/lib/perl5/site_perl/5.6.0/i586-linux";
# this is a test
use DBI;
unless ( $dbh =
DBI->connect("DBI:mysql:adatabase","test","",{PrintError=>0})) {
print STDERR "unable to get dbi connection: $DBI::errstr\n";
}
print STDERR "successfully created dbh $dbh\n";
$dbh->disconnect;
1;
#
and run it from the command line, it works. If I PerlRequire it in my
httpd.conf
I get a segmentation fault when I run "apachectl configtest". The last
frame of
the stack in the core dump is as follows:
###
#0 0x402125aa in mysql_real_connect (mysql=0x0, host=0x0,
user=0x82caf60 "test", passwd=0x0,
db=0x82c8c58 "adatabase", port=0, unix_socket=0x0, client_flag=0) at
libmysql.c:1125
1125libmysql.c: No such file or directory.
What's going on? Any help would be much appreciated!
- Noam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
