Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz tests fine on my system. +1 --Geoff
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue, Apr 15, 2008 at 8:51 AM, Mark Blackman [EMAIL PROTECTED] wrote: While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I've been using fork, mod_perl, and $$ for years without a single problem. Did you have some trouble that sent you looking for this module? - Perrin
reinitializing Perl's notion of $$ in mod_perl
While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I'd be grateful to understand mod_perl's response to Perl's pid caching is, given that forking *will* happen in the mod_perl environment. - Mark
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 13:59, Perrin Harkins wrote: On Tue, Apr 15, 2008 at 8:51 AM, Mark Blackman [EMAIL PROTECTED] wrote: While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I've been using fork, mod_perl, and $$ for years without a single problem. Did you have some trouble that sent you looking for this module? See http://www.jsw4.net/info/listserv_archives/mod_perl/07-wk25/ msg2.html and http://www.issociate.de/board/post/445529/ Process_ID_when_called_from_PerlChildInitHandler.html And now I'm having trouble getting sense out of Apache::DProf because $$ is wrong (and it's dumping all the child's output into the parent's tmon.out) My assumption is that perl caches the PID on startup and only reinitializes on perl fork(), thus in the embedded case a fork() outside the perl API doesn't reinitialize $$ at least for some cases. I'd love someone to explain why that's not the whole story, as I'm sure it's not as this problem is clearly not global to all mod_perl users. - Mark
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue, Apr 15, 2008 at 9:05 AM, Mark Blackman [EMAIL PROTECTED] wrote: My assumption is that perl caches the PID on startup and only reinitializes on perl fork(), thus in the embedded case a fork() outside the perl API doesn't reinitialize $$ at least for some cases. It must be a mod_perl 2/apache 2 issue. I've never seen this happen with mp1 or with perl programs that use fork(). - Perrin
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 14:15, Perrin Harkins wrote:
On Tue, Apr 15, 2008 at 9:05 AM, Mark Blackman [EMAIL PROTECTED]
wrote:
My assumption is that perl caches the PID on startup and
only reinitializes on perl fork(), thus in the embedded case
a fork() outside the perl API doesn't reinitialize $$ at least
for some cases.
It must be a mod_perl 2/apache 2 issue. I've never seen this happen
with mp1 or with perl programs that use fork().
well perl fork is clearly an obvious cache invalidation event.
in mod_perl 2.0.3 mod_perl.c, I can see..
static void modperl_hook_child_init(apr_pool_t *p, server_rec *s){
modperl_perl_init_ids_server(s);
and modperl_perl_init_ids_server() eventually calls
modperl_perl_init_ids() which itself eventually does a
sv_setiv(GvSV(gv_fetchpv($, TRUE, SVt_PV)), ids-pid);
where ids-pid should contain the result of a recent getpid.
*However* I note that in the main perl code perl.c $$ is set
to be a readonly variable so I suspect, this code *might* need
to to look more like.
if ((tmpgv = gv_fetchpv($,TRUE, SVt_PV))) {
SvREADONLY_off(GvSV(tmpgv));
sv_setiv(GvSV(tmpgv), ids-pid);
SvREADONLY_on(GvSV(tmpgv));
}
- Mark
- Perrin
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue 15 Apr 2008, Mark Blackman wrote: While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I'd be grateful to understand mod_perl's response to Perl's pid caching is, given that forking *will* happen in the mod_perl environment. There was/is a problem in mp1 that it did/does not reinitialize $$ and getppid(). With mp2 I haven't seen this before. But I have heard of pid caching inside C libraries. Maybe if you compile modperl with another lib than apache. Then the apache lib caches and reinitializes the pid in one place but modperl uses the other lib. If you run linux you can have a look at /proc/PID/maps or /proc/pid/smaps. At least shared libs are shown there. Torsten -- Need professional mod_perl support? Just ask me: [EMAIL PROTECTED]
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 16:00, Torsten Foertsch wrote: On Tue 15 Apr 2008, Mark Blackman wrote: While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I'd be grateful to understand mod_perl's response to Perl's pid caching is, given that forking *will* happen in the mod_perl environment. There was/is a problem in mp1 that it did/does not reinitialize $$ and getppid(). With mp2 I haven't seen this before. But I have heard of pid caching inside C libraries. Maybe if you compile modperl with another lib than apache. Then the apache lib caches and reinitializes the pid in one place but modperl uses the other lib. Well this is a solaris 10 system and so it's just the straight /lib/ libc.so.1 in both cases. I'd be surprised if this is the issue. I suppose I could knock up a quick bit of C to test it. - Mark If you run linux you can have a look at /proc/PID/maps or /proc/pid/ smaps. At least shared libs are shown there. Torsten -- Need professional mod_perl support? Just ask me: [EMAIL PROTECTED]
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 16:24, Mark Blackman wrote:
On 15 Apr 2008, at 16:00, Torsten Foertsch wrote:
On Tue 15 Apr 2008, Mark Blackman wrote:
While I did find Torsten Förtsch's very useful Perl::AfterFork
module, surely the
mod_perl code must be doing something like this itself, no?
I'd be grateful to understand mod_perl's response to Perl's
pid caching is, given that forking *will* happen in the mod_perl
environment.
There was/is a problem in mp1 that it did/does not reinitialize $$
and
getppid(). With mp2 I haven't seen this before.
But I have heard of pid caching inside C libraries. Maybe if you
compile
modperl with another lib than apache. Then the apache lib caches and
reinitializes the pid in one place but modperl uses the other lib.
Well this is a solaris 10 system and so it's just the straight /lib/
libc.so.1
in both cases.
I'd be surprised if this is the issue. I suppose I could knock up a
quick bit of
C to test it.
#include stdio.h
#include stdlib.h
#include sys/types.h
#include unistd.h
int main(int argc, char *argv){
fork();
printf(my pid is %d\n,getpid());
}
which appears to demonstrate no caching of the pid of the system in
question.
- Mark
- Mark
If you run linux you can have a look at /proc/PID/maps or /proc/
pid/smaps. At
least shared libs are shown there.
Torsten
--
Need professional mod_perl support?
Just ask me: [EMAIL PROTECTED]
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue, Apr 15, 2008 at 11:00 AM, Torsten Foertsch [EMAIL PROTECTED] wrote: There was/is a problem in mp1 that it did/does not reinitialize $$ and getppid(). Under what circumstances? I use $$ all the time and have never seen any sort of caching behavior from it. I use Linux. - Perrin
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue 15 Apr 2008, Mark Blackman wrote:
int main(int argc, char *argv){
fork();
printf(my pid is %d\n,getpid());
}
Please use the fork-syscall here not the C function.
Torsten
--
Need professional mod_perl support?
Just ask me: [EMAIL PROTECTED]
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 17:27, Torsten Foertsch wrote:
On Tue 15 Apr 2008, Mark Blackman wrote:
int main(int argc, char *argv){
fork();
printf(my pid is %d\n,getpid());
}
Please use the fork-syscall here not the C function.
i'm trying to test the C-library behaviour though?
in my case, i got two different numbers, so that tells me there's
no caching surely.
- Mark
Torsten
--
Need professional mod_perl support?
Just ask me: [EMAIL PROTECTED]
Accessing CSS,JS and other files
Hi everyone... I tried searching the forums, but got few clues..yet I don't have my doubts clarified. Hence posting. I am running Apache/2.2.6 (Unix) with mod_perl/2.0.3 Perl/v5.8.8 Recently I have started developing pages using mod_perl and when I tried to link the CSS file or Javascript file, mod_perl is trying to execute them (treating them as perl files). This is annoying. When I searched thru' forums, came to know abt the Files section, which I can use. But still after studying the documentation, I could not write a proper Files section. Can some one help in that? This is my conf for mod_perl. #Typical for Modperl::Registry Alias /perl/ /var/www/perl/ PerlModule ModPerl::Registry Location /perl SetHandler perl-script PerlHandler ModPerl::Registry Options ExecCGI allow from all PerlSendHeader On /Location Do we need to write Files section before or after Location? Thanks n Regards, Dileep. - With Best regards, Dileep. *** -- View this message in context: http://www.nabble.com/Accessing-CSS%2CJS-and-other-files-tp16703625p16703625.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Best practices for returning 404/file-not-found pages inside and outside of mod_perl
It seems that using CGI, it is too late return a true 404 once the
script is processing the request. It's possible to still send output
that returns page not found text, but the HTTP status code will be 200.
More recently, I learned that with mod_perl, I learned that I can get
the system to return a true 404, so I updated my CGI::Application logic
to do that when possible:
if (exists $ENV{MOD_PERL}) {
$self-header_add( -status = 404 );
return '';
}
else {
return $self-error(title = 'Page not found')
}
However, I don't think I'm doing the ideal think in mod_perl, because it
behaves strangely in some cases. Two specific cases:
If I use GET on the command line, instead of 404, I'll get back this:
500 EOF when chunk header expected
Unless I fallback to HTTP 1.0:
PERL_LWP_USE_HTTP_10=1 GET ...
But for some reason, setting this environment variable was not working
for with Test::WWW::Mechanize.
More troubling is the behavior I see in the browser: The first time I
access the script that would through this 404 in mod_perl, it works.
Then for attempts 2 through 6 return internal server errors complaining
about can't locate modules. Starting on load 7, the pages are returned
reliably with the 404 error. WTF?
( This is with Apache 1.3x and mod_perl 1.x )
The approach of CGI::Application::Dispatch is to also return the 404
code, but also returns the body content along with it. In my case, I'm
hoping to trigger the internal ErrorDocument 404 page instead of
re-inventingt that wheel.
What am I missing?
Thanks!
Mark
Re: reinitializing Perl's notion of $$ in mod_perl
On Tue, Apr 15, 2008 at 8:28 AM, Mark Blackman [EMAIL PROTECTED] wrote:
modperl_perl_init_ids() which itself eventually does a
sv_setiv(GvSV(gv_fetchpv($, TRUE, SVt_PV)), ids-pid);
where ids-pid should contain the result of a recent getpid.
*However* I note that in the main perl code perl.c $$ is set
to be a readonly variable so I suspect, this code *might* need
to to look more like.
if ((tmpgv = gv_fetchpv($,TRUE, SVt_PV))) {
SvREADONLY_off(GvSV(tmpgv));
sv_setiv(GvSV(tmpgv), ids-pid);
SvREADONLY_on(GvSV(tmpgv));
}
- Mark
one could replace the provided ${'$'} with a magic one that doesn't cache
I could write one with TIESCALAR and Inline::C but I think there are better
ways to do it and I don't want to clog up modperl list with first-draft code --
just ignore the cached PID by redefining $$'s FETCH accessor to wrap
get_pid() directly. So what if it will take another millisecond.
Re: Best practices for returning 404/file-not-found pages inside and outside of mod_perl
On Tue, Apr 15, 2008 at 2:19 PM, Mark Stosberg [EMAIL PROTECTED] wrote: return a true 404 Since MP already replaces the Cexit function, it shouldn't be too tricky to abstract 404 and other error codes with by letting exit take arguments -- then you could do what you want with Cexit(STATUS = 404) for instance. I don't know how hard that feature would be to add; adding it to mod-perl might drive similar features added to other CGI systems, for instance the apache project could add a mapping of specific non-zero exit codes from CGI programs to things other than 500 internal server error. Of course, there's always redirecting to a location that really doesn't exist, but that isn't true. Dave the idea guy
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 17:27, Torsten Foertsch wrote:
On Tue 15 Apr 2008, Mark Blackman wrote:
int main(int argc, char *argv){
fork();
printf(my pid is %d\n,getpid());
}
Please use the fork-syscall here not the C function.
Right, the C library will almost certainly use
the fork() call here to invalidate and update the
cache entry. Using syscall(SYS_fork) guarantees
that the C library will not get a chance to update
its cache.
However, I'd be very surprised if any application (including
apache) deliberately used syscall(SYS_fork) over fork()
and so even if it is cached, the cache invalidation
is done at the right time.
- Mark
Torsten
--
Need professional mod_perl support?
Just ask me: [EMAIL PROTECTED]
modperl and syslog, strange behavior
Hi Y'all,
I'm new to mod_perl, please forgive me if this is already well known
info.
I have several different web scripts like:
if($UseLog) {
Sys::Syslog::setlogsock('unix');
openlog($WebScriptName, 'pid', 'daemon');
syslog('info', $WebScriptName starting);
}
...
syslog('info', Message); # Actually buried in a subroutine
...
Originally, if $UseLog was false for an invocation of the script,
the Message would not appear in the syslog.
When I turned on mod_perl, sometimes I found Message appearing,
but under a different script's name.
So: mod_perl is somehow saving the socket state between runs of
webscripts, right?
Is it doing what it is supposed to be doing? Is there anything
wrong with what I am doing?
And most important - is there any other area that has the same or
similar behavior?
Thanks,
j
--
John Gateley [EMAIL PROTECTED]
Re: reinitializing Perl's notion of $$ in mod_perl
On 15 Apr 2008, at 13:51, Mark Blackman wrote: While I did find Torsten Förtsch's very useful Perl::AfterFork module, surely the mod_perl code must be doing something like this itself, no? I'd be grateful to understand mod_perl's response to Perl's pid caching is, given that forking *will* happen in the mod_perl environment. Ok, more investigation suggests we're seeing an ordering problem. mod_perl (2.0.3) does reinitialize $$ in modperl_hook_child_init in mod_perl.c by calling void modperl_perl_init_ids_server(server_rec *s) in modperl_perl.c However, judicious sprinkling of printf statements suggests very strongly that the above code gets called *AFTER* the handler specified in PerlChildInitHandler. Would anyone are to comment why the code above would be done AFTER? The routine names suggest that modperl_hook_child_init() would get called before a PerlChildInitHandler to me, but my logging suggests otherwise. - Mark - Mark
Re: Best practices for returning 404/file-not-found pages inside and outside of mod_perl
On Tue, Apr 15, 2008 at 3:19 PM, Mark Stosberg [EMAIL PROTECTED] wrote: It seems that using CGI, it is too late return a true 404 once the script is processing the request. I thought mod_cgi would handle this, actually. It parses your header output. Apache::Registry has trouble emulating that, as discussed on this list in the past. However, I don't think I'm doing the ideal think in mod_perl, because it behaves strangely in some cases. Two specific cases: If I use GET on the command line, instead of 404, I'll get back this: 500 EOF when chunk header expected You're not using Registry here, right? Is it possible that something is using your status header as a return code from a mod_perl handler? Those don't always match. The best source for examples of how to do this correctly is probably the mod_perl Developer's Cookbook. I don't have mine handy, but that's where I'd like first if you have it. More troubling is the behavior I see in the browser: The first time I access the script that would through this 404 in mod_perl, it works. Then for attempts 2 through 6 return internal server errors complaining about can't locate modules. Starting on load 7, the pages are returned reliably with the 404 error. WTF? I'm not familiar with that one. What's the full text of the error message? In my case, I'm hoping to trigger the internal ErrorDocument 404 page instead of re-inventingt that wheel. I'm not sure you can do that. I know you can set the ErrorDocument for a specific block ($r-custom_response), but I don't think you can just hand off to ErrorDocument because it's tied into the default handler. I don't remember this well, so checking one of the books or the list archive is your best bet. - Perrin
