Re: Preloading DBI crashes Apache
Dan Brosemer wrote: Here's the thread to date: http://marc.theaimsgroup.com/?l=apache-modperlm=104586287823510w=2 On Sun, Feb 23, 2003 at 10:27:22AM -0500, Dan Brosemer wrote: On Sun, Feb 23, 2003 at 04:35:39AM -0800, Ask Bjoern Hansen wrote: Hi. I'm new here, and hoping someone can help me. I've installed the latest -current version of OpenBSD, and loaded mod_perl as a DSO. That gets me Apache 1.3.27, Perl 5.8.0, and mod_perl 1.27. The plot thickens. Loading mod_perl statically gets rid of this problem. Even with otherwise-identical configure arguments. Yet, the DSO mod_perl works fine except when I preload DBI. I'm _quite_ confused. I'd really like the DSO method to work, as then I wouldn't have to modify the OpenBSD source tree (any more than I normally do, anyway). Does anyone have suggestions? This sounds kind of similar to some problems I had on Debian. Try a groups.google.com search for author of 'Keith G. Murphy' and subject of Memory leak on reload when the 'Pg' driver is preloaded or even Apache segfaulting upon perl module load. I gave up on it quite some time ago and started using the statically linked mod_perl.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Juha-Mikko Ahonen wrote:
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI-install_driver('Pg'), the Apache processes stayed at 8.4 MB. I
bombarded the Apache with ApacheBench and multiple SIGUSR1 but I found
no memory leaks. The process sizes did not change.
The interesting thing I see here is that you are using a different
libapache-mod-perl version. I'm using the one from stable. I hesitate
to install yours (from unstable), since apt-get wants to upgrade all of
perl (a whole *bunch* of shit), and I'm not keen on the idea of
permanently tracking unstable with something as complex as Perl and its
dependents. I mean, crap, it even wants to upgrade libc6. Last time I
tried, downgrading libc6 was not fun. I'm guessing you might find it
difficult to downgrade as well, since you probably have Perl 5.8. Any
ideas?
I'm pretty tired at the moment, so there might have been something I
mislooked. I'll give it another look tomorrow. At work, where I don't
have any distractions :)
I appreciate you looking at this. But it's mainly for the maintainer at
this point...
It's pretty odd, in my view, that the Apache processes which did not
preload the Pg driver were smaller.
Why would that be odd? Seems intuitively right to me.
Keith, could you post results to modperl list if people at debian-isp
come to a different (or to the same) solution. I'm not subscribed to
the list.
Will do, for sure.
Memory leak on reload when the 'Pg' driver is preloaded
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
The leak happens when you send SIGUSR1 to the parent. Every time you do
it, you get more memory eaten (multiple megabytes), both in the parent
and (new) children.
It happens with the stock apache-ssl that comes from Debian stable.
Could well be a Debian-specific problem.
Using Debian's static-mod_perled apache-perl eliminates the problem.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Stathy G. Touloumis wrote: Using Debian's static-mod_perled apache-perl eliminates the problem. Do you mean you are using the 'so' version that comes with Debian? Yes, in the case that failed. The package is called 'libapache-mod-perl'. You should be using the static build of apache/mod_perl You're telling me. :-( By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Used If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. Thanks.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
Re: Memory leak on reload when the 'Pg' driver is preloaded
Juha-Mikko Ahonen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. I already have, months ago. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. Huh? I would think that would be a really good reason to yank it. If it were Debian-related, the maintainer could fix it and keep it.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? Yes, I'm sure. Red Hat comes with Apache prebuilt for DSO I believe. I have worked on contracts for a number of organizations which use DSO mod_perl in high volume environments (hundreds of thousands of users). Then I take your word for it. (My question was sincere, not argumentative, by the way). There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. What I meant was that some (perhaps slightly unusual in some way) configurations seem to give more problems than others. For example I think that servers using SSL have perhaps been prone to troubles, but it could just as easily be that the people who experienced the problems were not careful to follow what you might say are slightly more complex than usual build procedures. Hmmm. In my case, I replicated the problem with Debian's plain vanilla Apache as well, for the very purpose of simplification. So SSL does not seem to be involved.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Daniel Jacobowitz wrote: On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote: My own bug report is now 47 days old, without apparent followup. Hmmm, I probably should not have posted that. Sounds like a major whine. That's because I'm having an attack of real life. I haven't had time to look at my Debian bug reports in a month or so now. I don't know why the DSO is leaking in a case when the static module isn't, but it should be fixable; I just need to find five or six hours to sit down with it. Thanks, Dan, this really wasn't meant to be a slam-the-developer session. I really, *really* appreciate all the work you've done already. Now I feel tacky. :-( It's not like it was an obvious problem: I only got the DSO to leak when loading the Pg driver. That's pretty obscure.
Re: Memory leak on reload when the 'Pg' driver is preloaded
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko Ahonen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same if
I comment out the Apache::DBI line in addition. This works with plain
apache, or apache-ssl.
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
If I comment it all out including the Apache::Status line, I get neither
the segfault or the leak. (Well, small leak, a few bytes).
So the install_driver masks a bigger problem with Apache::Status?
That's just too weird. But true, I swear.
Is there anyone else out there with Debian stable w/
apache+libapache-mod-perl who can try to reproduce this simple case?
I'd really like either a confirmation or a counterexample. If the
latter, I'd chalk it up to a weirdness on my system (and probably not
even pursue it, since I've moved on to the static version). I'm
pursuing it this far so Dan J. might get some useful feedback.
I've submitted this to debian-isp as well; maybe someone there can try it.
Re: mod_perl restart vs. graceful
Stephen Reppucci wrote:
Hi Darren,
See my suggested refinement below (I don't like to leave the server
down any longer than needed...8^):
On Tue, 9 Apr 2002, darren chamberlain wrote:
For exactly this reason, I always modify apachectl so that the restart
option looks like:
restart)
timeout=${2:-5}
count=0
$0 stop
while [ $count -lt $timeout ]; do
while [ -f $PIDFILE -a $count -lt $timeout ]; do
echo -n .
sleep 1
count=`expr $count + 1`
done
echo
$0 start
;;
This will sleep for $2 (or 5 seconds) between stopping and starting.
The sleep ensures that the start doesn't get called too quickly.
On Debian, if you use the /etc/init.d/apache[-perl] script for
restarting, it uses the start-stop-daemon program to do essentially the
same thing. (Another reason I like Debian :-).
Re: [WOT] emacs and WEBDAV
Kee Hinckley wrote: Emacs over WebDAV should work fine if you run something that supports WebDAV as a filesystem (e.g. OSX), but that's not going to help you much. If you're running Linux, this looks like fun: http://sourceforge.net/projects/dav There's also kiwifs: http://kiwi.stanford.edu If you're only running Linux on the server, well, maybe you could roll something with samba (maybe you would need kernel oplocks?). Seems like all the good stuff is for Linux, doesn't it? ;-)
Re: Excellent article on Apache/mod_perl at eToys
Andrew Ho wrote: Hello, I checked the list archives and it didn't look like this had been posted yet. For those of you who haven't seen it yet... a great read on perl.com about the Apache/mod_perl setup at eToys, co-authored by our own mod_perl regular contributer Perrin Harkins. http://www.perl.com/pub/a/2001/10/17/etoys.html That's so awesome, the single best piece of technical writing on the web I can remember in a long time. Thanks for sharing. By the way, I noticed he documented still another gotcha due to a sneaky closure. Does anyone know off-hand whether the Perl 6 folks plan to change the closure syntax so they don't sneak into your code this way? I wonder how many mod_perl authors have never been burned by one?
Re: Advanced daemon allocation
Stas Bekman wrote: On Tue, 19 Jun 2001, Keith G. Murphy wrote: Matthew Byng-Maddick wrote: On Mon, Jun 18, 2001 at 10:41:50AM -0500, Keith G. Murphy wrote: This is only true if you're serving images off the mod_perl server which is crazy unless you're generating them. No images involved, but I was seeing a performance improvement under HTTP 1.1. What happened was that the user kept getting the same daemon for each invocation of the Apache::CGI script, which seemed to be due to HTTP 1.1's persistent connections. Do you mind if I ask how many users were using the service? Because if there were just a few, than it's true. Yes, it was very few indeed: one or two! You and Matthew Byng-Maddick have made me realize that mine was probably the *only* situation in which the KeepAlive technique would have been very useful: Rapid reinvocation of a script; extremely limited system memory; very few users. Almost sorry I brought it up, but it's been an informative discussion.
Re: Advanced daemon allocation
Stas Bekman wrote: On Mon, 18 Jun 2001, Keith G. Murphy wrote: Trevor Phillips wrote: Is there any way to control which daemon handles a certain request with apache 1.x? eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl application to 10 specific daemons would improve the efficiency of data cached in those processes. Making sure the browser supports HTTP 1.1 (persistent connections) will get you a lot better performance in many cases, since a particular user will tend to keep hitting the same daemon, so that helps if they're hitting the same or a related script over and over. I beg your pardon Keith, but probably in most cases this is a very bad suggestion. No offense taken. Notice I said many cases, not most cases. ;-) But your comment is appreciated: I certainly wouldn't want to mislead anyone. It would be a very bad idea in a busy internet situation. By leaving the KeepAlive's on (I guess that's what you refer to by persistent connections) I say persistent connections because in my case, I saw a difference coming into play between Netscape and IE browsers - and it was because IE supported HTTP 1.1, thus persistent connections. Yes, KeepAlive had to be on to see the effect. you tie a server to a user. Which makes your service very unscalable. Given that you can afford X servers processes running, when X users will get their persistent connection open, your service becomes closed to any other users. Of course. For me it was really very much a poor man's alternative to setting aside a certain number of daemons for mod_perl. I really didn't have enough system resources to do that! Your solution is good though if you know that you can have at most X users over a long time span. Which is usually the case on the intranet servers in the small companies. Which was exactly my situation. :-)
Re: Advanced daemon allocation
Matthew Byng-Maddick wrote: On Mon, Jun 18, 2001 at 10:41:50AM -0500, Keith G. Murphy wrote: Trevor Phillips wrote: Is there any way to control which daemon handles a certain request with apache 1.x? eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl application to 10 specific daemons would improve the efficiency of data cached in those processes. Making sure the browser supports HTTP 1.1 (persistent connections) will get you a lot better performance in many cases, since a particular user will tend to keep hitting the same daemon, so that helps if they're hitting the same or a related script over and over. This only works within the keepalive timeout. (default configuration 15s) Yes, this can have negative implications, as Stas explained. It's a really good point, and one I wasn't fully aware of. It worked well *in my situation*. In one case, I was seeing really bad performance from an app, but it seemed acceptable to the users, who were all running IE, where I was running Netscape, which still doesn't support 1.1 in version 4 browsers. :-( Dunno about 6, Mozilla, etc. This is only true if you're serving images off the mod_perl server which is crazy unless you're generating them. Well, it certainly also seemed to be true for rapid, *subsequent* invocations of a script. No images involved.
Re: Advanced daemon allocation
Trevor Phillips wrote: Is there any way to control which daemon handles a certain request with apache 1.x? eg; Out of a pool of 50 daemons, restricting accesses to a certain mod_perl application to 10 specific daemons would improve the efficiency of data cached in those processes. Making sure the browser supports HTTP 1.1 (persistent connections) will get you a lot better performance in many cases, since a particular user will tend to keep hitting the same daemon, so that helps if they're hitting the same or a related script over and over. In one case, I was seeing really bad performance from an app, but it seemed acceptable to the users, who were all running IE, where I was running Netscape, which still doesn't support 1.1 in version 4 browsers. :-( Dunno about 6, Mozilla, etc. Noticed you were running Netscape on Linux; what are your users running? ;-)
Re: @INC and mod_perl - PerlSetEnv PERL5LIB ... doesn't seem to work
Stas Bekman wrote: On Wed, 11 Apr 2001, Keith G. Murphy wrote: Vivek Khera wrote: "TS" == Tim Sweetman [EMAIL PROTECTED] writes: TS you can add directories to @INC by putting TS PerlSetEnv PERL5LIB /home/httpd/perl Just use the second method in the guide. ie, use lib '/path/to/lib' in a startup script. I request that the guide be changed, since apparently the 'PerlSetEnv' way hasn't worked properly for some time. Never has for me, anyway. Do you have the taint mode turned on? I think at some point mod_perl ignores PERL5LIB settings then. Can you confirm that? It seems to be working like a charm for me now. :-) I regret the false imputation... The root of my misunderstanding was that I did not realize that when I would start apache by hand, it was getting PERL5LIB from my shell environment. Then, when the system would reboot, and start Apache, it didn't have it! So I probably just had things misconfigured (like using 'SetEnv' instead of 'PerlSetEnv'), and mistakenly concluded that 'use lib' was the only thing that works reliably. I could never really debug the problem properly, since everything always worked by hand. Then when I saw Tim's post, it seemed to confirm what I already thought I knew. Shows what assuming will do. Hee-haw. ;-)
Re: @INC and mod_perl - PerlSetEnv PERL5LIB ... doesn't seem to work
Stas Bekman wrote: On Wed, 11 Apr 2001, Keith G. Murphy wrote: Vivek Khera wrote: "TS" == Tim Sweetman [EMAIL PROTECTED] writes: TS you can add directories to @INC by putting TS PerlSetEnv PERL5LIB /home/httpd/perl Just use the second method in the guide. ie, use lib '/path/to/lib' in a startup script. I request that the guide be changed, since apparently the 'PerlSetEnv' way hasn't worked properly for some time. Never has for me, anyway. Do you have the taint mode turned on? I think at some point mod_perl ignores PERL5LIB settings then. Can you confirm that? Ah, I just noticed something else. If I *am* running a startup script that 'use's modules that are in my PERL5LIB, I must do 'use lib', or the script fails to load them. So 'PerlSetEnv PERL5LIB' is pretty much useless (because not sufficient and redundant to 'use lib') in this case. That's probably normal and to-be-expected, but it would be nice if it were actually documented.
Re: @INC and mod_perl - PerlSetEnv PERL5LIB ... doesn't seem to work
Vivek Khera wrote: "TS" == Tim Sweetman [EMAIL PROTECTED] writes: TS you can add directories to @INC by putting TS PerlSetEnv PERL5LIB /home/httpd/perl Just use the second method in the guide. ie, use lib '/path/to/lib' in a startup script. I request that the guide be changed, since apparently the 'PerlSetEnv' way hasn't worked properly for some time. Never has for me, anyway.
Re: HTTP_REFERRER and Mod_perl
"Khachaturov, Vassilii" wrote: Please keep in mind that what you describe is a behaviour of one particular user agent. Some UAs just never send referer for anonymity. (Sometimes proxy will do that for them). Some do it for links from a web page, but not from a file:// URL. Some don't care for the URI scheme, and you get referer's from one's bookmarks on the disk. Another example: Just noticed the other day that NS6 won't send a referer if the user does "open in a new window" when right-clicking a link to a script. Gack. Though I would consider that a bug.
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory
Les Mikesell wrote: [cut] I don't think I understand what you mean by LRU. When I view the Apache server-status with ExtendedStatus On, it appears that the backend server processes recycle themselves as soon as they are free instead of cycling sequentially through all the available processes. Did you mean to imply otherwise or are you talking about something else? Be careful here. Note my message earlier in the thread about the misleading effect of persistent connections (HTTP 1.1). Perrin Harkins noted in another thread that it had fooled him as well as me. Not saying that's what you're seeing, just take it into account. (Quick-and-dirty test: run Netscape as the client browser; do you still see the same thing?)
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscriptsthat contain un-shared memory
Perrin Harkins wrote: Keith Murphy pointed out that I was seeing the result of persistent HTTP connections from my browser. Duh. I must mention that, having seen your postings here over a long period, anytime I can make you say "duh", my week is made. Maybe the whole month. That issue can be confusing. It was especially so for me when IE did it, and Netscape did not... Let's make everyone switch to IE, and mod_perl looks good again! :-b
Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory
Perrin Harkins wrote: [cut] Doesn't that appear to be saying that whichever process gets into the mutex first will get the new request? In my experience running development servers on Linux it always seemed as if the the requests would continue going to the same process until a request came in when that process was already busy. Is it possible that the persistent connections utilized by HTTP 1.1 just made it look that way? Would happen if the clients were MSIE. Even recent Netscape browsers only use 1.0, IIRC. (I was recently perplexed by differing performance between MSIE and NS browsers hitting my system until I realized this.)
Re: mod_perl advocacy project resurrection
Stas Bekman wrote: Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. [cut] It strikes me that there might be a route not yet taken to increase *availability* of mod_perl. Think about all the ISPs that host personal and small business web sites. How many of them run Apache and allow their customers to code Perl scripts? Earthlink (which is huge), for one. Yet it doesn't have mod_perl installed. But if it did, both Earthlink itself and the customers might see performance benefits from Apache::Registry scripting. The two biggest obstacles I see to this: (1) Have to have a *reliable* way for customers to reload their Registry scripts. Here's where some development work might be needed. (2) It might be argued that anything that *needs* Registry is too heavy-duty for the ISP to want it running anyway. Thoughts? (I wonder if it might be possible to enlist the Apache folks to campaign for this as well, since anything that keeps out the dread IIS is desirable). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Patrick wrote: On Thu, Dec 07, 2000 at 03:52:01PM +0100, Stas Bekman took time to write: Your problem is that you try to use the precompiled broken packages provided by distros. If I can jump... I must say that I *never* had a problem with Debian packages of mod_perl. Maybe RedHat packages have (don't known I don't use that), but Debian packages are correct for me. So on a Debian System, you just need to do : apt-get install libapache-mod-perl and tweak the configuration files. At least that's my experience. Mmmm, I did have a big problem (segfaults) with the apache and mod_perl from Debian 2.1. I think it was an upstream, not package, problem though: that was when most everybody was having a problem with mod_perl as a module. I built it into Apache though, and it worked fine. Debian 2.2 has it built that way as a binary, so I've just gone with that. I've stayed away from the separate module thing, so I have no idea how well it works now. (BTW, kudos the the Debian maintainer which probably reads this list) Absolutely. I've never seen a package problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pointer to a CGI.pm list
"Roderick A. Anderson" wrote: Sorry but I've run out of sources. (Don't have netnews.) Is there a mailing list for CGI.pm? I've done all I can by reading the 'the book' and searching the net. Can't find anything like the symtoms I'm seeing. Actually the problem may be a lack of perl knowledge on my part but it manifests itself when using CGI.pm so I have to start there. I take the above to mean that you don't have Usenet access? Maybe you could use DejaNews (www.deja.com) to access comp.lang.perl.modules.
Re: Why isn't PerlSetEnv working for me?
Doug MacEachern wrote:
On Wed, 27 Sep 2000, Keith G. Murphy wrote:
Upon further investigation, what I am seeing is that PERL5LIB gets
passed into %ENV just fine. It's just not being used to locate modules;
it is not in @INC. Could the part of Perl that pushes the PERL5LIB
setting to @INC have already executed prior to my PerlSetEnv statement?
i don't think so, it's set by mod_perl.c on every request, in
perl_per_request_init():
/* SetEnv PERL5LIB */
if (!MP_INCPUSH(cld)) {
char *path = (char *)table_get(r-subprocess_env, "PERL5LIB");
if (path) {
perl_incpush(path);
MP_INCPUSH_on(cld);
}
}
what version of mod_perl are you using?
1.21_03-dev (it's the one in the current Debian release).
Re: Why isn't PerlSetEnv working for me?
Stas Bekman wrote:
On Tue, 26 Sep 2000, Keith G. Murphy wrote:
I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux.
I have the following lines towards the end of my httpd.conf:
PerlSetEnv PERL5LIB /usr/local/MyPerl/lib
PerlRequire startup.pl
Include perllocs.conf
However, upon system startup, my startup.pl fails because it can't find
a particular module in the @INC list.
If I start Apache from the command line, it works. This is undoubtedly
because PERL5LIB is set up in my /etc/profile, to the same path.
I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just
doesn't work.
Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But
why?
http://thingy.kcilink.com/modperlguide/config/PerlSetVar_PerlSetEnv_and_PerlP.html
Yes, I have looked at that.
Regarding the setting of PerlPassEnv PERL5LIB in httpd.conf: if you turn
on taint checks (PerlTaintCheck On), $ENV{PERL5LIB} will be ignored
(unset). See the 'Switches -w, -T' section.
I can explicitly set it *off*:
PerlTaintCheck Off
and still get the same behavior.
Upon further investigation, what I am seeing is that PERL5LIB gets
passed into %ENV just fine. It's just not being used to locate modules;
it is not in @INC. Could the part of Perl that pushes the PERL5LIB
setting to @INC have already executed prior to my PerlSetEnv statement?
If so, that would certainly limit the usefulness of PerlSetEnv for that
purpose. Maybe some note should be made in the docs. Or can someone
confirm that it works for them?
Re: Why isn't PerlSetEnv working for me?
Chris Winters wrote: * Keith G. Murphy ([EMAIL PROTECTED]) [000926 18:43]: I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux. I have the following lines towards the end of my httpd.conf: PerlSetEnv PERL5LIB /usr/local/MyPerl/lib PerlRequire startup.pl Include perllocs.conf However, upon system startup, my startup.pl fails because it can't find a particular module in the @INC list. If I start Apache from the command line, it works. This is undoubtedly because PERL5LIB is set up in my /etc/profile, to the same path. I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just doesn't work. Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But why? There's another workaround: in httpd.conf: Perl use lib qw( /usr/local/MyPerl/lib ); /Perl Pretty painless :) That's a great workaround (from both Chrises), that I will use. :-) Thanks.
Why isn't PerlSetEnv working for me?
I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux. I have the following lines towards the end of my httpd.conf: PerlSetEnv PERL5LIB /usr/local/MyPerl/lib PerlRequire startup.pl Include perllocs.conf However, upon system startup, my startup.pl fails because it can't find a particular module in the @INC list. If I start Apache from the command line, it works. This is undoubtedly because PERL5LIB is set up in my /etc/profile, to the same path. I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just doesn't work. Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But why?
Re: Question about $sth-finish;
Matt Sergeant wrote:
On Tue, 15 Aug 2000, Vladislav Safronov wrote:
Hi,
Could you have a look at the lines and answer the question ..
---
sub foo {
my $dbh = shift;
my $sql = ...
my $sth = $dbh-prepare($sql);
$sth-execute;
$sth-finish;
}
===
Do I always need to call $sth-finish? Wouldn't it be automaticly called
when
sub foo ends (when my variable $sth get destroyed)?
$sth doesn't always get destroyed when foo ends (due to a bug in all
perls).
(Boggle) Really? 'My' variables going out of scope don't always get
freed up? Or is this strictly an object thing with DESTROY?
Re: Why do variables not reinitialize when script changed?
Stas Bekman wrote:
I think you confuse,
something. When the script is recompiled all the variables belonging to
the package decalared by Apache::Registry or similar are getting reset. If
you require/use() some modules that declare packages and have global
variables -- these won't be reset unless reloaded or initialized in your
code.
OK, we've lost my original question here, but what I was saying was
this:
I have a script that is in Apache::Registry. (It's showing up in
"Compiled Registry Scripts" in perl-status).
The global variables are *not* getting set on recompilation. Are you
saying they should?
*You* have straightened me out, on the other hand.
So, lessee, BEGIN { somevar=somevalue; } ought to work for a variable I
want reinitialized at compilation only...
Not if you are talking about the scripts running under Apache::Registry
and friends, please read the guide.
http://perl.apache.org/guide/porting.html#BEGIN_blocks
Stas, what are you talking about? Your own guide says:
"BEGIN blocks in Apache::Registry scripts will be executed, as above
plus:
...
An additional time, once per child process, each time the script file
changes on disk. "
I.e., at compilation. And that is what I'm seeing, and it's the
behavior I want.
I think you are confused about what I am saying. Probably working too
much on the template guide... :-)
Re: Feature sets [was Re: Templating System]
Ron Pero wrote: [cut] * Place the templating systems into a spectrum of categories, from simplest to most complex/developed. It would look approximately like this (not attempting to be complete): -Level one, simplest * Simple tag/anchor replacement * Embedded code evaluation -Level two, complete templating, but templating only * HTML::Template * Template Toolkit * HTML - Tree (??) -Level three, templating plus (added features such as session management, database integration, etc.) * Apache::ASP * Embperl * HTML::Mason * AxKit Perhaps the other dimension could be whether it is based on browsing a page that calls Perl, or invoking a Perl script that brings in a page. Then you'd have a nice 2D grid that I would think would impart a lot of information at a glance. Not that there aren't products that would go into more than one cell. Another thing to note would be whether the product is useful for generating static pages, like Template Toolkit, and (I'm sure) others.
Re: Why do variables not reinitialize when script changed?
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
Since the interpreter does not go away when a script is recompiled, neither
does the stash or any of the items contained within it. Some programmers
are probably using this as a feature, and therefore it is unlikely that it
will change.
This is really standard perl stuff and it has nothing to do with
Apache::Registry in particular. It is just something the average perl
programmer does not come across since we usually load the interpreter, load
a program, run the program, exit the interpreter.
check out:
http://thingy.kcilink.com/modperlguide/porting/Global_Variables_Persistence.html
Thanks for the info and the link.
One note though. The info in the link really doesn't pertain to my
specific question:
"global variables persist inside the same process from request to
request"
I knew that; I was surprised that they did even on a recompilation of
the script, which the link info doesn't really refer to.
*You* have straightened me out, on the other hand.
So, lessee, BEGIN { somevar=somevalue; } ought to work for a variable I
want reinitialized at compilation only...
Yep, works. Thanks.
Why do variables not reinitialize when script changed?
This is probably a very basic question, understood by everyone but... Why, when I change a script loaded under Apache::Registry, and the script (verifiably) reloads, do global variables not reinitialize? I'm running Apache 1.3.9, mod_perl 1.21 on a Debian GNU/Linux system. Am I the only one that finds it odd that the variables hang around unchanged when the script that they pertain to is recompiled? Perhaps this is stated or implied in the documentation; I didn't see it.
Re: Templating System
"Randal L. Schwartz" wrote: "Jacob" == Jacob Davies [EMAIL PROTECTED] writes: Jacob Now as to ampersands used to separate form fields, like: Jacob A HREF="/somehandler?email=jacob%40sfinteractive.comname=Jacob" Jacob do you mean that it should be: Jacob A HREF="/somehandler?email=jacob%40sfinteractive.comamp;name=Jacob" Jacob instead? That second one looks better now that I look at it, Jacob but I confess that I invariably use the first one. Then you are wrong. :) You need to have amp; in there, so that the browser can turn it back from amp; to before sending the URL back up to your server (or whichever server comes along). Are there any browsers that do not actually handle the naked '' correctly? I confess that I also missed this, though I do understand the reason: the first one's invalid HTML. It just seems to always work.
Re: Guide search engine (was Re: multiple copies of a module)
Jeremy Howard wrote: I'm glad you brought this up again. Since I mentioned I'd be happy to host such a thing, and asked for suggestions, I've got a total of one (from Stas--thanks!). That suggestion was to use ht://dig http://www.htdig.org/. Has anyone got a search engine up and running that they're happy with? Stas has made the good point that it needs to be able to hilight found words, since the pages are quite large. If anyone has a chance to do a bit of research about (free) search engines, I'd really appreciate it if you could let me know what you find out. It'd be nice publicity if it was mod_perl based, I guess, but it doesn't really matter. I know this is absolute anathema, considering you guys are developers, but... Have you looked at www.atomz.com, at least as a temporary solution? (A free service for sites with fewer than 500 pages). Basically, the search brings up their page, but you can customize it to look just like one of yours. It truly is fast (as hell) and flexible, and it does highlight found words. Even does soundalikes in the absence of other matches. The result page will show their logo, though, but it's rather unobtrusive. (The biggest drawback, as a long-term solution, is that if you change the look of your pages, you have one more maintenance chore to do, in that you have to go over to atomz.com and change your result page there as well). O'Reilly uses it, if that helps! :-) Try this: http://search.atomz.com/search/?sp-a=0002078e-spsp-q=cgisp-k=Books (Looks for O'Reilly books pages containing 'cgi'). Yeah, I know, I'd rather roll my own, too, given time...
Re: talking about cookies (was: session something...)
"Jeffrey W. Baker" wrote: On Thu, 11 May 2000, Marc Slemko wrote: In reality, IE's recently publicized hole (which I reported to them, in a slightly modified form, months ago but they didn't see fit to release a patch...) doesn't change much. Hotmail? Yahoo mail? amazon.com? etc. Your cookies for all those sites are vulnerable anyway due to the "cross site scripting" issue. This particular hole in IE doesn't change things too much. Sure, there may be the rare site that isn't vulnerable to cross site scripting. But that is the very rare site, and most sites that think they aren't vulnerable are. Cookies are not secure and will never be secure. I have said it before and will say it again many times before I die. Unfortunately, it isn't as simple as saying "well, don't use cookies". There isn't much in the way of alternatives for a lot of things... Cross-site scripting attacks are hard for most people to wrap their minds around. There are a zillion sites that are vulnerable, mainly because they parrot back to the user whatever they submitted without doing any validation or HTML/URL escaping. Then there are browser bugs that don't treat excaped character properly. Sigh. Whether we're talking about the IE bug, or cross-site scripting issues, wouldn't the whole thing be solved by users turning *off* scripting and leaving the cookies *on*? I.e., in what ways are cookies not safe if scripting is turned off? What great functionality is lost if users turn off their scripting? Of course, this may be an abstract question in terms of programming, if users *do* insist on enabling scripting. I do notice that both Microsoft and CERT, in their different ways, recommend that folks turn off scripting for best protection against cross-site scripting attacks: http://www.cert.org/advisories/CA-2000-02.html http://www.microsoft.com/technet/security/crsstQS.asp So maybe some will get the message. Though making ridiculous recommendations like avoiding "promiscuous browsing" (CERT's words) doesn't help. And MS's recommendation simply eliminates E-mail-based attacks using their product (Outlook), while leaving others exposed. They make it ridiculously hard to turn off scripting, then show you how to do it only in a limited way. But it does seem like not even MS is saying "Don't accept cookies". Though they're still pretty quiet on the latest IE hole.
Re: OT: Re: Most nonesense I've ever read about mod_perl
Frank Mayhar wrote: Matt Sergeant wrote: On Sun, 7 May 2000, Frank Mayhar wrote: Perl does have some good constructs for Web work, too. I've been writing a webstore and some stuff is really convenient that would be inconvenient in C. On the other hand, there's some stuff that I just wouldn't use Perl for, like, say, a system daemon, and there's other stuff that I _can't_ use it for, like in the kernel. Do a web search for perlfs - yes someone really did embed perl into the Linux kernel ;-) Kill them. Kill them now. -- Don't forget the wooden stake through their hearts. But, given that Perl has such odd but useful syntax, I've always wanted to see core Perl in *firmware*. Think how mod_perl could fly! :-) But then, I enjoyed the C64 with its embedded Basic. I liked it more when I put that Comal cartridge in there. Yeah, kill me. Kill me now.
Re: oracle : The lowdown
David Harris wrote: Jeff Warner wrote: We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and and Apache::DBI. Works great, once it is all setup. Our overall processing is faster with Oracle too. The lack of transactions and views put an immediate end of mySQL once we got into the details of my project. Oracle is overkill for smaller task but you don't have to worry about outgrowing it. What about PostgreSQL (www.postgresql.org)? It looks like it has transaction management (commit, rollback) with the whole concurrency control thing. I don't know if has views. I've got a small project that I am figuring on using PostgreSQL for, so I'm curious to hear what people might have to say about it. Another option to look at is Solid (www.solidtech.com). They just quoted me their Solid Embedded Server (their name for a database server) for $2,000 per CPU. I used their database server a few years ago and it was very nice. Back then it cost only $200, too... :-) Has anyone tried this (especially on other distributions/kernel/libc versions): http://www.interbase.com/downloads/summaries/19.html I'd be most interested in your experiences. Of course, InterBase is going open-source, soon. :-)
Re: Seg fault on fork w/ PerlModule
Tony Demark wrote: I have compiled the following: Apache 1.3.9 mod_perl 1.21 (PERL_AUTHEN PERL_LOG PERL_STACKED_HANDLERS) [cut] When starting an httpd process with a 'PerlModule' defined in the conf file, the process will seg fault when it attempts to fork: [cut] It is well known now that there is a problem with mod_perl as a DSO with these versions. Have you tried statically linking mod_perl into Apache? There's been a fair amount of discussion about all this, actually.
OT: Re: mod-perl logo
Chris Thompson wrote: On Mon, Nov 01, 1999 at 04:42:50PM -0400, Neil Kandalgaonkar wrote: Joshua Chamas [EMAIL PROTECTED] wrote: That said, they do allow non-profits and others to use the camel, e.g. the Perl Mongers. It's not evil, they're just trying to protect a trademark which they built. AFAIK no one associated a camel w/perl before the ORA books. There's a slightly different reason that you are all missing. It's not that they WANT to defend their trademark, it's that they HAVE to defend their trademark, or they lose it. As I recall under US trademark law, if I can prove that you knew of a use of your trademark and did nothing, The courts can say that you werent defending it, and take it away. [cut] Just goes to show, in the US if you dont vigorously defend your rights to any registered or implicit trademark, you can lose it. Trademark law is probably designed to avoid the very kind of situation that is going on with Unisys and GIFs. Unfortunately, that's a *patent*.
