Re: [ANNOUNCE] mod_perl-1.99_14
Stas Bekman wrote: Stefan Loones wrote: -8<-- Start Bug Report 8<-- 1. Problem Description: My previous working version was : mod_perl-1.99_11-3 (.i386.rpm) I did a rpmbuild --rebuild mod_perl-1.99_14-1.bl.src.rpm (rpm supplied by Stuart Jansen, thanks !) I'm afraid you will have to bug Stuart about this problem. Please use the source build and if that fails then we will handle that. Problem is that on our production machine I need to do everything with rpm. When I have the time I will try it on another machine. After installing (rpm) this mod_perl version 1.9914: restarting apache gives: Starting httpd: Syntax error on line 9 of /etc/httpd/conf.d/perl.conf: Cannot load /etc/httpd/modules/mod_perl.so into server: /etc/httpd/modules/mod_perl.so: undefined symbol: apr_table_compress from: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress I did: # locate libapr-0.so.0 /usr/lib/libapr-0.so.0 /usr/lib/libapr-0.so.0.9.4 I can't see where that URL suggested to use locate. Please follow the exact instructions, i.e. use ldd. Step 4 at this URL. # ls -l /usr/lib/libapr-0.so* lrwxrwxrwx 1 root root 17 May 1 22:51 /usr/lib/libapr-0.so -> libapr-0.so.0.9.4 lrwxrwxrwx 1 root root 17 May 1 22:51 /usr/lib/libapr-0.so.0 -> libapr-0.so.0.9.4 -rwxr-xr-x 1 root root 125760 Mar 23 09:28 /usr/lib/libapr-0.so.0.9.4 # nm /usr/lib/libapr-0.so.0 nm: /usr/lib/libapr-0.so.0: no symbols That's a stripped lib # ldd /usr/sbin/httpd libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0xb72e9000) **snip** I read somewhere that in the future the lowest supported version of Apache would be 2.0.47, but I suppose this means 2.0.46 should still work now. And because of internal reasons I can't upgrade Apache right now. I tried it also on another machine (more or less the same configuration, other bug report can be made if necessary) with the same results. 2.0.46 should work just fine. apr_table_compress indeed doesn't exist in libapr coming with 2.0.46, but mod_perl supplies one in src/modules/perl/modperl_apache_compat.c nm mod_perl.so | grep apr_table_compress Should show you that symbol. I guess the rpm that you are using is broken and doesn't support 2.0.46. Build from the source. When I have some spare time I'll try to build from source. Thanks anyway, Stef -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: [QUESTION] Modperl setup problem.
I see. I'm not using a cgi directory, but am running scripts out of the normal root/sub directories. Here's what I have in httpd right now: LoadModule php4_modulemodules/libphp4.so LoadModule perl_modulemodules/mod_perl.so PerlModule Apache2 ** DocumentRoot "/wwwroot/htdocs" Alias /perl/ /wwwroot/htdocs/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI ** Options FollowSymLinks AllowOverride None SetHandler perl-script PerlHandler Modperl::Registry PerlRequire /wwwroot/htdocs/WebGUI/sbin/preload.perl Alias /extras /wwwroot/htdocs/WebGUI/www/extras I've included the last section because it is of the preload.perl. I don't think it's causing any interference, but I though it would be a good idea to include it just in case. Thanks! Zac -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] mod_perl-1.99_14
Stefan Loones wrote: Stas Bekman wrote: Stefan Loones wrote: -8<-- Start Bug Report 8<-- 1. Problem Description: My previous working version was : mod_perl-1.99_11-3 (.i386.rpm) I did a rpmbuild --rebuild mod_perl-1.99_14-1.bl.src.rpm (rpm supplied by Stuart Jansen, thanks !) I'm afraid you will have to bug Stuart about this problem. Please use the source build and if that fails then we will handle that. Problem is that on our production machine I need to do everything with rpm. When I have the time I will try it on another machine. That's clear. But nothing prevents you from building from the source to test whether it works. I have no problem building mp2 from source on linux against 2.0.46. So w/o being able to reproduce the problem, I can't be much of help here. After installing (rpm) this mod_perl version 1.9914: restarting apache gives: Starting httpd: Syntax error on line 9 of /etc/httpd/conf.d/perl.conf: Cannot load /etc/httpd/modules/mod_perl.so into server: /etc/httpd/modules/mod_perl.so: undefined symbol: apr_table_compress from: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress I did: # locate libapr-0.so.0 /usr/lib/libapr-0.so.0 /usr/lib/libapr-0.so.0.9.4 I can't see where that URL suggested to use locate. Please follow the exact instructions, i.e. use ldd. Step 4 at this URL. Yes, but that's not how you find the library it's linked against. You need to use ldd for that. Step 4 suggests to use locate to find other occurences of this library which may get on the way. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
mod_perl 2 and DBI connection pooling
What is the status of DBI connection pooling (a la Apache::DBI) in mod_perl 2? The 2.0 guide says, "a replacement for Apache::DBI based on the tipool will allow to reuse database connections between multiple threads of the same process." "will allow"? Does that mean it's not done yet? How are people using DBI and mod_perl 2 in production environments? -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] mod_perl-1.99_14
Stas Bekman wrote:
Problem is that on our production machine I need to do everything
with rpm. When I have the time I will try it on another machine.
That's clear. But nothing prevents you from building from the source
to test whether it works. I have no problem building mp2 from source
on linux against 2.0.46. So w/o being able to reproduce the problem, I
can't be much of help here.
Ok, I dit the build from source, and make test comes with the same
error. I'm not sure what info I have to provide you now.
Below are the last lines from make test and after that a new
mp2bug-report (of the installed version 1.9911 of course) to give all
other details, also because this is yet on another machine. In other
words this means I got this error on 3 different machines, the only main
difference of this 3 machines is they all have different kernels.
Greetz, Stef
Last lines of make test:
make[2]: Entering directory
`/home/stef/rpm/modperl/orig/mod_perl-1.99_14/xs/APR'
:[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/t/TEST -bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody' (99:99)
[warning] testing whether 'nobody' is able to -rwx
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/t
"/usr/bin/perl"
-Mlib=/home/stef/rpm/modperl/orig/mod_perl-1.99_14/Apache-Test/lib
-MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(99, 99,
q[/home/stef/rpm/modperl/orig/mod_perl-1.99_14/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
Syntax error on line 12 of
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/t/conf/httpd.conf:
Cannot load
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/src/modules/perl/mod_perl.so
into server:
/home/stef/rpm/modperl/orig/mod_perl-1.99_14/src/modules/perl/mod_perl.so:
undefined symbol: apr_table_compress
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
-8<-- Start Bug Report 8<--
1. Problem Description:
see above
2. Used Components and their Configuration:
*** mod_perl version 1.9911
*** using
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APR_CONFIG => /usr/bin/apr-config
MP_APXS=> /usr/sbin/apxs
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /usr/sbin/httpd -V
Server version: Apache/2.0.46
Server built: Dec 12 2003 05:43:29
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-4.el, archname=i386-linux-thread-multi
uname='linux bui'
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
-Dvendorprefix=/usr -Dsiteprefix=/usr
-Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less
-isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef'
useithreads=define usemultiplicity=
useperlio= d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=un uselongdouble=
usemymalloc=, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-20)',
gccosandvers=''
gccversion='3.2.3 200305'
intsize=o, longsize=s, ptrsize=l, doublesize=8, byteorder=1234
d_longlong=define, longlongsi
mp2: starting a new completely separate perl process
Hi all,
First of all sorry if this is not really mod_perl related
I'm looking for the best way to start a new process from a (SetHandler
modperl) PerlResponseHandler. I don't want the ResponseHandler to wait
for the new process. So the new process needs to be completely
independent. The new process will be doing lots of database queries, and
put the results in a queue (mysql), were it can be read by the next
apropriate request from the user.
I'm thinking about doing this like :
system("path/to/newprocess.pl data > /dev/null >2>&1 &");
Tests with a newprocess.pl script that only does "sleep(300)" seems to
act like suspected. The PerlResponseHandler doesn't wait for it, so
that's ok. It are no child processes, that's also ok. But when I restart
Apache, these new processes all dissappear, and this means they are not
really independent.
The questions:
Is this the best way of doing this ?
Can/will this have a negative effect on mod_perl and/or the perfomance
of mod_perl ?
Thanks for your time,
Regards,
Stef
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2: starting a new completely separate perl process
Stefan Loones wrote:
Hi all,
First of all sorry if this is not really mod_perl related
I'm looking for the best way to start a new process from a (SetHandler
modperl) PerlResponseHandler. I don't want the ResponseHandler to wait
for the new process. So the new process needs to be completely
independent. The new process will be doing lots of database queries, and
put the results in a queue (mysql), were it can be read by the next
apropriate request from the user.
I'm thinking about doing this like :
system("path/to/newprocess.pl data > /dev/null >2>&1 &");
Tests with a newprocess.pl script that only does "sleep(300)" seems to
act like suspected. The PerlResponseHandler doesn't wait for it, so
that's ok. It are no child processes, that's also ok. But when I restart
Apache, these new processes all dissappear, and this means they are not
really independent.
The questions:
Is this the best way of doing this ?
Can/will this have a negative effect on mod_perl and/or the perfomance
of mod_perl ?
It's all explained here:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl
Though you may need to make a few small tweaks to adjus to the 2.0 API.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [ANNOUNCE] mod_perl-1.99_14
Stefan Loones wrote: Stas Bekman wrote: Problem is that on our production machine I need to do everything with rpm. When I have the time I will try it on another machine. That's clear. But nothing prevents you from building from the source to test whether it works. I have no problem building mp2 from source on linux against 2.0.46. So w/o being able to reproduce the problem, I can't be much of help here. Ok, I dit the build from source, and make test comes with the same error. I'm not sure what info I have to provide you now. Great. So now we know that it's not the problem of the rpm. [...] *** /usr/sbin/httpd -V Server version: Apache/2.0.46 Server built: Dec 12 2003 05:43:29 Server's Module Magic Number: 20020903:4 ^^ That explains the problem that you are having. You aren't running 2.0.46, but 2.0.46+, which is not supported. A real Apache/2.0.46 reports: Server's Module Magic Number: 20020903:3 ^^ notice that the minor version number is different. I've just rebuilt mp2 cvs with the 2.0.46 and it works just fine. For 2.0.46 only the symbol should live in mod_perl.so: % nm src/modules/perl/mod_perl.so | grep compress 0002d057 T apr_table_compress Please install the real 2.0.46 and the problem will go away. If you are interested in low-level details, your problem comes from: src/modules/perl/modperl_apache_compat.c: /* pre-APR_0_9_5 (APACHE_2_0_47) * both 2.0.46 and 2.0.47 shipped with 0.9.4 - * we need the one that shipped with 2.0.47, which is major mmn 20020903, minor mmn 4 */ #if ! AP_MODULE_MAGIC_AT_LEAST(20020903,4) ... void apr_table_compress... #endif /* pre-APR_0_9_5 (APACHE_2_0_47) */ you can manually change that to (20020903,5) or similar, but I can't tell if other things won't break. We have this recurrent issue with distros which think that Perl and Apache are used only standalone to run one liners and serve html files, and give their users releases, which Russians call "ni riba ni miaso", literally translated as "not a fish and not meat", leading to the problem you have just encountered yourself. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [QUESTION] Modperl setup problem.
[EMAIL PROTECTED] wrote: I see. I'm not using a cgi directory, but am running scripts out of the normal root/sub directories. Here's what I have in httpd right now: LoadModule php4_modulemodules/libphp4.so LoadModule perl_modulemodules/mod_perl.so PerlModule Apache2 ** DocumentRoot "/wwwroot/htdocs" Alias /perl/ /wwwroot/htdocs/ It needs to be: If you plan to serve script as in http://localhost/perl/myscript.pl SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI As you wrote that, it's totally useless. It doesn't do anything. ** Options FollowSymLinks AllowOverride None SetHandler perl-script PerlHandler Modperl::Registry PerlRequire /wwwroot/htdocs/WebGUI/sbin/preload.perl Alias /extras /wwwroot/htdocs/WebGUI/www/extras I've included the last section because it is of the preload.perl. I don't think it's causing any interference, but I though it would be a good idea to include it just in case. You probably want: SetHandler perl-script PerlHandler Modperl::Registry PerlOptions +ParseHeaders Options +ExecCGI PerlRequire /wwwroot/htdocs/WebGUI/sbin/preload.perl Looks like you may want to spend some time hugging a book on Apache. Or read the online docs on how the Apache configuration works. All these issues aren't really mod_perl-specific. Please let us know if the problem still persists with the fixed config. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl 2 and DBI connection pooling
John Siracusa wrote: What is the status of DBI connection pooling (a la Apache::DBI) in mod_perl 2? The 2.0 guide says, "a replacement for Apache::DBI based on the tipool will allow to reuse database connections between multiple threads of the same process." "will allow"? Does that mean it's not done yet? How are people using DBI and mod_perl 2 in production environments? For now Apache::DBI should work. But it won't take the benefit of threads. It'll work similar to the prefork mpm. I wrote the prototype of DBI::Pool about 1.5 years ago, but since then I didn't have time working on it. Now I have the first priority to finish polishing the mod_perl 2.0 API and release 2.0 as soon as possible. Since we don't get much help from the mod_perl community, it may take a bit longer than it could have taken. Once 2.0 is released, and the main post-release problems get resolved (as people will start moving en-masse to 2.0 and discovering bugs that they should have been doing now (hint! hint!)), I'll hopefully get back to work on that module. But that won't happen for at least next few months. Of course feel free to pick up where I've left and to finish it off. Though I won't be quite available to assist at this time. I really want to finish the majority of the API polish before I need to deliver my OSCon tutorial and the deadline is on June 14th. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
