@inc ithreads virtual server +parent
I'm looking at the information in mod_perl 2 User's Guide (and online) about using VirtualHost and +Parent, with an ithreads-enabled Perl, in order to be able to modify @inc by virtualserver. On my system I basically have that setup, and have tried it, and it seems to work fine (I tried it with prefork, though that appears not to matter except for the inefficiency of course). I'm wondering what would happen if I -didn't-have an ithreads-enabled Perl, but still set up the httpd.conf with the virtual-host/+parent stanzas? Will it fail on startup with an error about +parent being unsupported or some other error? Or does it run fine but I end up with a shared @inc across all virtual servers perhaps? .. I have a somewhat limited customer set and each customer will probably run a test production setup, with mostly the same code in each environment (thus @inc conflicts). I'm wondering what, if anything, they might see I take it the only real way around the above situation is either to use an ithreads-enabled Perl or to run separate apaches... is there some other way? Thanks! Dylan
segmentation faul exit (11) .. but not php?
Hi, on an internal system I have a slightly older apache/mod_perl setup running we're seeing the segmentation fault exit (11) issue (http://209.85.173.104/search?q=cache:yRtrb5W_BdUJ:modperlbook.org/html/ 22-3-3-exit-signal-Segmentation-fault-11.html+%22exit+signal+Segmentatio n%22+mod_perlhl=enct=clnkcd=1gl=us) show up in the error log at the end of each page delivery by the server. 99% of the time things work fine even with this error, though eventually pages start showing up empty until a restart. I'd like to eliminate this problemhowever, we're not using mod_php and I don't believe it's compiled into the server, unless I'm not aware of the right way to check for that (note that we do have a number of php modules installed on the system though). There is no LoadModule for anything php related in my httpd.conf and httpd -l does not show anything php-related. I'm wondering if perhaps this issue also occurs as a result of other packages ... perhaps mod_dav_svn? Any ideas? Maybe I'm missing something? Here is a list of stuff we're using: Linux blahblah 2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux /usr/sbin/httpd -v Server version: Apache/2.0.52 Server built: Feb 28 2005 07:21:27 (yes I know it's missing the latest security patches.) /usr/sbin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c grep -i loadmod httpd.conf 21 LoadModule access_module modules/mod_access.so LoadModule auth_module modules/mod_auth.so LoadModule auth_anon_module modules/mod_auth_anon.so LoadModule auth_dbm_module modules/mod_auth_dbm.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule ldap_module modules/mod_ldap.so LoadModule auth_ldap_module modules/mod_auth_ldap.so LoadModule include_module modules/mod_include.so LoadModule log_config_module modules/mod_log_config.so LoadModule env_module modules/mod_env.so LoadModule mime_magic_module modules/mod_mime_magic.so LoadModule cern_meta_module modules/mod_cern_meta.so LoadModule expires_module modules/mod_expires.so LoadModule deflate_module modules/mod_deflate.so LoadModule headers_module modules/mod_headers.so LoadModule usertrack_module modules/mod_usertrack.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule mime_module modules/mod_mime.so LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule status_module modules/mod_status.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule asis_module modules/mod_asis.so LoadModule info_module modules/mod_info.so LoadModule dav_fs_module modules/mod_dav_fs.so LoadModule vhost_alias_module modules/mod_vhost_alias.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule dir_module modules/mod_dir.so LoadModule imap_module modules/mod_imap.so LoadModule actions_module modules/mod_actions.so LoadModule speling_module modules/mod_speling.so LoadModule userdir_module modules/mod_userdir.so LoadModule alias_module modules/mod_alias.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule cache_module modules/mod_cache.so LoadModule suexec_module modules/mod_suexec.so LoadModule disk_cache_module modules/mod_disk_cache.so LoadModule file_cache_module modules/mod_file_cache.so LoadModule mem_cache_module modules/mod_mem_cache.so LoadModule cgi_module modules/mod_cgi.so LoadModule perl_module modules/mod_perl.so PerlLoadModule Apache2::Status
RE: version checking
Oh, heh heh, good point I should have mentioned that I'm way back in the Clinton/Gore software era because we still have customers on RHEL 3. The difference is the jump to apache2/mod_perl2 from 1.3/1, that I've been tasked with. Off to a great start...heh. I was hoping to get some good advice from the mod_perl collective out here (which, I agree, yours is good advice, I just can't follow it). Dylan -Original Message- From: Jonathan Vanasco [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:52 PM To: modperl List Subject: Re: version checking On Apr 25, 2007, at 8:13 AM, Carl Johnstone wrote: RHEL5 comes with mod_perl 2.0.2, perl 5.8.8 and apache 2.2.3 so it's *nearly* up to date! =item 2.0.3 November 28, 2006 =item 2.0.2 - October 20, 2005 considering that its April 2007, i think using 2.03 and compiling from source is the best route to go.
RE: Are RHEL 3.0 mod_perl 2.0.x compatible?
Ok, point taken I'll give her a go and see what happens. Thanks guys -Original Message- From: Carl Johnstone [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 5:44 PM To: modperl@perl.apache.org Subject: Re: Are RHEL 3.0 mod_perl 2.0.x compatible? Jonathan Vanasco wrote: second: your issue seems to be that you're trying to run everything via rpms , which is causing your dependency issue. try compiling from source. if you use cpan to install modperl, it'll download all of the perl dependancies for you. You *may* be able to find rpms that somebody else has built that work on RHEL3 - but unless you want guaranteed repeatability for multiple servers, I wouldn't bother with rpms. Like Jonathan says just build and install from source. Even if you are building many servers, it may be easier to build your own rpms than to find some suitable! Carl
