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
