OT: localtime can't handle epochs less than 0 ???
Off Topic General Perl Question --- Hi All, When i use the 'localtime' function in perl 5.6.1 if i pass it an epoch time of less than 0 then i always get the date of: * Wed Dec 31 19:00:00 1969 Is there a method someone knows of (other function, cpan module?, anything) that will let me convert epochs of less than 0 to valid date/time strings. I am using Date::Parse::str2time and that produces epochs of less than zero. On another note, can anyone points me to a general perl questions list that they would recommend (not too much traffic and medium to expert level?) thanks, simran.
Re: OT: localtime can't handle epochs less than 0 ???
simran wrote: Off Topic General Perl Question --- Please don't do that. And for others, please don't reply to this kind of questions even though you know the answer, and thus encouraging these questions. Let's keep focused on mod_perl here. On another note, can anyone points me to a general perl questions list that they would recommend (not too much traffic and medium to expert level?) Certainly! http://lists.perl.org/ provides a gazillion of perl related lists and newsgroups for you choose from. _ 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/
Apache::Reload and @INC
Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). Has anybody run across this problem? If sowhat is my solution? Thanks a lot, Igor.
Re: Apache 2?
On Tue, 26 Nov 2002, Philip Mak wrote: On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: What do yo mean a modem will tie up the Server? I've never heard this before. Let's say you have a mod_perl page that returns a 100k document, and a 28.8k modem downloads that document. The mod_perl process that is serving that document will be tied up until that modem finishes downloading the document, which is inefficient since the mod_perl processes take up a lot of memory. A lightweight front-end proxy that loads the data from the mod_perl process all at once and then feeds it to the modem would save memory. Things are bit complicated. Kernel can buffer some part of document and there is Apache feature named lingering close. For example, client's speed is 3K/s. If you have 64K kernel TCP send buffer then mod_perl will write 64K very soon but it will wait about 12 seconds to write other 36K. And after mod_perl will have written these 36K it will wait 2 second in lingering close. Even you increase kernel TCP send buffer (it's not always good idea) to 100K anyway you still 2 second lingering close delay for slow clients. Note that you never see lingering close state in /server-status (at least in Apache 1.3) - such processes are marked as idle but they are not really idle - they can not handle requests. Also lingering close time is not accounted in %T directive in the log. You can only estimate the count of Apache processes that is in linegring close state using netstat utulity and looking for FIN_WAIT2 socket states. Igor Sysoev http://sysoev.ru/en/
Re: General interest question: PDF contents handling in PostgreSQL.
Thanks a lot for the advise, Let you know. Fabian. Perrin Harkins wrote: Fabián R. Breschi wrote: I wonder if using ModPerl and PostgreSQL there's any possibility to resemble what in Oracle is called 'Intermedia', in this particular case parsing/indexing content of PDF files inside PostgreSQL as a LOB or alternatively as a flat OS file with metadata parsed/indexed from it into the RDBMS. You can easilly add this to DBIx::FullTextSearch. All you need to do is write a simple frontend that uses a PDF reading module to extract the text. However, it uses MySQL rather than PostgreSQL. - Perrin
Re: General interest question: PDF contents handling in PostgreSQL.
Rob Nagler wrote: I agree with you with the overhead provoked by the Oracle solution. Particularly, using intermedia with the 'Internet File System' option of 8i/9i things get extremely complex in terms of manageability. On the other hand, the user friendly interface that allows to drop a file into the DB and get indexed on the fly has a high cost in terms of system It isn't indexed on the fly in our version (8i). Has this changed?You have to run the indexer regularly, so in this it is no better thanexternal indexing solutions. Indeed, one of the big problems is thatyou can't qualify the query *prior* to index search afaik. It seemsto search the entire index always. In our case, this is extremelycostly, because our space naturally divides, and isolated indexeswould solve the problem much more efficiently. Oracle claims to get the file search within the DB at a fraction of time respect to MS flat files in the IFS solution with 8i onwards (Enterprise edition), obviously it doesn't mean that indexing performs well compared to an analog solution. Didn't pay attention to the fact of the reindexing after dropping a doc inside IFS since I have definitively abandoned the idea due to performance issues. Looking backwards to the history, from Context to Intermedia, now the solution has become 'UltraSearch' for which I personally have to get acquainted about improvements. resources, for my personal point of view this particular workflow did not scale well with existing systems having installed only the RDBMS with no spare capacity, specially in terms of CPU/Memory resources. It scales enough, if you aren't trying to solve the googleproblem. :-) For our users, it's ok performance, even for the heavyinternal users. Just being able to search message boards and fileareas (including word docs) is huge plus for us. Ihave tried IFS within a system doing well the RDBMS job for a lo-mid sized/tuned configuration using Solaris 2.6 and Sun Sparc. IFS made to us the horrible first impression of putting the system down in it's knees. Frankly, didn't had the time/patiente to understand if there was a chance to tune-up a little more and accomplish with the scalation, in my opinion it should have been a waste of time for that particular situation without a real machine scalation. Following your suggestion, I could drop the PDF textual contents achieved using pdftotext to a 'TEXT' datatype into a PostgreSQL, then use a search engine to look inside it to resemble a similar functionality regarding intermedia. Regarding the search engine, guess that it should be necessary to have at least a de-structurated text search algorithm along with something like SOUNDEX in Oracle. I don't think intermedia uses SOUNDEX. It does pure keywordmatching. It's particularly bad in my opinion. It also doesn't learnwhat people really want to know. For example, if you search:http://www.bivio.com/pub/search?s=taxesYou always get the IRS Pubs, but this is rarely what people arelooking for on our site (although they should read the publications,they are more interested in what bivio can do for them in terms oftaxes). Note the performance on the search. The data set you aresearching in the public case is very small in comparison to the wholedocument database which is multi-GB.Hope this helps.Rob I'm not sure what intermedia uses to search text, certainly it don't learns anything about searches (don't know what 'Ultrasearch' is capable of despite all the hyphe Oracle is putting into this technology as usually) . Regarding the search in bivio.com, it's quite okay in terms of human-awareness response but probably it should do better thinking in terms of a 12 pages indexed data set. Thanks a lot for your valuable suggestions. I will let you know just in case of further evolution from what we've talking about. All the best. Fabian.
Re: Apache::Reload and @INC
Igor Vylusko wrote: Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). It's not easy with mod_perl 1.0. The manpage is talking about changing @INC globally for the whole server. I usually do that with 'use lib' in startup.pl. Has anybody run across this problem? If sowhat is my solution? There are several solutions, none of which is very helpful in production, since they either slow things down or may cause collisions when modules with the same names are loaded, see: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ _ 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[2]: Apache::Reload and @INC
in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). SB It's not easy with mod_perl 1.0. The manpage is talking about changing SB @INC globally for the whole server. I usually do that with 'use lib' in SB startup.pl. I define PerlSetEnv PERL5LIB globaly for the whole server but PERL5LIB was stripped out from @INC anyway on enabling PerlInitHandler Apache::Reload in _any_ vhost. I am using PerlSetEnv PERL5LIB per vhost basis and it works fine for me without Apache::Reload. Has anybody run across this problem? If sowhat is my solution? SB There are several solutions, none of which is very helpful in SB production, since they either slow things down or may cause collisions SB when modules with the same names are loaded, see: SB http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ I would like just set PerlInitHandler Apache::Reload on several vhosts only for developing purposes and preserve everything else at that. Thanks for advice, Igor.
Getting at server's MaxClients setting?
Hi, is it possible to get at the configured MaxClients setting from within my handler? I checked Apache::Server which gives you some configuration information but there's no accessor for MaxClients. Any other, easy, way?
Re: NTLM Authentication patch
Hello, I am also interested in this patch, as we encounter lots of problems with some POSTed forms over here. Sometimes we get several Inernal Server Errors until the form gets processed correctly. It usually is enough to click on 'Reload' to get the form processed. This behaviour occurs only using IE 5.5SP2 (Exact version: 5.50.4807.2300). Mozilla is working fine, obviusly without using NTLM... Gerald, was the logfile I sent you helpful? Thanks, Frank - Weitergeleitet von Frank Zimper/BUH/CH/SB_PLC am 27.11.2002 14:17 - Gerald Richter [EMAIL PROTECTED] 11.11.2002 09:33 An: Gerald Combs [EMAIL PROTECTED], [EMAIL PROTECTED] Kopie: Thema: Re: NTLM Authentication patch We recently installed AuthenNTLM where I work, and ran into the POST problems described in the thread at http://marc.theaimsgroup.com/?t=10317736546r=1w=2 After looking through a couple of network traces I think I've found the problem. It appears that after IE authenticates via NTLM, it sends type 1 messages for subsequent requests during a keepalive session. This is fine and dandy unless you're sending a POST request - when it sends the type 1 message, it also sends a Content-length: 0, and doesn't append the POST data. Since the browser has successfully authenticated itself earlier in the keepalive session, AuthenNTLM validates the request and a POST with no accompanying POST data gets passed to the server. Yes, I have seen the same from traces people have send me, but could not reproduce it here (my IE always sends the POST data) I have modified your patch to handle both situations and to have the old behaviour in case of GET requests (for performance reasons) I send you the updated version per private mail, please give it a try if it still works correct for you and let me know. I will release it to CPAN as soon as somebody who had had the problem reports me that the new version solves it. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Apache 2?
- Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Philip Mak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 2:24 AM Subject: Re: Apache 2? . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? Issac
New problems making mod_perl run: Apache/2.0.43 (Unix)mod_perl/1.99_07-dev Perl/v5.8.0
Hi, Well, looks like I've managed to make this server run (thanks for your help), and looks like, in this case, mod_cgi is working (unlike the one shipped with RH 8.0). Now I'm trying to make HTML::Mason work with this configuration. I have downloaded HTML::Mason 1.15, and force-compiled it. This one requires libapreq, which I haven't been able to compile, since it requires Apache::MyConfig . That's supposed to be in the old version of mod_perl, right? So, the only way to have HTML::Mason working is to have both things working at the same time? Any other option? Has anybody made HTML::Mason work with this prerrelease of mod_perl? Thanks again! JJ PS: My whole world depends on HTML::Mason, so please lend me a hand here... -- Juan Julian Merelo Guervos [EMAIL PROTECTED] GeNeura team
Re: Identifying memory leaks
check Apache::leak that will help you to track mod_perl memory leak. Willy Charles frankeldsl@peakpTo: [EMAIL PROTECTED] eak.com cc: Subject: Identifying memory leaks 11/26/2002 02:28 PM A Linux machine running Apache/2.0.35 (Unix) mod_perl/1.99_05-dev Perl/v5.6.1 mysql 4.0.1 uses increasing used memory (according /usr/bin/free), eventually resuting in all memory being consumed. Memory usage drops somewhat after a reboot of apache and mysql, but not completely. If a reference does not go out of scope between sessions, that memory will not be garbage collected. I would like to test for these types of difficulties. Questions: Are there tools to track total (all threads/processes) mod_perl, apache, mysql memory usage? What is the normal behavior for a module which connects (via a global) to a database in terms of mysql processes started?
Re: Getting at server's MaxClients setting?
Bas A.Schulte wrote: Hi, is it possible to get at the configured MaxClients setting from within my handler? I checked Apache::Server which gives you some configuration information but there's no accessor for MaxClients. Any other, easy, way? see my previous post from earlier this week :) http://marc.theaimsgroup.com/?l=apache-modperlm=103791699126881w=2 in this case, MaxClients looks like it calls ap_daemons_limit to make the setting, so you may be able to create a subclass that offers up that API to perl-land. for more information on how, you can check out the slides from my recent ApacheCon talk: http://www.modperlcookbook.org/~geoff/slides/ApacheCon/oo-mod_perl-printable.ppt.gz hmm... sounds like another good idea to add to my next talk :) --Geoff
Re: Getting at server's MaxClients setting?
Geoff, On Wednesday, November 27, 2002, at 03:07 PM, Geoffrey Young wrote: in this case, MaxClients looks like it calls ap_daemons_limit to make the setting, so you may be able to create a subclass that offers up that API to perl-land. for more information on how, you can check out the slides from my recent ApacheCon talk: http://www.modperlcookbook.org/~geoff/slides/ApacheCon/oo-mod_perl-printable. ppt.gz hmm... sounds like another good idea to add to my next talk :) Well, for the moment, I'll grep for it in the current httpd.conf ;) Just thought I'd ask in case I was missing something obvious. Thanks, Bas.
Re: segmentation fault using a startup file
Hello, Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple which I use togeather with mod_perl. This seems to be a knowen problem but without a known solution. All I could find is that you can either: 1. Compile your own apache 2. Use another XML parser perl module Is someone here with another solution? Thanks, Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Re: Getting at server's MaxClients setting?
Bas A.Schulte wrote: Geoff, On Wednesday, November 27, 2002, at 03:07 PM, Geoffrey Young wrote: in this case, MaxClients looks like it calls ap_daemons_limit to make the setting, so you may be able to create a subclass that offers up that API to perl-land. for more information on how, you can check out the slides from my recent ApacheCon talk: http://www.modperlcookbook.org/~geoff/slides/ApacheCon/oo-mod_perl-printable. ppt.gz hmm... sounds like another good idea to add to my next talk :) Well, for the moment, I'll grep for it in the current httpd.conf ;) Just thought I'd ask in case I was missing something obvious. nope, you didn't miss anything. unfortunately, mod_perl 1.X does not offer up the entire Apache API to perl land (though the intent of 2.0 is to do just that). actually, I just whipped up a module that offers get/set for MaxClients: http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-MaxClients-0.01.tar.gz it's not perfect (it doesn't offer the checks that the MaxClients directive does), but it seems to work. with a little effort, I suspect it could be worked out so that you don't need a request object, but rather an Apache::Server object. however, it shows how easy mod_perl makes it to open up the Apache API where you need it. --Geoff
modperl file cache screwed up
Hi, on my installation of Apache (1.3.27 + last Modperl) I have the problem that on two diffrent virtual servers, there are perl CGIs with the same name but entirely diffrent funcions. I have the effect that sometimes when asking to execute the CGI of server1, the CGI of server2 is run and sends its output. Did I miss something? Does the cache not handle virtual servers correctly? (e.g. cache by filename, not by entire URL) Or do I have to set a variable in the directory section of each server? Sorry, I'm quite unfamiliar with Apache/Perl. Thanks! Peter -- ITServ: kompetent, zuverlässig und fair - ITServ GmbH Peter Bauer Phone:++49 (0)700 487378-33 Roentgenstrasse 11-or- ++49 (0)700 ITSERV-DE D-65474 Bischofsheim Fax: ++49 (0)700 487378-32 GERMANY -or- ++49 (0)700 ITSERV-FA Mail: [EMAIL PROTECTED] Mobile : ++49 (0)172 9391076 -
Re: modperl file cache screwed up
Bauer, Peter wrote: Hi, on my installation of Apache (1.3.27 + last Modperl) I have the problem that on two diffrent virtual servers, there are perl CGIs with the same name but entirely diffrent funcions. I have the effect that sometimes when asking to execute the CGI of server1, the CGI of server2 is run and sends its output. Did I miss something? Does the cache not handle virtual servers correctly? (e.g. cache by filename, not by entire URL) Or do I have to set a variable in the directory section of each server? Sorry, I'm quite unfamiliar with Apache/Perl. In general, this should not be a problem: Apache::Registry is smart enough to know that you are running with vhosts and it caches the scripts accordingly. however, if you're having problems one thing to try is setting $Apache::Registry::NameWithVirtualHost = 1; in your startup.pl see http://perl.apache.org/docs/1.0/guide/config.html#toc_A_Script_From_One_Virtual_Host_Calls_a_Script_with_the_Same_Path_From_the_Other_Virtual_Host for more details. the other thing you can try is swapping Apache::Registry for Apache::RegistryNG (which uses a filepath instead of URI for script caching) and see if that helps at all. --Geoff
Re: New problems making mod_perl run: Apache/2.0.43 (Unix)mod_perl/1.99_07-dev Perl/v5.8.0
On 27 Nov 2002, Juan Julian Merelo Guervos wrote: Hi, Well, looks like I've managed to make this server run (thanks for your help), and looks like, in this case, mod_cgi is working (unlike the one shipped with RH 8.0). Now I'm trying to make HTML::Mason work with this configuration. I have downloaded HTML::Mason 1.15, and force-compiled it. This one requires libapreq, which I haven't been able to compile, since it requires Apache::MyConfig . That's supposed to be in the old version of mod_perl, right? So, the only way to have HTML::Mason working is to have both things working at the same time? Any other option? Has anybody made HTML::Mason work with this prerrelease of mod_perl? At the moment libapreq hasn't been ported to mod_perl-2, but that's being worked on. The mason mailing list archives (see http://www.masonhq.com/) contain discussions of using Mason and mod_perl-2. Apparently the requirement of libapreq can be ignored if you use CGI as a value for args_method. There's some other mod_perl-1 stuff used in Mason related to constants and such; these can be handled either by some simple changes to Mason modules and/or through mod_perl-2's compatibility mode. -- best regards, randy kobes
Re: segmentation fault using a startup file
Hi there, On 27 Nov 2002, Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple [snip] All I could find is that you can either: 1. Compile your own apache [snip] What is it about compiling your own Apache that troubles you? 73, Ged.
Re: segmentation fault using a startup file
Hello, Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: On 27 Nov 2002, Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple [snip] All I could find is that you can either: 1. Compile your own apache [snip] What is it about compiling your own Apache that troubles you? It is a lot of work to do. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. Jan -- Jan Theofel Fon: +49 (7 11) 48 90 83 - 0 ETES - EDV-Systemhaus GbRFax: +49 (7 11) 48 90 83 - 50 Libanonstrasse 58 A * D-70184 Stuttgart Web: http://www.etes.de __ Inflex - eMail Scanning and Protection Queries to: [EMAIL PROTECTED]
Re: segmentation fault using a startup file
Hi Jan, On 27 Nov 2002, Jan Theofel wrote: Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: What is it about compiling your own Apache that troubles you? It is a lot of work to do. Only the first couple of times. Takes me about two minutes nowadays. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? 73, Ged.
Re: segmentation fault using a startup file
On Wed, 27 Nov 2002, Ged Haywood wrote: Date: Wed, 27 Nov 2002 20:56:01 + (GMT) From: Ged Haywood [EMAIL PROTECTED] To: Jan Theofel [EMAIL PROTECTED] Cc: mod_perl mailinglist [EMAIL PROTECTED] Subject: Re: segmentation fault using a startup file Hi Jan, On 27 Nov 2002, Jan Theofel wrote: Am Mit, 2002-11-27 um 17.33 schrieb Ged Haywood: What is it about compiling your own Apache that troubles you? It is a lot of work to do. Only the first couple of times. Takes me about two minutes nowadays. I agree. The first few times I compiles anything on Unix, I thought Wow, this is hard. Now I understand how things fit together and why it's a Good Thing to compile your own stuff. I feel dirty now when I use RPMs of Perl, Apache, or vi. Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? A few months ago I tried out some different Linux distros. I liked Debian a lot until I got this wierd feeling about system dependencies on their own Perl. I ditched it within hours of that as I felt that it might prove easy to break the system. If you feel that you can't compile your own Apache on SuSE, you should probably consider a different distro for your web server and rely on those other nice bits on systems where you can do without the flexibility of compiling your own stuff. What will you do when the next security hole is found in Apache and you can't upgrade for fear of breaking your system? ky
RE: segmentation fault using a startup file
Jan Theofel wrote: Am Mon, 2002-11-25 um 17.46 schrieb Jan Theofel: (Re)starting apache results in the following segmentation fault: The problem with this segmentation fault is XML::Simple which I use togeather with mod_perl. This seems to be a knowen problem but without a known solution. It was a known problem with older versions of Apache. Specifically, the Apache build process statically linked in expat (for mod_dav?) and XML::Parser dynamically loaded expat causing a symbol conflict/segfault. My understanding is that modern builds of Apache no longer bundle expat but use the system supplied one so both Apache and XML::Parser share the dynamically loaded one - which of course is the 'right answer'. I'm not sure what version that change came in at (1.3.22 rings a bell) although I guess it's possible that SUSE may have forced a static linkage. What version of XML::Simple are you using? If it is 1.08 or earlier, then the expat conflict is almost certainly your problem. You could upgrade to 1.08_01 which allows you to use any SAX parser (eg: XML::LibXML) instead of expat/XML::Parser. If you're already running version 1.08_01 and you have SAX installed then work out which parser module you're using (the last one in lib/XML/SAX/ParserDetails.ini). Try selecting a different one (by swapping the order around in the ini file). Regards Grant
