Memory issues with DSO
I am experimenting with using mod_perl 1.2x as a DSO and have noticed that it does not share much memory between process and also seems to utilize much more memory. I thought that it is possible to use mod_perl 1.2x as a DSO when perl is compile with -Uusemymalloc and -Ubincompat5005 which it is. Is this a know issue and should building a DSO in mod_perl 1.x versions just be avoided? Thanks, Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.18-3smp, archname=i386-linux uname='linux warehouse-dev.spacdock.com 2.4.18-3smp #1 smp thu apr 18 07:27:31 edt 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Ubincompat5005 -Uusemymalloc -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.3 2.96-110)', 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' -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
Hi there, On Fri, 29 Aug 2003, Stathy G. Touloumis wrote: should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. Thanks, I will check the archives. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Memory issues with DSO
Sorry that I neglected to list all info : Apache version 1.3.27 mod_perl version 1.26 OS version RedHat Linux 2.4.20-18.7 perl -V : Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.18-3smp, archname=i386-linux uname='linux warehouse-dev.spacdock.com 2.4.18-3smp #1 smp thu apr 18 07:27:31 edt 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Ubincompat5005 -Uusemymalloc -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.3 2.96-110)', 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' -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
static linking vs DSO linking
At a recent client, I had the mandate to develop a front/back server setup, with the front being a thin mod_proxy setup and the back being a fat mod_perl setup. One of the things I noticed while compiling and deploying Apache on Solaris via the pmap command is that the static linking and selective loading (via LoadModule) didn't really save me that much stuff... only the AddModule selected whether the module had been activated, and therefore allocated its private memory. Has anyone else seen this? Am I crazy for suggesting that DSO doesn't really gain you much, and a simple selective AddModule is enough? Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? I want the backend's mod_perl usage to be fat: that's the whole point of the divergence. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: static linking vs DSO linking
Hi Randal, On 11 Jun 2003, Randal L. Schwartz wrote: Am I crazy for suggesting that DSO doesn't really gain you much...? 'Sfunny you should say that... Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? Never had to worry about it a great deal, I usually just throw RAM or boxes at it. Maybe you could have a look at Squid or something? 73, Ged. -- On Tue, 10 Jun 2003, Ged Haywood wrote: On Tue, 10 Jun 2003, Forrest Aldrich wrote: I wonder if this will affect anything else, especially other things that require DSO support. ? Have you got the Eagle Book? You need --enable-module=so in your configure arguments to put mod_so into Apache, mod_so allows Apache to load shared objects. What does --enable-shared=max imply to Apache... make as much as possible as shared objects, the idea being to make the resulting binary smaller. It won't save any memory if you run it with tons of modules loaded, so it's probably more trouble than it's worth. Which is my opinion of DSO generally. I always build static if I can.
HTML::Mason and mod_perl issues with DSO?
With regard to the RT (http://www.fsck.com/rt) program, there were notes in the README file that said mod_perl DSO has/had massive scalability problems when using HTML::Mason. I inquired to the RT author, who isn't certain that issues till persists - so I also inquired to the HTML::Mason people. However, I wanted to also inquire -here- since some people might know more about the problem - I guess it had to do with random segfaults - and I imagine this might be in larger-scale operations (ie: the reference to scalability) so the problem might not be seen unless the system has a larger load. I'm not sure. Any info/tips/pointers on this issue would be appreciated. Forrest
Re: HTML::Mason and mod_perl issues with DSO?
From: Forrest Aldrich [EMAIL PROTECTED] With regard to the RT (http://www.fsck.com/rt) program, there were notes in the README file that said mod_perl DSO has/had massive scalability problems when using HTML::Mason. This is probably old info based on the DSO build shipped through RedHat 7.2. Somewhere as an update to the 7.2 release they got it right and it is solid at least through 7.3 and its updates. The only quirk is that there is a memory leak if you attempt graceful restarts so it is always best to stop/start. I'm not sure about RH8/9 with apache 2.x/mp2. --- Les Mikesell [EMAIL PROTECTED]
Re: [mp1] Partial success working on Tru64/DSO
(... revisiting old thread about my problems with compiling
apache/mod_perl as DSO on Tru64 unix)
My problem is still not solved but I get it up to the point where it
probably lies in some customary modules (which does not behave
correctly when unloaded/reloaded) and is not directly related to
apache/mod_perl.
As I got the minimal success (some simple mod_perl application
worked), I report here the way I compiled perl/apache/mod_perl in
that case. Maybe it will help someone in similar situation.
Below I cite the main parts of the script I used (with unnecessary
details omitted):
WORK_DIR=$HOME/tools_src
DIST_DIR=$HOME/DOWNLOAD
INST_DIR=$HOME/tools
PERL_INST_DIR=$INST_DIR/perl
APACHE_INST_DIR=$INST_DIR/apache
PERL_VERSION=perl-5.6.1
APACHE_VERSION=apache_1.3.27
MOD_PERL_VERSION=mod_perl-1.27
LIBAPREQ_VERSION=libapreq-1.0
DIGEST_MD5_VERSION=Digest-MD5-2.20
MIME_BASE64_VERSION=MIME-Base64-2.12
# ... cut a lot of other modules which are out-of-topic here
#
unpack() {
if [ -d $1 ]; then
rm -rf $1
fi
echo -n Unpacking $1...
gunzip -c $DIST_DIR/$1.tar.gz | tar xf -
echo done
}
#
if [ ! -d $WORK_DIR ]; then
mkdir -p $WORK_DIR
fi
if [ ! -d $INST_DIR ]; then
mkdir -p $INST_DIR
fi
#
cd $WORK_DIR
unpack $PERL_VERSION
cd $PERL_VERSION
# Some commments:
# -Uinstallusrbinperl in my case I use customary install directory
# -Uuseshrplib there is a makefile problem and compilation error
# when we define it (which we try to patch below, so please
# experiment if you like)
# -Uusemymalloc on 64bit platforms it is recommended according to some docs
# -Ubincompat5005 we don't want coredumps caused by name conflicts
# of malloc/free
# -Dusemultiplicity it helps a bit with DSO reloading
sh Configure -des -Dprefix=$PERL_INST_DIR -Uinstallusrbinperl \
-Uuseshrplib -Uusemymalloc -Ubincompat5005 \
-Dusemultiplicity
make
make test
make install
# don't forget it when installing outside defaults
PATH=$PERL_INST_DIR/bin:$PATH; export PATH
#
build_module() {
MOD=$1
cd $WORK_DIR
unpack $MOD
cd $WORK_DIR/$MOD
perl Makefile.PL $2 $3 $4 $5 $6 $7 $8 $9
make
make test
make install
}
build_module $DIGEST_MD5_VERSION
build_module $MIME_BASE64_VERSION
# ... cut others ...
#
unpack $APACHE_VERSION
unpack $MOD_PERL_VERSION
cd $WORK_DIR/$MOD_PERL_VERSION
perl Makefile.PL $PERL_MOD_DBG $PLTRACE \
APACHE_SRC=../$APACHE_VERSION/src \
APACHE_PREFIX=$APACHE_INST_DIR \
USE_APACI=1 \
USE_DSO=1 \
DO_HTTPD=1 \
ALL_HOOKS=1 \
EVERYTHING=1 \
APACI_ARGS=--enable-module=so,\
--prefix=$APACHE_INST_DIR,\
--enable-module=access,--enable-shared=access,\
--enable-module=actions,--enable-shared=actions,\
--enable-module=alias,--enable-shared=alias,\
--enable-module=asis,--enable-shared=asis,\
--enable-module=auth,--enable-shared=auth,\
--enable-module=auth_anon,--enable-shared=auth_anon,\
--enable-module=auth_db,--enable-shared=auth_db,\
--enable-module=auth_dbm,--enable-shared=auth_dbm,\
--enable-module=autoindex,--enable-shared=autoindex,\
--enable-module=cern_meta,--enable-shared=cern_meta,\
--enable-module=cgi,--enable-shared=cgi,\
--enable-module=digest,--enable-shared=digest,\
--enable-module=dir,--enable-shared=dir,\
--enable-module=env,--enable-shared=env,\
--enable-module=example,--enable-shared=example,\
--enable-module=expires,--enable-shared=expires,\
--enable-module=headers,--enable-shared=headers,\
--enable-module=imap,--enable-shared=imap,\
--enable-module=include,--enable-shared=include,\
--enable-module=info,--enable-shared=info,\
--enable-module=log_agent,--enable-shared=log_agent,\
--enable-module=log_config,--enable-shared=log_config,\
--enable-module=log_referer,--enable-shared=log_referer,\
--enable-module=mime,--enable-shared=mime,\
--enable-module=mime_magic,--enable-shared=mime_magic,\
--enable-module=mmap_static,--enable-shared=mmap_static,\
--enable-module=negotiation,--enable-shared=negotiation,\
--enable-module=proxy,--enable-shared=proxy,\
--enable-module=rewrite,--enable-shared=rewrite,\
--enable-module=setenvif,--enable-shared=setenvif,\
--enable-module=speling,--enable-shared=speling,\
--enable-module=status,--enable-shared=status,\
--enable-module=unique_id,--enable-shared=unique_id,\
--enable-module=userdir,--enable-shared=userdir
RE: 1.3.27 DSO hassles
I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ 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: 1.3.27 DSO hassles
Hi-- I also had this problem when I built on Solaris (2.7). Here is how I fixed it: The symbol is in libgcc.a. Use gcc -print-libgcc-file-name to see where that file is. Now, delete mod_negotiation.so and re-make. See how make does the link. Then, just re-link adding the file to the command line. I think you have to do it for one other module as well, but I don't remember which one. I never came up with a fully automated way to do it, but I didn't rebuild Apache that often. -P - Original Message - From: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] To: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 12:40 PM Subject: RE: 1.3.27 DSO hassles I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ 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: 1.3.27 DSO hassles
Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul Weiss who provided the hint. Configure and install Apache Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl into the core) cd apache_1.3.27/src/modules ld -G -o mod_negotiation.so mod_negotiation.lo /pathto/libgcc.a This will extract the floatdisf function from libgcc.a and link it into mod_negotiation.so which can be verified with nm. The libgcc.a archive will be contained into your gcc build tree under gcc-3.2.1/gcc Thanks to all who replied. Alan -Original Message- From: Paul Weiss [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 11:20 AM To: Sinclair, Alan (CORP, GEAccess); [EMAIL PROTECTED] Subject: Re: 1.3.27 DSO hassles Hi-- I also had this problem when I built on Solaris (2.7). Here is how I fixed it: The symbol is in libgcc.a. Use gcc -print-libgcc-file-name to see where that file is. Now, delete mod_negotiation.so and re-make. See how make does the link. Then, just re-link adding the file to the command line. I think you have to do it for one other module as well, but I don't remember which one. I never came up with a fully automated way to do it, but I didn't rebuild Apache that often. -P - Original Message - From: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] To: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 12:40 PM Subject: RE: 1.3.27 DSO hassles I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ 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: 1.3.27 DSO hassles
Sinclair, Alan (CORP, GEAccess) wrote: Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul Weiss who provided the hint. Configure and install Apache Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl into the core) cd apache_1.3.27/src/modules ld -G -o mod_negotiation.so mod_negotiation.lo /pathto/libgcc.a This will extract the floatdisf function from libgcc.a and link it into mod_negotiation.so which can be verified with nm. The libgcc.a archive will be contained into your gcc build tree under gcc-3.2.1/gcc Thanks to all who replied. Fantastic! I've documented this solution at http://perl.apache.org/docs/1.0/guide/troubleshooting.html (auto-update pending) Thank you! __ 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
1.3.27 DSO hassles
All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. Any ideas Thanks Alan
Re: 1.3.27 DSO hassles
Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ 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: 1.3.27 DSO hassles
In message [EMAIL PROTECTED], Stas Bekman writes: There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. Apache/modperl works fine for me as DSO under Solaris 7,8,9. 2.6 is EOL, but I suspect it will work with latest recommended patches. Using gcc2.95.3 Using perl5.8, but also worked under 5.6.1 and 5.00503 Build openssl ./config --prefix=/opt/openssl \ --openssldir=/opt/openssl shared env LD_RUN_PATH=/opt/openssl/lib make Build Apache/mod_ssl ./configure --with-apache=../apache_1.3.27 cd ../apache_1.3.27 env SSL_BASE=/opt/openssl ./configure --prefix=/opt/apache \ --enable-module=most --enable-shared=max # Add the var CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to the env command if you want largefiles or built your perl that way # Edit src/modules/ssl/Makefile and add -R$(SSL_LIBDIR) to SSL_LDFLAGS # If using gcc2, edit src/modules/proxy/Makefile and add -L/path/to/gcc-lib/$host_info/$gcc_version/ -lgcc to LIBS_SHLIB Build modperl perl Makefile.PL USE_APXS=1 WITH_APXS=/opt/apache/bin/apxs \ EVERYTHING=1 PERL_TRACE=1 John [EMAIL PROTECTED]
Re: [mp1] Still can not get working DSO configuration on Tru64
Stas Bekman [EMAIL PROTECTED] writes: Marcin Kasperski wrote: [...] It seems to me, they had problem with the '-Wl,-rpath' issue which I found to be minor and easily patched (by the way: maybe someone would want to correct it in distribution?). I wasn't following that thread, but if you send a patch that solves that problem, I'd be more than happy to commit it to the main distro. Hmm, so far I can only offer 'half-patch' and the problem explanation (I do not understand configure scripts well enough to guess how to correct them). The problem is that the -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE option (which, by the way, is returned by perl -V:ccdlflags when perl is compiled with -Duseshrplib) is not an option for 'ld' but for 'cc'. In fact it means 'dear cc, be so kind and pass to ld the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does not know '-Wl' and complains. As perl -V:ld returns 'ld', maybe this is the problem in perl, not in modperl, but I am not sure. I patched it just by replacing 'ld' with 'cc' in the Makefile generated by configure script - such correction caused link step to succeed (and 'unresolved PL_perl_destruct_level to be reported while apache startup' :-( ) Currently I plan to check the opposite correction (using -rpath ... and ld as link command), maybe this will change something. -- ( Marcin Kasperski | Working overtime sucks the spirit and motivation ) ( http://www.mk.w.pl | out of a team. (Wells) ) () ( Porady dla twrcw serwisw WWW: http://www.mk.w.pl/porady/porady_www )
Re: [mp1] Still can not get working DSO configuration on Tru64
The problem is that the -Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE option (which, by the way, is returned by perl -V:ccdlflags when perl is compiled with -Duseshrplib) is not an option for 'ld' but for 'cc'. In fact it means 'dear cc, be so kind and pass to ld the option -rpath /tools/perl/lib/5.6.1/alpha-dec_osf/CORE). ld does not know '-Wl' and complains. As perl -V:ld returns 'ld', maybe this is the problem in perl, not in modperl, but I am not sure. I patched it just by replacing 'ld' with 'cc' in the Makefile generated by configure script - such correction caused link step to succeed (and 'unresolved PL_perl_destruct_level to be reported while apache startup' :-( ) Currently I plan to check the opposite correction (using -rpath .. and ld as link command), maybe this will change something. I tried it - I left ld as link command but replaced in Makefile -Wl,-rpath,/tools/... with -rpath /tools/... The results are exactly the same: link succeeded, PL_perl_destruct_level is unresolved while running apache. -- ( Marcin Kasperski | Communication takes place between people, documents ) ( http://www.mk.w.pl |are secondary. (Booch) ) () ( Sztuczki i kruczki w C++: http://www.mk.w.pl/porady/porady_cplusplus )
Re: [mp1] Still can not get working DSO configuration on Tru64
The results are exactly the same: link succeeded, PL_perl_destruct_level is unresolved while running apache. I found the workaround to avoid this effect: slightly patching apache build procedure so that the httpd binary is linked with perl libperl.so helped. The error disappears... now I get the coredump during the application startup. In case I manage to diagnose this core somehow, I will mention it here. -- ( Marcin Kasperski | A complex system designed from scratch never works) ( http://www.mk.w.pl |and cannot be patched to make it work. (Booch) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
Re: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski [EMAIL PROTECTED] writes: The results are exactly the same: link succeeded, PL_perl_destruct_level is unresolved while running apache. I found the workaround to avoid this effect: slightly patching apache build procedure so that the httpd binary is linked with perl libperl.so helped. The error disappears... now I get the coredump during the application startup. In case I manage to diagnose this core somehow, I will mention it here. After recompiling perl, apache and modperl with debugging enabled I got the following backtrace. Does it reminds anything to anyone? I suspect something wrong in the fact, that perl_startup is called so late (during processing some PerlModule...) (Carp module mentioned there just happened to be the first PerlModule mentioned in my apache config) /apache-1.3.27, modperl-1.27/ Core file produced from executable 'httpd' Thread terminated at PC 0x3ffbff67de8 by signal SEGV (ladebug) where 0 0x3ffbff67de8 in S_new_he() hv.c:26 #1 0x3ffbff6b194 in Perl_share_hek(str=0x3feed70=@, len=1, hash=66) hv.c:1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70=@, klen=1, val=0x140048d80, hash=66) hv.c:413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70=@, klen=1, lval=1) hv.c:210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70=@, add=1, sv_type=4) gv.c:669 #5 0x3ffbfefe56c in S_init_main_stash() perl.c:2523 #6 0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) perl.c:951 #7 0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) perl.c:895 #8 0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) mod_perl.c:702 #9 0x30001817070 in perl_cmd_module(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260=Carp) perl_config.c:582 #10 0x12001cee8 in invoke_cmd(cmd=0x30041842828, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9daf=) http_config.c:918 #11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0=PerlModule Carp) http_config.c:1030 #12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) http_config.c:1044 #13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0=/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf, p=0x14001e818, ptemp=0x140338818) http_config.c:1332 #14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140338818, confname=0x1400112f0=/home/marcink/GAUSS/igoweb/src/tests/imf_efficiency/apache.conf) http_config.c:1616 #15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) http_main.c:5071 #16 0x120010ce8 in main(argc=4, argv=0x11fffc018) http_main.c:5456 #17 0x12000aad8 in __start(...) in /home/marcink/tools/apache/bin/httpd When I removed PerlModule directives and sticked only with PerlRequire, it occured that I must add 'use Apache;' on the beginning to use things like Apache-push_handlers (on normal installations it was not necessary, here I got ). And then I got similar coredump: Core file produced from executable 'httpd' Thread terminated at PC 0x3ffbff67de8 by signal SEGV (ladebug) where 0 0x3ffbff67de8 in S_new_he() hv.c:26 #1 0x3ffbff6b194 in Perl_share_hek(str=0x3feed70=@, len=1, hash=66) hv.c:1484 #2 0x3ffbff688c8 in Perl_hv_store(hv=0x140048cb0, key=0x3feed70=@, klen=1, val=0x140048d80, hash=66) hv.c:413 #3 0x3ffbff681f0 in Perl_hv_fetch(hv=0x140048cb0, key=0x3feed70=@, klen=1, lval=1) hv.c:210 #4 0x3ffbff03b7c in Perl_gv_fetchpv(nambeg=0x3feed70=@, add=1, sv_type=4) gv.c:669 #5 0x3ffbfefe56c in S_init_main_stash() perl.c:2523 #6 0x3ffbfef9c18 in S_parse_body(env=0x0, xsinit=0x3000180ecd8) perl.c:951 #7 0x3ffbfef9b0c in perl_parse(my_perl=0x140034040, xsinit=0x3000180ecd8, argc=3, argv=0x11fff9c48, env=0x0) perl.c:895 #8 0x3000180f58c in perl_startup(s=0x14001e860, p=0x14001e818) mod_perl.c:702 #9 0x30001817274 in perl_cmd_require(parms=0x11fffbe10, dummy=0x14001fdd8, arg=0x140020260=/home/marcink/src/tests/startup.pl) perl_config.c:613 #10 0x12001cee8 in invoke_cmd(cmd=0x30041842800, parms=0x11fffbe10, mconfig=0x14001fdd8, args=0x11fff9deb=) http_config.c:918 #11 0x12001d3ec in ap_handle_command(parms=0x11fffbe10, config=0x14001f250, l=0x11fff9da0=PerlRequire /home/marcink/src/tests/startup.pl) http_config.c:1030 #12 0x12001d4f8 in ap_srm_command_loop(parms=0x11fffbe10, config=0x14001f250) http_config.c:1044 #13 0x12001db48 in ap_process_resource_config(s=0x14001e860, fname=0x1400112f0=/home/marcink/src/tests/apache.conf, p=0x14001e818, ptemp=0x140235818) http_config.c:1332 #14 0x12001ea30 in ap_read_config(p=0x14001e818, ptemp=0x140235818, confname=0x1400112f0=/home/marcink/src/tests/efficiency/apache.conf) http_config.c:1616 #15 0x120010208 in standalone_main(argc=4, argv=0x11fffc018) http_main.c:5071 #16 0x120010ce8 in main(argc=4, argv=0x11fffc018) http_main.c:5456 #17 0x12000aad8 in __start(...) in /home/marcink/tools/apache/bin/httpd
DSO/Tru64 (was Re: References for modperl usage in financial institutions?)
PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this list. I am using Tru64 - and if you have any suggestions of what to try, I will do it...
Re: DSO/Tru64 (was Re: References for modperl usage in financialinstitutions?)
Marcin Kasperski wrote: PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this list. I am using Tru64 - and if you have any suggestions of what to try, I will do it... I wish it was that simple :( You really have to know the peculiarities of the system to know why the behavior is different. -- __ 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: [mp1] Still can not get working DSO configuration on Tru64
Stas Bekman [EMAIL PROTECTED] writes: Marcin Kasperski wrote: In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol PL_perl_destruct_level unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help). 2 years ago, there was a similar struggle as you can see from this thread: http://marc.theaimsgroup.com/?t=9744223061r=1w=2 May be those participants are still using True64 and can give you some hints? It seems to me, they had problem with the '-Wl,-rpath' issue which I found to be minor and easily patched (by the way: maybe someone would want to correct it in distribution?). And all they wanted was to get statically linked modperl. This is the thing I already have. Maybe I will post a question to tru64-managers... -- ( Marcin Kasperski | (...) the only completion criterion for the Analysis ) ( http://www.mk.w.pl | and Design phases is - the date. (Martin) ) () ( Nie gub zgosze bdw: http://www.mk.w.pl/narzedzia/narzedzia_bugewid)
Re: [mp1] Still can not get working DSO configuration on Tru64
In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol PL_perl_destruct_level unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help).
Re: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski wrote: In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol PL_perl_destruct_level unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help). 2 years ago, there was a similar struggle as you can see from this thread: http://marc.theaimsgroup.com/?t=9744223061r=1w=2 May be those participants are still using True64 and can give you some hints? __ 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: Static vs. DSO on Linux specifically
Sam Tregar No, the last Redhat Apache/mod_perl I used was in 6.2. I didn't file a Sam Tregar bug about it because after looking around it appeared that it was a well Sam Tregar known problem. After that I started compiling Apache/mod_perl static and Sam Tregar left the seg-faults behind. PMFJI :] Back in RH 6.2 I would hazard that the segfault was more related to Perl being set to uselargefiles and Apache NOT being set. This only became visible when one tried to build mod_perl as a DSO. Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. Cheers :) -Sx-
Re: Static vs. DSO on Linux specifically
On Tue, 23 Jul 2002, WC -Sx- Jones wrote: Back in RH 6.2 I would hazard that the segfault was more related to Perl being set to uselargefiles and Apache NOT being set. This only became visible when one tried to build mod_perl as a DSO. Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. I don't think so. Rebuilding Apache/mod_perl static with the exact same Perl that shipped with Redhat 6.2 solved the segfaults. Perhaps it is a problem in Perl, I wouldn't know, but I guarantee it wasn't a result of using a different Perl. -sam
Re: Static vs. DSO on Linux specifically
-Sx- said Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. Sam Tregar said I don't think so. Rebuilding Apache/mod_perl static with the exact same Perl that shipped with Redhat 6.2 solved the segfaults. :) How is this different from what I said? :) To better clarify - I said that IF you had tried to build the mod_perl as a DSO and the uselargefiles setting is NOT the same between Perl and Apache (IE - both are either uselargefiles or they are both undef) you WILL get a segfault -- even today. Building as STATIC causes the httpd to be completely rebuilt and the mod_perl settings will cause the Apache binary to match the Perl definition ofd use large files. Building mod_perl as static causes other issues as well - like causing Apache --with-layout to forget which layout it is supposed to use... Oh well; -Sx- :]
Static vs. DSO on Linux specifically
I've seen a lot of comments which seem to me to say that a static mod_perl is the only way to go. But Redhat ships it as a DSO. Now, on the one hand, I wouldn't just automatically assume that Redhat knew what they were doing. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). (And I know a static setup would use somewhat less memory; but the last memory I bought for this server cost me $16.04 per 128MB, and it's connected to the net over only a 768k DSL line, so I'm not running *hundreds* of server processes; more like *tens*.) What I've found on the web so far makes claims strong enough that I feel my experience contradicts them adequately, and makes few actual *explanations*. So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Static vs. DSO on Linux specifically
Hi!
On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote:
So, specifically for the Linux environment, what are the downsides of
running mod_perl as a DSO? (Pointers to the FM so I can R it would be
fine.)
Did you take a look at this:
http://perl.apache.org/docs/1.0/guide/install.html#Pros_and_Cons_of_Building_mod_perl_as_DSO
?
--
#!/usr/bin/perlhttp://domm.zsi.at
for(ref(bless[],just'another'perl'hacker)){s-:+-$-gprint$_.$/}
Re: Static vs. DSO on Linux specifically
On 22 Jul 2002, David Dyer-Bennet wrote: So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) Segmentation faults, pure and simple. The Apache/mod_perl that ships with Redhat, and I assume other DSO Apache/mod_perl setups, is unstable. Here's one place I've seen this mentioned: http://masonhq.com/docs/faq/#why_am_i_getting_segmentation_fa -sam
Re: Static vs. DSO on Linux specifically
Hi David, On 22 Jul 2002, David Dyer-Bennet wrote: But Redhat ships it as a DSO. Debian also, but I think that is only for simplicity. It would be 'expensive' to produce static versions of apache with mod_perl, or with mod_php or both. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). The reason for me was 'too many open file handles'. Every http daemon has a file handle for every DSO module, moreover a file handle for every log file. After sometime I started to have that error and found static building the best solution for my problem. IIRC, DSO is still marked as experimental in apache source. Last, but not least, conf files look better :) Ciao, Valerio Valerio Paolini, http://130.136.3.200/~paolini -- what is open-source about? Learn, and then give back
Re: Static vs. DSO on Linux specifically
On 22 Jul 2002 10:26:32 -0500, David Dyer-Bennet [EMAIL PROTECTED] said: DD I've seen a lot of comments which seem to me to say that a static DD mod_perl is the only way to go. I've been using mod_perl as DSO for more than one year (or even maybe two) without any problems on FreeBSD/Linux/Intel. My understanding is that there was some problems in the past and there are still some issues on some platforms but Linux/Intel platform is safe. DD But Redhat ships it as a DSO. DD Now, on the one hand, I wouldn't just automatically assume that Redhat DD knew what they were doing. I would not trust RedHat to much to do right thing with Perl. They are know to produce broken mod_perl packages in the past for example. DD [..snip..] -- Ilya Martynov (http://martynov.org/)
RE: Static vs. DSO on Linux specifically
Of course this is an old conversation, but we use mod_perl as a DSO here extensively with no problems. We have servers that have uptimes of almost 1 year (306 days as of today) and were taken down because the servers were moved to a new server room and not because of a problem with the DSO. And we get several thousand hits a day during the school year. It has been my experience that DSO vs. Static is not the issue it once was. Joe -Original Message- From: David Dyer-Bennet [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:27 AM To: [EMAIL PROTECTED] Subject: Static vs. DSO on Linux specifically I've seen a lot of comments which seem to me to say that a static mod_perl is the only way to go. But Redhat ships it as a DSO. Now, on the one hand, I wouldn't just automatically assume that Redhat knew what they were doing. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). (And I know a static setup would use somewhat less memory; but the last memory I bought for this server cost me $16.04 per 128MB, and it's connected to the net over only a 768k DSL line, so I'm not running *hundreds* of server processes; more like *tens*.) What I've found on the web so far makes claims strong enough that I feel my experience contradicts them adequately, and makes few actual *explanations*. So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Static vs. DSO on Linux specifically
Thomas Klausner [EMAIL PROTECTED] writes: Hi! On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote: So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) Did you take a look at this: http://perl.apache.org/docs/1.0/guide/install.html#Pros_and_Cons_of_Building_mod_perl_as_DSO ? Yes, and it seemed quite inconclusive, whereas some of the discussion I have heard from people makes it sound *important*. And the guide doesn't mention the two issues that people have mentioned on this list in response to my post (file handles and segfaults). -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
RE: Any known good configuration for mod_perl DSO?
In response to my question, Ged Haywood pointed me at a message from Chip Turner, reproduced here in part: 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. That should is a big big word, as I came across Mr Turner's message in a search of the list archives -- I'm currently working with a RedHat 7.2 box with all errata applied. All Perl-related RPMs were supplied by RedHat. And I get silent failure in the form of segmentation faults. So that's why I asked my original question. Can I expect that if we upgrade our web servers to RedHat 7.3, we'll be rid of the segfault problem? Or am I looking at rolling my own RPMs or installing from source RPMs? My suspicion, confirmed by Mr Turner, is that this is tied directly to shared libraries and toolchains, and so I suspect further that the problem will go away if I build everything from scratch using source RPMs. In the meanwhile, thanks to the people who have offered tips on building from source RPMs. Right now, it looks like this is the way we're going to go. And finally, thank you to the people who recommended (many in private messages) ditching RPMs altogether and installing from source, but unfortunately that's not an option, as I thought I had made clear in my initial post. One of the reasons we're using RPMs to handle configuration management is that we have several redundant servers in production and several servers for development use, and it's important that the configuration on each server be identical. It's also important that, if we add a new server to either group, we can produce an identical configuration to the development and production clusters. Charlton
Re: Any known good configuration for mod_perl DSO?
Wilbur, Charlton wrote: Or am I looking at rolling my own RPMs or installing from source RPMs? My suspicion, confirmed by Mr Turner, is that this is tied directly to shared libraries and toolchains, and so I suspect further that the problem will go away if I build everything from scratch using source RPMs. I highly recommend building your own RPMs. It works great, you get exactly what you want (and nothing you don't want), and you can install them quickly on a cluster of machines because you don't have to recompile on each one. - Perrin
Re: Any known good configuration for mod_perl DSO?
We built our own RPM that did source level builds on our entire system. So you load the rpm and it in turn executes a build script that built our entire system. Not just apache, modperl and mason but also it rebuilt all the modules that were needed, compiled external binaries, installed the Oracle libs and drivers and auto configured all configuration files based on the host it was on and a host-configuration mapping. Seemed to work well. John- On Mon, 24 Jun 2002 17:07:52 -0400 Wilbur, Charlton [EMAIL PROTECTED] wrote: Hello collective wisdom, I have the task of making Apache, mod_perl, and HTML::Mason work together under RedHat. I know this is a problem; the most frequently recommended solution that I've found is to build everything from scratch and link it all together, without using DSOs. However, my constraints are that all configuration management must be handled using RPMs, because we have a multitude of web servers that must all be maintained in parallel. My order of preference is for using downloadable binary RPMs, followed by using SRPMs and building from scratch, and finally followed by rolling my own RPMs. So I have a couple of questions that I'm currently researching, and if anybody here knows the answers, I'd be grateful to hear them: First, is there a known good binary RPM configuration, a combination of mod_perl and apache RPMs, from RedHat or another vendor that doesn't suffer from the silent-segfault problem? Second, is it possible that building from source RPMs would prevent the problem? Occasionally I've seen problems like this arise due to differing versions of the toolchain, and building from source RPMs would ensure that the same toolchain was used to build all of the components. If I find answers to these questions elsewhere before I receive answers from this list, I'll follow up to myself and share the wisdom. Thanks, Charlton -- Charlton Wilbur [EMAIL PROTECTED]
Re: Any known good configuration for mod_perl DSO?
Hi there,
On Mon, 24 Jun 2002, Wilbur, Charlton wrote:
I have the task of making Apache, mod_perl, and HTML::Mason work together
under RedHat. I know this is a problem;
Not necessarily; look at this thread for example...
73,
Ged.
--
From [EMAIL PROTECTED] Tue Jun 25 00:08:24 2002
Date: 22 Jun 2002 23:23:01 -0400
From: Chip Turner [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: Jeremy Weatherford [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: 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.
dso
Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? Arnold
Re: dso
At 11:41 29.05.2002, Arnold van Kampen wrote: Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? If you're having problems, it's often known to be the quick answer to try. If you're not having trouble, keep using DSO happily! -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: dso
I have to agree with this statement. We have a server farm with 15 apache servers running mod_perl as a DSO (not counting the several development and QC servers) with no problems. IMHO mod_perl as a DSO probably had problems in the beginning, but I couldn't confirm that without some research and I'm too lazy to do it, and as a result people now recommend compiling mod_perl into httpd. So I would say if DSO works for you use it, if not don't use it. -Original Message- From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 6:54 AM To: Arnold van Kampen Cc: [EMAIL PROTECTED] Subject: Re: dso At 11:41 29.05.2002, Arnold van Kampen wrote: Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? If you're having problems, it's often known to be the quick answer to try. If you're not having trouble, keep using DSO happily! -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: DSO on Solaris - child dies with seg fault
On Sun, 14 Apr 2002, Sreeji K Das wrote: Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. wondering if this is the XSLoader vs DynaLoader mentioned earlier today. there is a workaround builtin to 1.27-tobe: http://perl.apache.org/~dougm/mod_perl-1.26_01-dev.tar.gz you could also try 'use DynaLoader ();' before loading any other modules.
Re: DSO on Solaris - child dies with seg fault
Thanx Doug for the reply. Unfortunately I still get segfaults :-( No difference. Once I have the time, I'll get the stacktrace see for any clues. Right now I have kept DSO in the backburner, as I have got PerlFreshRestart fully up and runnig (with a no. of patches to mod_perl) Sreeji --- Doug MacEachern [EMAIL PROTECTED] wrote: you might actually be hitting a problem i just found on solaris with 2.0 and perl 5.6.1. a problem that is fixed in 5.8.0-tobe, where certain DynaLoader and XSLoader combo prevents modperl from closing all of the dlhandles. try adding this to your startup.pl before use-ing any other modules: use DynaLoader (); __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: DSO on Solaris - child dies with seg fault
you might actually be hitting a problem i just found on solaris with 2.0 and perl 5.6.1. a problem that is fixed in 5.8.0-tobe, where certain DynaLoader and XSLoader combo prevents modperl from closing all of the dlhandles. try adding this to your startup.pl before use-ing any other modules: use DynaLoader ();
Re: DSO on Solaris - child dies with seg fault
Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. I've attached some additional info., generated by trussing the child, as it was being restarted: $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 Note: I have also tried setting ENV PERL_DESTRUCT_LEVEL to -1 and also to 2, but got the same results. Thanx for any help. Sreeji --- Stas Bekman [EMAIL PROTECTED] wrote: Sreeji K Das wrote: Hi, I was trying to run mod_perl as DSO on Solaris. I see the following line in the logs: [notice] child pid 24323 exit signal Segmentation Fault (11) This happens whenever I send a USR1 to the server for restart. Also I see the same message whenever the child is about to exit (ie. after handling the prescribed no.of requests). Is DSO stable enough to be used under Solaris ? I have searched through the archives see differing opinions. Additional Info: $perl -V:uselargefiles -V:bincompat5005 uselargefiles='define'; bincompat5005='undef'; perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 Using SunOS 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-80 I've compiled mod_perl with PERL_USELARGEFILES=0 and USE_DSO. The above problem is repeatable with PerlFreshRestart On and Off. Any clues ? Thanx Sreeji (BTW, make test has gone through w/o any errors) See if it helps you:http://perl.apache.org/guide/install.html#When_DSO_can_be_Used __ 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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) (sleeping...) 26978: signotifywait() = 16 26978: Received signal #16, SIGUSR1, in accept() [caught] 26978:siginfo: SIGUSR1 pid=26322 uid=300528 26978: lwp_sigredirect(1, SIGUSR1) = 0 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) Err#4 EINTR 26978: sigprocmask(SIG_SETMASK, 0xEF276450, 0x) = 0 26978: setcontext(0xEFFFE5A8) 26978: sigaction(SIGHUP, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: sigaction(SIGUSR1, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: write(2, `, 1) = 1 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E8E3, 33)= 33 26978: ' p u s h _ h a n d l e r s ( ) s t a c k i s e m p t y 26978:\n 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E05A, 19)= 19 26978: h a n d l e r s r e t u r n e d 26978: write(2, - 1\n, 3) = 3 26978: write(2, r u n n i n g , 8) = 8 26978: write(2, 3, 1) = 1 26978: write(2, 0xEF51F95E, 16)= 16 26978: E N D b l o c k s f o r 26978: write(2, 0xEF547DCC, 13)= 13 26978: p e r l _ s h u t d o w n 26978: write(2, \n, 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0x00E90A80, 48)= 48 26978: T S T F o r m s s e r v e r p r o c e s s 2 6 9 7 8 s 26978: h u t t i n g d o w n . . .\n 26978: write(2, 0x013725C0, 40)= 40 26978: R e s e t t i n g c o n n e c t i o n t o d a t a b a s e 26978: @ s i g t e s t 26978: write(2, \n, 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0xEF51D770, 48)= 48 26978: d e s t r u c t i n g a n d f r e e i n g P e r l i n t 26978: e r p r e t e r ( l e v e l = 26978: write(2, 0, 1) = 1 26978: write(2, ) . . ., 4) = 4 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: write(2, o k\n, 3) = 3 26978: Incurred fault #6, FLTBOUNDS %pc = 0xEF1A3CFC 26978:siginfo: SIGSEGV SEGV_MAPERR addr=0xEF1A3CFC
Re: DSO on Solaris - child dies with seg fault
Sreeji K Das wrote: Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. Good then. I just wasn't sure. Hopefully someone with Solaris access/knowledge will be able to help you out, but see below. I've attached some additional info., generated by trussing the child, as it was being restarted: $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 What's needed is the core dump backtrace, see http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
DSO on Solaris - child dies with seg fault
Hi, I was trying to run mod_perl as DSO on Solaris. I see the following line in the logs: [notice] child pid 24323 exit signal Segmentation Fault (11) This happens whenever I send a USR1 to the server for restart. Also I see the same message whenever the child is about to exit (ie. after handling the prescribed no.of requests). Is DSO stable enough to be used under Solaris ? I have searched through the archives see differing opinions. Additional Info: $perl -V:uselargefiles -V:bincompat5005 uselargefiles='define'; bincompat5005='undef'; perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 Using SunOS 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-80 I've compiled mod_perl with PERL_USELARGEFILES=0 and USE_DSO. The above problem is repeatable with PerlFreshRestart On and Off. Any clues ? Thanx Sreeji (BTW, make test has gone through w/o any errors) __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: DSO on Solaris - child dies with seg fault
Sreeji K Das wrote: Hi, I was trying to run mod_perl as DSO on Solaris. I see the following line in the logs: [notice] child pid 24323 exit signal Segmentation Fault (11) This happens whenever I send a USR1 to the server for restart. Also I see the same message whenever the child is about to exit (ie. after handling the prescribed no.of requests). Is DSO stable enough to be used under Solaris ? I have searched through the archives see differing opinions. Additional Info: $perl -V:uselargefiles -V:bincompat5005 uselargefiles='define'; bincompat5005='undef'; perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 Using SunOS 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-80 I've compiled mod_perl with PERL_USELARGEFILES=0 and USE_DSO. The above problem is repeatable with PerlFreshRestart On and Off. Any clues ? Thanx Sreeji (BTW, make test has gone through w/o any errors) See if it helps you:http://perl.apache.org/guide/install.html#When_DSO_can_be_Used __ 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: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
upgrades for applications that maintain state - since a user might have a session created using a new-code box, then hit an old-code box on the next page view. it takes us many minutes to work through restarting the entire array. were you ever concerned about something like that? I only learned this yesterday by reading Perrin's eToys article, but their concept of sticky load balancing was interesting. They had a proxy server in front of the app servers. The proxy assigned session keys, and made sure that if you came back in on the same session you got assigned to the same app server. I thought that was a neat idea and would solve this particular problem. -Fran
PerlFreshRestart, mod_perl DSO, and Apache::StatINC
I'm looking at how to best avoid downtime during a code upgrade, as we often do spot releases of critical code fixes and we're getting to the usage level that I don't want to interrupt service to deploy that code. At the same time, I want to avoid running 200 stat()'s per request for all of the loaded modules. We're presently running in this configuration: Apache 1.3.22 static mod_perl 1.26 Apache::StatINC --Want to get rid of it. PerlFreshRestart OFF I see three options open to me: 1. static mod_perl w/ PerlFreshRestart Reloads %INC. downside: Heresay claims historical instablity. 2. dynamic mod_perl Tears down cleans up Perl interpreter on graceful restart. downside: Heresay claims historical instablity. 3. static mod_perl w/ Apache::StatInc Runs many stat()'s per request. downside: Runs many stat()'s per request. Aside from the historical instability, the second option strikes me as the cleanest and most robust. How has the current stability of these mechanisms? Is it enterprise-worthy? I'm variously running on RedHat Linux 7.0 and 7.1. -- Gordon Henriksen IT Engineering ICLUBcentral Inc. [EMAIL PROTECTED]
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
Gordon Henriksen wrote: I'm looking at how to best avoid downtime during a code upgrade, as we often do spot releases of critical code fixes and we're getting to the usage level that I don't want to interrupt service to deploy that code. At the same time, I want to avoid running 200 stat()'s per request for all of the loaded modules. look into the touchfile option in Apache::Reload - that might help some. --Geoff
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
Gordon Henriksen wrote: I see three options open to me: 1. static mod_perl w/ PerlFreshRestart Reloads %INC. downside: Heresay claims historical instablity. 2. dynamic mod_perl Tears down cleans up Perl interpreter on graceful restart. downside: Heresay claims historical instablity. 3. static mod_perl w/ Apache::StatInc Runs many stat()'s per request. downside: Runs many stat()'s per request. Frankly, those options all suck for anything other than development servers. A production server on a busy site needs to be fully stopped and restarted when you upgrade your code. Doing anything else is just asking for trouble (strange closure issues, for example) and will trash your shared memory to boot. The best way I've found to deal with this problem is to have multiple servers behind a load-balancer and do a rolling restart. If you have servers A and B, you take A out of the load balancer temporarilly, upgrade it, add it back in, take B out, upgrade it, add it back in. Using this technique, we were able to smoothly upgrade production servers on a very busy cluster of machines during normal business hours while customers were on the site. - Perrin
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
The best way I've found to deal with this problem is to have multiple servers behind a load-balancer and do a rolling restart. If you have servers A and B, you take A out of the load balancer temporarilly, upgrade it, add it back in, take B out, upgrade it, add it back in. Using this technique, we were able to smoothly upgrade production servers on a very busy cluster of machines during normal business hours while customers were on the site. we do that frequently here - 7 servers behind a BigIP. I've always wondered, though, whether this approach is foolproof for major upgrades for applications that maintain state - since a user might have a session created using a new-code box, then hit an old-code box on the next page view. it takes us many minutes to work through restarting the entire array. were you ever concerned about something like that? --Geoff
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
Geoffrey Young wrote: we do that frequently here - 7 servers behind a BigIP. I've always wondered, though, whether this approach is foolproof for major upgrades for applications that maintain state - since a user might have a session created using a new-code box, then hit an old-code box on the next page view. it takes us many minutes to work through restarting the entire array. were you ever concerned about something like that? We also used BigIP, with the sticky load-balancing option on. (Well, we used two, and only the application servers were sticky. It didn't matter which proxy/web server you went to.) This prevents the problem you're talking about. Of course if the upgrade involves changing some shared resource like a database as well, you have to take the site off-line while you do it. I suppose it's possible to rig up something crazy with multiple databases and synchronization, but it's just not worth it. - Perrin
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
We had been using Option 1 for a long time we had absolutely no problems (with mod_perl-1.19/Apache-1.3.14/Perl-5.005). However on upgrading to mod_perl-1.26, we were getting hell lot of errors. I have tracked this to a bug in perl_util.c on fixing this PerlFreshRestart works w/o any problems. I have posted this details 2/3 weeks back but haven't got any reply. I had to go for option 1, since I was not sure about DSO StatINC does stats() for every request that comes in - not too good. (even with a touchfile, it has to do stat() !) Sreeji --- Gordon Henriksen [EMAIL PROTECTED] wrote: I'm looking at how to best avoid downtime during a code upgrade, as we often do spot releases of critical code fixes and we're getting to the usage level that I don't want to interrupt service to deploy that code. At the same time, I want to avoid running 200 stat()'s per request for all of the loaded modules. We're presently running in this configuration: Apache 1.3.22 static mod_perl 1.26 Apache::StatINC --Want to get rid of it. PerlFreshRestart OFF I see three options open to me: 1. static mod_perl w/ PerlFreshRestart Reloads %INC. downside: Heresay claims historical instablity. 2. dynamic mod_perl Tears down cleans up Perl interpreter on graceful restart. downside: Heresay claims historical instablity. 3. static mod_perl w/ Apache::StatInc Runs many stat()'s per request. downside: Runs many stat()'s per request. Aside from the historical instability, the second option strikes me as the cleanest and most robust. How has the current stability of these mechanisms? Is it enterprise-worthy? I'm variously running on RedHat Linux 7.0 and 7.1. -- Gordon Henriksen IT Engineering ICLUBcentral Inc. [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: PerlFreshRestart, mod_perl DSO, and Apache::StatINC
We had been using Option 1 for a long time we had absolutely no problems But doesn't it totally wreck your shared memory? For me that would make it unusable. I usually get a pretty large percentage of memory to be shared and count on that for getting maximum capacity from each box. - Perrin
hvrv2table in mod_perl stops me using mod_php DSO
Hi, I'm trying to get the php module to work on Apache_1.3.22 under AIX 4.3.3. This works OK if I load mod_perl dynamically, but if I build mod_perl in statically, when httpd loads libphp4.so it gives a segmentation error. I've tried recompiling but that's made no difference. Everything was compiled using the Visual Age C compiler 5.0.2.0 (including my perl installation which is version 5.005_03). I've run a debug on it and it always seems to hit hvrv2table which appears to be a function in mod_perl. Unfortunately I can't tell from the debugger which line of code this is. Are there any known problems with this function? JS. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: DSO Issues
JC == John Chia [EMAIL PROTECTED] writes: JC On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. JC Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP JC it. Perl 5.005_03 has the leaks no matter what. And with DSO, PerlFreshStart is a no-op, since you get a fresh perl no matter what. One of these days I'll take the time to migrate to 5.6.1 and then regression test my whole app, which ain't easy to do on a web-based interactive system where you have hundreds of options to test in combination.
Re: DSO Issues
On Wed, Nov 28, 2001 at 10:34:00AM -0500, Vivek Khera wrote: SR == Stephen Reppucci [EMAIL PROTECTED] writes: SR If we're collecting a list of things that don't work in a DSO SR build, add perl subs (via !--#perl sub=My::handler--). SR At least, they didn't work as of January of this year. Doubtful that they ever will, either, since that introduces a dependency on mod_perl into mod_include. Both have to be linked together (ie, statically) for that to work. Not really, you can do it with just module DT_NEEDED depends. It does mean you have to build them together and load in the right order. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: DSO Issues
SR == Stephen Reppucci [EMAIL PROTECTED] writes: SR If we're collecting a list of things that don't work in a DSO SR build, add perl subs (via !--#perl sub=My::handler--). SR At least, they didn't work as of January of this year. Doubtful that they ever will, either, since that introduces a dependency on mod_perl into mod_include. Both have to be linked together (ie, statically) for that to work. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
DSO Issues
Hi All, While it seems to be well-known anecdotally that one should never use a DSO install of mod_perl (particularly among Mason developers), is there yet any place where all the known issues surrounding the use of DSO mod_perl are documented? I see a place in the guide where Stas mentions issues with mymalloc and such, but I also saw a post from a few months ago where he'd asked for someone with extensive experience with DSO installs to come forward and discuss the known issues. Did this ever come about? Thanks! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: DSO Issues
Ditto. DSO makes my life so much better in terms of portability and administratability that having my services down for a few seconds during a log rotation is certainly worth it. Regards, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vivek Khera Sent: Tuesday, November 27, 2001 2:17 PM To: [EMAIL PROTECTED] Subject: Re: DSO Issues DW == David Wheeler [EMAIL PROTECTED] writes: DW While it seems to be well-known anecdotally that one should never use a DW DSO install of mod_perl (particularly among Mason developers), is there DW yet any place where all the known issues surrounding the use of DSO The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. The amount of leakage depends on my particular application. Having a DSO makes it much easier for me to administer (having multiple instances of apache running on the same machine, some with and some without mod_perl), so I live with it and do a full stop/restart instead of SIGHUP to rotate logs. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: DSO Issues
On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- john chia [EMAIL PROTECTED] starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services products
Re: DSO Issues
DW == David Wheeler [EMAIL PROTECTED] writes: DW While it seems to be well-known anecdotally that one should never use a DW DSO install of mod_perl (particularly among Mason developers), is there DW yet any place where all the known issues surrounding the use of DSO The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. The amount of leakage depends on my particular application. Having a DSO makes it much easier for me to administer (having multiple instances of apache running on the same machine, some with and some without mod_perl), so I live with it and do a full stop/restart instead of SIGHUP to rotate logs. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: DSO Issues
If we're collecting a list of things that don't work in a DSO build, add perl subs (via !--#perl sub=My::handler--). At least, they didn't work as of January of this year. On Tue, 27 Nov 2001, John Chia wrote: On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
I noticed you list XML::Simple. It is a favorite module of mine, but it uses XML::Parser which uses the expat XML parser. It is seems that mod_perl has problems with XML::Parser. This problem is supposed to be fixed in Apache 1.3.22, but I still had problems with strange segfaults and munched scalers when using XML::Parser. I recommend switching XML parsers to one that doesn't use expat. I had good luck using XML::LibXML, especially after making a Simple API :) Matthew Gerlach John Chia wrote: Hi, I have a very annoying problem with mod_perl segfaulting. It must be some perl code, but I cannot isolate where. Here are the symptoms, all running on 7.2: 1) does not happen with apache/mod_perl compiled and linked on RedHat 6.2 2) does not happen with apache/mod_perl statically linked on Redhat 7.2 3) does happen with apache from 6.2 and mod_perl (re)linked on 7.2 I don't really want to go static, plus I'm a good guinea pig for this sort of thing! Stack traces... ** gdb 'where' after segfaulting: #0 __pthread_mutex_lock (mutex=0x67617765) at mutex.c:99 #1 0x401b0974 in __libc_free (mem=0x40515b18) at malloc.c:3152 #2 0x404bdb08 in Perl_sv_clear () from /usr/lib/apache/libperl.so #3 0x404bdd3f in Perl_sv_free () from /usr/lib/apache/libperl.so #4 0x404b7bf4 in S_visit () from /usr/lib/apache/libperl.so #5 0x404b7c87 in Perl_sv_clean_all () from /usr/lib/apache/libperl.so #6 0x4046f08e in perl_destruct () from /usr/lib/apache/libperl.so #7 0x4044ee2b in perl_shutdown () from /usr/lib/apache/libperl.so #8 0x4044f2a5 in mp_dso_unload () from /usr/lib/apache/libperl.so #9 0x080525f9 in ap_run_cleanup () at eval.c:41 #10 0x080510cb in ap_clear_pool () at eval.c:41 #11 0x08060220 in ap_child_terminate () at eval.c:41 #12 0x08060c03 in main () at eval.c:41 #13 0x40150306 in __libc_start_main (main=0x8060780 main, argc=2, ubp_av=0xbb54, init=0x804fb20 _init, fini=0x8089450 _fini, rtld_fini=0x4000d2cc _dl_fini, stack_end=0xbb4c) at ../sysdeps/generic/libc-start.c:129 ** strace is not at all helpful.. reads mime.types, opens access_log and does some rt_sigprocmask stuff then SIGSEGV. ** Interactive debugger via Apache::DB .. (sorry bout the mess) DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:349): 349:return unless defined DBI::trace_msg; # return unless bootstrap'd ok DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:350): 350:local ($!,$?); DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:351): 351:DBI-trace_msg(-- DBI::END\n, 2); DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:353): 353:$DBI::PERL_ENDING = $DBI::PERL_ENDING = 1; # avoid typo warning DBI::CODE(0x884e440)(/usr/lib/perl5/site_perl/5.6.1/i386-linux/DBI.pm:354): 354:DBI-disconnect_all() if %DBI::installed_drh; AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:449): 449:my $self = shift; AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:450): 450:my ($variable, $attrib); AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:454): 454:($variable = $AUTOLOAD) =~ s/.*:://; AppConfig::State::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig/State.pm:457): 457:$variable eq 'DESTROY' return; AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:206): 206:my $self = shift; AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:207): 207:my $method; AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:211): 211:($method = $AUTOLOAD) =~ s/.*:://; AppConfig::AUTOLOAD(/usr/lib/perl5/site_perl/5.6.1/AppConfig.pm:214): 214:$method eq 'DESTROY' return; Segmentation fault ** Semi-complete module list: perl-HTML-Table-1.12a-3mtl perl-Log-Agent-0.2.8-3mtl perl-MLDBM-2.00-7mtl perl-URI-1.17-5mtl perl-Storable-1.0.13-3mtl perl-Filesys-Statvfs_Df-0.67-4mtl perl-Proc-ProcessTable-0.33-4mtl perl-IO-Interface-0.97-6mtl perl-DBD-Pg-1.01-5mtl perl-libnet-1.0704-8mtl perl-Apache-GTopLimit-0.01-3mtl perl-Crypt-SSLeay-0.31-5mtl perl-Net-IMAP-Simple-0.93-4mtl perl-App-Config-1.09-5mtl perl-FreezeThaw-0.41-6mtl perl-GTop-0.10-4mtl perl-POE-0.17-4mtl perl-Authen-Smb-0.91-3mtl perl-Convert-ASN1-0.07-1 perl-IMAP-Admin-1.5.1-3mtl perl-Net-SNMP-3.5-1 perl-HTML-Mason-1.04-6mtl perl-GDGraph-1.33-6mtl perl-XML-Writer-0.4-0 perl-Time-HiRes-01.20-7mtl perl-Archive-Tar-0.22-6mtl perl-XML-Parser-2.30-7 perl-Adaptor-0.2-1 perl-GD-1.33-9mtl perl-Apache-DB-0.06-1mtl perl-ldap-0.25-5mtl perl-Params-Validate-0.07-4mtl perl-GDTextUtil-0.80-6mtl perl-HTML-Parser-3.25-5mtl perl-Net-DNS-0.12-6mtl perl-Net-Printer-0.20-1 perl-MIME-Base64-2.12-7mtl perl-Net-Finger-1.05-5mtl perl-MLM-0.1-1 perl-Sys-CpuLoad-0.01-7mtl perl-Digest-MD5-2.13-1
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
Hi. On 24 November 2001 12:35 (+0800), Stas Bekman wrote: Check this out: http://perl.apache.org/guide/install.html#When_DSO_can_be_Used Nope. Still segfaulting. Same place. yes, the output of perl -V, the args used to build mod_perl (grab the src.rpm, rpm -i and look at the spec file. But first see if the above URL solves your problem. ** perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.7-10, archname=i386-linux uname='linux europa.starnix.com 2.4.7-10 #1 thu sep 6 17:27:27 edt 2001 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles -Ubincompat5005' 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.1 2.96-98)', 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.4.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 Nov 25 2001 12:57:07 @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/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 /usr/lib/perl5/site_perl . ** mod_perl build: ** RPM_OPT_FLAGS=-O2 -march=i386 -mcpu=i686 CFLAGS=$RPM_OPT_FLAGS \ perl Makefile.PL USE_APXS=1 \ WITH_APXS=/usr/sbin/apxs \ EVERYTHING=1 \ CCFLAGS=$RPM_OPT_FLAGS -fPIC make ** usemymalloc/bincompat [root@h241 RPMS]# perl -V:usemymalloc usemymalloc='n'; [root@h241 RPMS]# perl -V:bincompat5005 bincompat5005='undef'; ** i386 modules perl-Array-RefElem-0.02-13mtl.i386.rpm perl-Authen-Smb-0.91-7mtl.i386.rpm perl-Compress-Zlib-1.14-9mtl.i386.rpm perl-Crypt-SSLeay-0.31-8mtl.i386.rpm perl-DBI-1.20-8mtl.i386.rpm perl-Filesys-Statvfs_Df-0.67-7mtl.i386.rpm perl-Filter-1.25-5mtl.i386.rpm perl-GD-1.33-11mtl.i386.rpm perl-GTop-0.10-6mtl.i386.rpm perl-HTML-Parser-3.25-8mtl.i386.rpm perl-IO-Interface-0.97-8mtl.i386.rpm perl-libapreq-0.33-13mtl.i386.rpm perl-MIME-Base64-2.12-9mtl.i386.rpm perl-Newt-1.08-6mtl.i386.rpm perl-Storable-1.0.13-5mtl.i386.rpm perl-Time-HiRes-01.20-9mtl.i386.rpm Thanks! -- john chia [EMAIL PROTECTED] starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services products
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
Hi there, On Mon, 26 Nov 2001, John Chia wrote: Still segfaulting. Same place. [snip] Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: [snip] Compiler: [snip] gccversion='2.96 2731 (Red Hat Linux 7.12.96-98)', Did you compile Perl yourself? 73, Ged.
Re: mod_perl segfaulting (Redhat 7.2, DSO, Apache 1.3.20)
On 26 November 2001 23:41 (+), Ged Haywood wrote: Did you compile Perl yourself? Yep. -- john chia [EMAIL PROTECTED] starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services products
Re: Proble by Build mod_perl as a DSO outside the Apache Source Treevia APXS
On Fri, 9 Nov 2001, SubbaReddy M wrote: Hello Gurus, please help me to get update for mod_perl. [...] PLEASE -don't- post any HTML mails on the list. We are humans here, not browsers.
Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
Sorry, my intention is to express the problem area. so that, expect the exact solution. Please, if you have solution, kindly respond or put on known one. I am eagrly, waiting for solution. Thank you, -SubbaReddy - Original Message - From: Mohit Agarwal [EMAIL PROTECTED] To: SubbaReddy M [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, November 09, 2001 12:21 AM Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS On Fri, 9 Nov 2001, SubbaReddy M wrote: Hello Gurus, please help me to get update for mod_perl. [...] PLEASE -don't- post any HTML mails on the list. We are humans here, not browsers. ---BeginMessage--- Hello Gurus, please help me to get update for mod_perl. I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and To extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_outside_ But, unable to access the apache httpd from browser ( http://192.168.1.235/ ). i.e., Build mod_perl as a DSO outside the Apache Source Tree via APXS This will build the DSO libperl.so outside the Apache source tree with the new Apache 1.3 support tool apxs and install it into the existing Apache hierarchy. When I checked log file of the httpd, seems something ERROR [root@qclinux /root]# tail /etc/log/httpd/error_log Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.26 configured -- resuming normal operations configured -- resuming normal operations Size magic not implemented. When I tried from browser not any page and checked log file [root@qclinux /root]# tail /var/log/httpd/error_log [Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation fault (11) [Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 860 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 859 exit signal Segmentation fault (11) Please, kindly give me suggestion to get on work mod_perl with existing Apache. because, it has some many loaded module. I am facing so many problem to get work with new apache + mod_perl. So I want to continue with existing Apache and new mod_perl environment. Thanks in advance. -SubbaReddy M ---End Message---
Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
When I tried from browser not any page and checked log file [root@qclinux /root]# tail /var/log/httpd/error_log [Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation fault (11) [Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 860 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 859 exit signal Segmentation fault (11) Please, kindly give me suggestion to get on work mod_perl with existing Apache. because, it has some many loaded module. I am facing so many problem to get work with new apache + mod_perl. Since you have a segfault, we cannot help you until you send us the backtrace. See the SUPPORT file in your source distro which explains how to do that. _ 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/
Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
SubbaReddy M wrote: How can I get backtrace info to send you? If you want to solve your problem at least read the replies thoroughly and you will be all set. Here it is again. And DO NOT reply to me, but to the list. Since you have a segfault, we cannot help you until you send us the backtrace. See the SUPPORT file in your source distro which explains how to do that. _ 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/
Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
Oh, thank you very much hamptone, I am really waitinting for replies. This is type encouragement is require for new bies. thank you and let you know the progress. -SubbaReddy But, - Original Message - From: hamptone [EMAIL PROTECTED] To: SubbaReddy M [EMAIL PROTECTED] Sent: Friday, November 09, 2001 3:03 AM Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS Try my tips for doing this at: www.hamptonandassociates.net/apache_tips.htm Good luck. - Original Message - From: SubbaReddy M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 09, 2001 4:02 PM Subject: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS Hello Gurus, please help me to get update for mod_perl. I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and To extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_outside_ But, unable to access the apache httpd from browser ( http://192.168.1.235/ ). i.e., Build mod_perl as a DSO outside the Apache Source Tree via APXS This will build the DSO libperl.so outside the Apache source tree with the new Apache 1.3 support tool apxs and install it into the existing Apache hierarchy. When I checked log file of the httpd, seems something ERROR [root@qclinux /root]# tail /etc/log/httpd/error_log Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.26 configured -- resuming normal operations configured -- resuming normal operations Size magic not implemented. When I tried from browser not any page and checked log file [root@qclinux /root]# tail /var/log/httpd/error_log [Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation fault (11) [Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 860 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 859 exit signal Segmentation fault (11) Please, kindly give me suggestion to get on work mod_perl with existing Apache. because, it has some many loaded module. I am facing so many problem to get work with new apache + mod_perl. So I want to continue with existing Apache and new mod_perl environment. Thanks in advance. -SubbaReddy M
with backtrace Fw: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
[root@qclinux mod_perl-1.26]# perl Makefile.PL PERL_DEBUG=1 EVERYTHING=1 DEBUG mode... ...adding `-g' to EXTRA_CFLAGS ...turning on PERL_TRACE ...setting PERL_DESTRUCT_LEVEL=2 Configure mod_perl with ../apache_1.3.22/src ? [y] Shall I build httpd in ../apache_1.3.22/src for you? [y] Appending mod_perl to src/Configuration Using config file: /soft/Apache-ASP-2.27/make_httpd/mod_perl-1.26/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + using system Expat + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in modules/standard Creating Makefile in modules/perl EXTRA_CFLAGS: -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -I/u sr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -D NO_DL_NEEDED PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'root' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl Thanks inadvance -SubbaReddy - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: SubbaReddy M [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Friday, November 09, 2001 2:02 AM Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS SubbaReddy M wrote: How can I get backtrace info to send you? If you want to solve your problem at least read the replies thoroughly and you will be all set. Here it is again. And DO NOT reply to me, but to the list. Since you have a segfault, we cannot help you until you send us the backtrace. See the SUPPORT file in your source distro which explains how to do that. _ 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/
Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
Hello Gurus, please help me to get update for mod_perl. I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and To extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_outside_ But, unable to access the apache httpd from browser ( http://192.168.1.235/ ). i.e., Build mod_perl as a DSO outside the Apache Source Tree via APXS This will build the DSO libperl.so outside the Apache source tree with the new Apache 1.3 support tool apxs and install it into the existing Apache hierarchy. When I checked log file of the httpd, seems something ERROR [root@qclinux /root]# tail /etc/log/httpd/error_log Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.26 configured -- resuming normal operationsconfigured -- resuming normal operationsSize magic not implemented. When I tried from browser not any page and checked log file [root@qclinux /root]# tail /var/log/httpd/error_log[Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation fault (11)[Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation fault (11)[Fri Nov 9 07:16:45 2001] [notice] child pid 860 exit signal Segmentation fault (11)[Fri Nov 9 07:16:45 2001] [notice] child pid 859 exit signal Segmentation fault (11) Please, kindly give me suggestion to get on work mod_perl with existing Apache. because, it has some many loaded module. I am facing so many problem to get work with new apache + mod_perl. So I want to continue with existing Apache and new mod_perl environment. Thanks in advance. -SubbaReddy M
Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS
Hello Gurus, please help me to get update for mod_perl. I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and To extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/install.html#Build_mod_perl_as_a_DSO_outside_ But, unable to access the apache httpd from browser ( http://192.168.1.235/ ). i.e., Build mod_perl as a DSO outside the Apache Source Tree via APXS This will build the DSO libperl.so outside the Apache source tree with the new Apache 1.3 support tool apxs and install it into the existing Apache hierarchy. When I checked log file of the httpd, seems something ERROR [root@qclinux /root]# tail /etc/log/httpd/error_log Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.26 configured -- resuming normal operations configured -- resuming normal operations Size magic not implemented. When I tried from browser not any page and checked log file [root@qclinux /root]# tail /var/log/httpd/error_log [Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation fault (11) [Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 860 exit signal Segmentation fault (11) [Fri Nov 9 07:16:45 2001] [notice] child pid 859 exit signal Segmentation fault (11) Please, kindly give me suggestion to get on work mod_perl with existing Apache. because, it has some many loaded module. I am facing so many problem to get work with new apache + mod_perl. So I want to continue with existing Apache and new mod_perl environment. Thanks in advance. -SubbaReddy M
modperl as DSO
Hi, I emailed the list a few days ago with some troubles i had with Apache::AuthenSMB. Turns out It didn't work because I did not have mod_perl correctly installed Now for my question, I recompiled mod_perl in apache (no DSO) and then it worked; problem is I really want it as a DSO and tried that again using: perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs EVERYTHING=1 (may be wrapped) As far as I know this is the correct way to install it as a DSO, but nevertheless after installing it, Apache::AuthenSMB didn't work any more. Although mod_info says modperl is correctly installed and loaded. What could be the problem? Thanks, Jeroen
Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, some weeks ago here was the discussion about DSO-mod_perl and leaking; as far as I understand it the solution was, that on SOME platforms (solaris) mod_perl should be build as static. It seems that FreeBSD is such a platform ;-) I build Apache from the Ports-Collection with mod-ssl -- /usr/ports/www/apache13-modssl -- (with 1.3.20 and 1.3.22) and manually Perl 5.6.1 (NO mymalloc, no compatibility, with mymalloc also tested) and mod_perl 1.26 as DSO with APXS. My mod_perl-Application has a global and resident hash, about 18 MB, which is build in the startup-script. At normal startup, it seems that mod_perl requires TWICE the amount of this hash, and each restart (also graceful) it eats ~18 MB. 1 GB is fast full ;-) The mod_perl from Ports Collection is build also as DSO and has the same problem (with old Perl replaced by 5.6.1). Has someone mod_perl on FreeBSD WITH DSO and without leaking running? If not possible it might be good to include a warning in the Makefiles or mod_perl-Guide etc. I prefer to build Apache from the Ports collection, so at next I'll try to create a Port with static mod_perl ... Ciao Alvar PS: #perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=freebsd, osvers=4.4-stable, archname=i386-freebsd uname='freebsd gnarzelwicht.delirium-arts.de 4.4-stable freebsd 4.4-stable #8: sat oct 6 13:55:41 cest 2001 [EMAIL PROTECTED]:usrobjusrsrcsysmykernel2 i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O3 -march=k6 -funroll-loops -fexpensive-optimizations -malign-double', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', 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=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -ldb -lm -lc -lcrypt -liconv -lutil perllibs=-lm -lc -lcrypt -liconv -lutil libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under freebsd Compiled at Oct 23 2001 17:37:29 @INC: /usr/lib/perl5/5.6.1/i386-freebsd /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-freebsd /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, It would be interesting to hear whether you have the same results with the stock Perl version distributed with FreeBSD (built without PERL_THREADED defined, since that experimental stuff was removed from FreeBSD with good reason). with perl 5.6.1 and my Perl isn't threaded :) That's what the p5-apache port did. I added the mod_perl port _specifically_ to make mod_perl available to FreeBSD admins dynamically. but it's build as DSO and I guess this makes the troubles. i prefer DSO and ports too, but i guess that DSO is the problem. Also the standard perl of FreeBSD is 5.005 -- which is really leaking memory and not up to date ;=) so i want to use 5.6.1 -- on my test machine i replaced it with 5.6.1, on production server i installed a second perl because it seems that it was not the best idea to replace the standard perl version ... Ciao Alvar
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, It kinda feels like you didn't absorb any of the contents of my reply. :-) ehm, ups sorry -- perhaps i misunderstand you ;) (oh yes, my english is bad :( ) Let me try a different approach. What do you want me to do? it was mainly a message to the mod_perl mailinglist, CC to you because you maintain the ports and maybe heard about the problem. about two months ago in the list there was a discussion about building mod_perl as DSO and the result was, that on some platforms it leaks memory if build as DSO. Ciao Alvar
DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alan Burlison wrote: Stas Bekman wrote: No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? So what is the point of having DSO at all then? The question was 'How do I build on Solaris with DSO?', the answer was 'Build perl to use the system malloc', I don't see what the problem with that is. You are right, it was my mistake. I read the solution to the problem was not to build it as DSO. (mail overload problem :( ) I'll add this note regarding Solaris. I think the best thing would be if somebody who has an extensive DSO build experience across many platforms could summarize the problems, so we can put it into the guide. Personally I always build my production servers as static, so I only rely on comments from others. Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc * My server leaks memory on restart with DSO = don't use DSO _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Stas Bekman wrote: Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; which can be turned off with: % Configure -Ubincompat5005 ... * My server leaks memory on restart with DSO = don't use DSO shouldn't happen with 5.6.1, at least it doesn't with my testing.
Re: DSO problems summary? (was Re: Children dying)
On Thu, Aug 16, 2001 at 09:35:43AM -0700, Doug MacEachern wrote: that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; Well... With # perl -v This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; # perl -V:bincompat5005 bincompat5005='define'; on # uname -a SunOS netra 5.8 Generic_108528-09 sun4u sparc SUNW,UltraAX-i2 am I safe? Or what should I rebuild with what flags? Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. Alex.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alex Povolotsky wrote: This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; that's fine. Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. how did you build modperl? if USE_APXS=1 you may have missed this other warning: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) the first option is the easiest cure.
DSO suexecx mod_perl
Hello, OK, but I can I govern this: in the apache configuration of ./configure I tried to add some DSO (Dynamical Shared Objects) like this ./configure --enable-module=most --enable-shared=max --enable-suexec --suexe c-caller=apache --suexec-docroot=/home --suexec-userdir=/home --suexec-uidmi n=500 --suexec-gidmin=100 --suexec-safepath=/usr/local/bin:/usr/bin:/bin --a ctivate-module=src/modules/perl/libperl.a --enable-shared=perl - after running make and then make install I tried to restart httpd it failed. My Question: What can I do to have most of the DSO object modules for apache and mod_perl running as suExec. Oli -- sure... they don't conflict, but you also can't use them at the same time... module effectively means internal to apache, and exec effectively means external ... so you can have mod_cgi call external programs using suexec, or mod_perl handle perl scripts internally to apache ... but they don't combine --- hello list, I tried to configure my new apache (with APACI) like this: ./configure --prefix=/usr/local/apache --activate-module=src/modules/perl/li bperl.a --enable-shared=perl --enable-suexec --suexec-caller=apache --suexec -docroot=/home --suexec-userdir=/home --suexec-uidmin=500 --suexec-gidmi n= 100 --suexec-logfile=/usr/local/apache/logs/suexec_log --suexec-safepath=/us r/local/bin:/usr/bin:/bin My question: Is there any possibility to run Apache with suexec and mod_perl ?
Re: DSO suexecx mod_perl
Oliver [EMAIL PROTECTED] wrote: Hello, OK, but I can I govern this: in the apache configuration of ./configure I tried to add some DSO (Dynamical Shared Objects) like this ./configure --enable-module=most --enable-shared=max --enable-suexec --suexe c-caller=apache --suexec-docroot=/home --suexec-userdir=/home --suexec-uidmi n=500 --suexec-gidmin=100 --suexec-safepath=/usr/local/bin:/usr/bin:/bin --a ctivate-module=src/modules/perl/libperl.a --enable-shared=perl - after running make and then make install I tried to restart httpd it failed. My Question: What can I do to have most of the DSO object modules for apache and mod_perl running as suExec. You can't. suExec is used to run other programs. DSOs are not programs but shared libraries. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
RE: Solaris mod_perl DSO...
On 22 Jun 2001, Jay Thorne wrote: Hmm. I've tried this on perl 5.5.x and 1.25 on a linux box, and I still get the 4meg leak per HUP hi, for the nth time, 5.005 leaks, 5.6.1 does not.
RE: Solaris mod_perl DSO...
On 21 Jun 2001 19:34:03 -0700, Doug MacEachern wrote: On Thu, 21 Jun 2001, Paul G. Weiss wrote: I've done it with 5.6.1. There was a fairly detailed thread on it last week on how it was done. In order to avoid a memory leak on restart you need to build with a bleed modperl though. If you can start and stop your server you're fine with 1.25. as you pointed out before, you can configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2 without installing cvs modperl. Hmm. I've tried this on perl 5.5.x and 1.25 on a linux box, and I still get the 4meg leak per HUP -- -- Jay Thorne Manager, Systems Technology, UserFriendly Media, Inc.
Solaris mod_perl DSO...
Has anyone had any luck getting mod_perl to work as a DSO on Solaris? In looking through the sources, it looks like my only option is to upgrade to bleed perl. If that really is the only thing I can do, can someone quickly second my thoughts before I go and subject myself to a little piece of something other than heaven? Thanks. -sc -- Sean Chittenden PGP signature
RE: Solaris mod_perl DSO...
I've done it with 5.6.1. There was a fairly detailed thread on it last week on how it was done. In order to avoid a memory leak on restart you need to build with a bleed modperl though. If you can start and stop your server you're fine with 1.25. -Original Message- From: Sean Chittenden [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 7:32 PM To: [EMAIL PROTECTED] Subject: Solaris mod_perl DSO... Has anyone had any luck getting mod_perl to work as a DSO on Solaris? In looking through the sources, it looks like my only option is to upgrade to bleed perl. If that really is the only thing I can do, can someone quickly second my thoughts before I go and subject myself to a little piece of something other than heaven? Thanks. -sc -- Sean Chittenden
RE: Solaris mod_perl DSO...
On Thu, 21 Jun 2001, Paul G. Weiss wrote: I've done it with 5.6.1. There was a fairly detailed thread on it last week on how it was done. In order to avoid a memory leak on restart you need to build with a bleed modperl though. If you can start and stop your server you're fine with 1.25. as you pointed out before, you can configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2 without installing cvs modperl.
RE: Confusion resolved (was: mod_perl DSO leaking on restart)
Doug,
Will this patch make it into 1.26? If so, is there a slated release date
for 1.26?
Thanks,
Christian
-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 9:04 PM
To: Paul G. Weiss
Cc: mod_perl list
Subject: Re: Confusion resolved (was: mod_perl DSO leaking on restart)
ah ha, right, since i always have PERL_DEBUG=1, perl_destruct_level is
always set to 2. good find! it should always be 2 for dso,
this patch
seems to fix USE_APXS too.
--- src/modules/perl/mod_perl.c 2001/06/14 04:49:08 1.137
+++ src/modules/perl/mod_perl.c 2001/06/19 01:59:18
@@ -259,8 +259,6 @@
if((pdl = getenv(PERL_DESTRUCT_LEVEL)))
perl_destruct_level = atoi(pdl);
-else
- perl_destruct_level = PERL_DESTRUCT_LEVEL;
if(perl_destruct_level 0) {
MP_TRACE_g(fprintf(stderr,
@@ -510,6 +508,7 @@
array_header *librefs;
librefs = xs_dl_librefs((pool *)data);
+perl_destruct_level = 2;
perl_shutdown(NULL, NULL);
unload_xs_so(librefs);
}
Re: Confusion resolved (was: mod_perl DSO leaking on restart)
DM == Doug MacEachern [EMAIL PROTECTED] writes: DM On 19 Jun 2001, Vivek Khera wrote: Drat. Not here. I just sucked down the latest mod_perl CVS with this patch, and I still lose 9M per USR1... Lemme try some tracing to see what gives here. (FreeBSD 4.3, perl 5.005_03) DM i mentioned earlier in the thread 5.005_03 has leaks. although, with the DM t/ config (make start_httpd_fork), i see ~140k of leakage per USR1, Right. Apparently the size of Volvo semi-trucks. I guess I'll just not USR1 the back-end ;-)
RE: Confusion resolved (was: mod_perl DSO leaking on restart)
On Tue, 19 Jun 2001, Christian Gilmore wrote: Doug, Will this patch make it into 1.26? yes. If so, is there a slated release date for 1.26? soon-ish. you can always configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2 in the meantime.
Re: Confusion resolved (was: mod_perl DSO leaking on restart)
On 19 Jun 2001, Vivek Khera wrote: Drat. Not here. I just sucked down the latest mod_perl CVS with this patch, and I still lose 9M per USR1... Lemme try some tracing to see what gives here. (FreeBSD 4.3, perl 5.005_03) i mentioned earlier in the thread 5.005_03 has leaks. although, with the t/ config (make start_httpd_fork), i see ~140k of leakage per USR1, compared to 9M is a surprise, but i suppose the 5.005_03 leakage depends on what you have loaded.
Confusion resolved (was: mod_perl DSO leaking on restart)
I think I've found the error of my ways. The reason that it was leaking with a static build was that the PerlFreshRestart directive was set to 'On'. This resulted in a leak of a couple of Mb. The reason that it was leaking with a USE_DSO build was that I didn't set PERL_DESTRUCT_LEVEL. Once I added PerlSetEnv PERL_DESTRUCT_LEVEL 2 the leak stopped. Actually I get the behavior Doug reported: a small leak of around 24K on the first restart and none thereafter. Actually in order to achieve this I had to comment out the load of example_module. That module leaks about 56K when restarted as a dso. I've not been able to avoid a leak with a USE_APXS build. -Paul On Sun, 17 Jun 2001, Paul G. Weiss wrote: Now I'm really confused. I built the whole thing statically and it still leaks: the static build (using the same Perl): ~/test/prefix/bin/perl Makefile.PL EVERYTHING=1 \ APACHE_PREFIX=$(echo ~/test/prefix/apache) \ APACHE_SRC=../apache_1.3.19 DO_HTTPD=1 Now it still leaks 520K per restart: make start_httpd_fork ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 7856 httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 8488 httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o pid,vsz,comm -p $(cat t/logs/httpd.pid ) PID VSZ COMMAND 4877 9108 httpd This is on Redhat 7.1 (not Linux 7.1 as I said below). I didn't bother trying it on Solaris. You don't suppose building with APACHE_PREFIX could have anything to do with it, do you? I haven't heard of any leaks with a static build. -P On Sun, 17 Jun 2001, Paul G. Weiss wrote: Doug, I'm confused as to how you managed to *not* leak when I'm still leaking. I've tried these tests on both a Solaris 2.7 system and a Linux 7.1. Here is a summary of what I do: I build Perl ./Configure -des -Uusemymalloc -Dprefix=$(echo ~/test/prefix) -Dcc=gcc make make test make install I build Apache ~/test/prefix/bin/perl Makefile.PL USE_DSO=1 EVERYTHING=1 \ USE_APACI=1 APACHE_PREFIX=$(echo ~/test/prefix/apache) \ APACHE_SRC=../apache_1.3.19 \ APACI_ARGS='--enable-module=all --enable-shared=max' \ DO_HTTPD=1 make make test I now run the test: make start_httpd_fork ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) etc. The virtual size grows each time, although by different amounts in Linux and Solaris. Both are around 4Mb. So what are you doing differently? Let me know so I can do the same thing. The Perl I'm using is 5.6.1 and the modperl is modperl_20010614113010.tar.gz. -P On Fri, 15 Jun 2001, Paul G. Weiss wrote: Don't be so willing to bet. Still leaking. I did as you said and just rebuilt Perl and mod_perl but didn't bother to rebuild all the Perl modules (I would have done so had I been successful here). Here's what I see: make start_httpd_fork ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 15528 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 20016 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 24544 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 27224 ../apache_1.3.19/src/httpd make kill_httpd kill `cat t/logs/httpd.pid` rm -f t/logs/httpd.pid rm -f t/logs/error_log On Thu, 14 Jun 2001, Doug MacEachern wrote: On Fri, 15 Jun 2001, Paul G. Weiss wrote: alignbytes=8, usemymalloc=y, prototype=define ^ ok, here's why i kept asking for perl -V. i don't see Perl's malloc.c ever release its memory pool. when usemymalloc=y, free() only puts memory back into Perl's pool for use by other malloc()'s. i don't see a function to destroy this pool when perl cleans itself up. willing to bet if you rebuild Perl with: Configure -des -Uusemymalloc ... and then rebuild mod_perl, the leaks will go away.
Re: Confusion resolved (was: mod_perl DSO leaking on restart)
ah ha, right, since i always have PERL_DEBUG=1, perl_destruct_level is
always set to 2. good find! it should always be 2 for dso, this patch
seems to fix USE_APXS too.
--- src/modules/perl/mod_perl.c 2001/06/14 04:49:08 1.137
+++ src/modules/perl/mod_perl.c 2001/06/19 01:59:18
@@ -259,8 +259,6 @@
if((pdl = getenv(PERL_DESTRUCT_LEVEL)))
perl_destruct_level = atoi(pdl);
-else
- perl_destruct_level = PERL_DESTRUCT_LEVEL;
if(perl_destruct_level 0) {
MP_TRACE_g(fprintf(stderr,
@@ -510,6 +508,7 @@
array_header *librefs;
librefs = xs_dl_librefs((pool *)data);
+perl_destruct_level = 2;
perl_shutdown(NULL, NULL);
unload_xs_so(librefs);
}
Re: mod_perl DSO leaking on restart?
Doug, I'm confused as to how you managed to *not* leak when I'm still leaking. I've tried these tests on both a Solaris 2.7 system and a Linux 7.1. Here is a summary of what I do: I build Perl ./Configure -des -Uusemymalloc -Dprefix=$(echo ~/test/prefix) -Dcc=gcc make make test make install I build Apache ~/test/prefix/bin/perl Makefile.PL USE_DSO=1 EVERYTHING=1 \ USE_APACI=1 APACHE_PREFIX=$(echo ~/test/prefix/apache) \ APACHE_SRC=../apache_1.3.19 \ APACI_ARGS='--enable-module=all --enable-shared=max' \ DO_HTTPD=1 make make test I now run the test: make start_httpd_fork ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,vsz,comm' -p $(cat t/logs/httpd.pid ) kill -USR1 $(cat t/logs/httpd.pid ) etc. The virtual size grows each time, although by different amounts in Linux and Solaris. Both are around 4Mb. So what are you doing differently? Let me know so I can do the same thing. The Perl I'm using is 5.6.1 and the modperl is modperl_20010614113010.tar.gz. -P On Fri, 15 Jun 2001, Paul G. Weiss wrote: Don't be so willing to bet. Still leaking. I did as you said and just rebuilt Perl and mod_perl but didn't bother to rebuild all the Perl modules (I would have done so had I been successful here). Here's what I see: make start_httpd_fork ../apache_1.3.19/src/httpd -f `pwd`/t/conf/httpd.conf -d `pwd`/t ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 15528 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 20016 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 24544 ../apache_1.3.19/src/httpd kill -USR1 $(cat t/logs/httpd.pid ) ps -o 'pid,ppid,vsz,comm' -p $(cat t/logs/httpd.pid ) PID PPID VSZ COMMAND 28802 1 27224 ../apache_1.3.19/src/httpd make kill_httpd kill `cat t/logs/httpd.pid` rm -f t/logs/httpd.pid rm -f t/logs/error_log On Thu, 14 Jun 2001, Doug MacEachern wrote: On Fri, 15 Jun 2001, Paul G. Weiss wrote: alignbytes=8, usemymalloc=y, prototype=define ^ ok, here's why i kept asking for perl -V. i don't see Perl's malloc.c ever release its memory pool. when usemymalloc=y, free() only puts memory back into Perl's pool for use by other malloc()'s. i don't see a function to destroy this pool when perl cleans itself up. willing to bet if you rebuild Perl with: Configure -des -Uusemymalloc ... and then rebuild mod_perl, the leaks will go away.
