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! Sostill 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 slightlyunusual 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 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 thenew 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:
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 thenew 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.
Help -- OpenIndexOptions
I'm installing a new site build ona 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
Help - OpenIndexOptions / AutoIndex...
Also, if I try to load Apache::AutoIndex, and turn off mod_autoindex, the server won't accept the IndexOptions directive...
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 usesApache::Session, DBI::Mysql, HTML::Mason,CGI, andApache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. Iknow 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
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: 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
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]
