[mp2] Apache2::Reload missing in FreeBSD ports
Hello guys, I'm wondering if there is any1 using FreeBSD + Apache2 + mp2. In short: there's no Apache2::Reload. I browsed around the web (in particular http://www.mail-archive.com/d...@perl.apache.org/msg12048.html) , and apparently I'm not the only one who noticed it. People mention Apache::Reload, but on my FBSD7.2: 1. Installing p5-Apache-Reload over package (at v0.07) throw out: Can't locate object method dir_config via package Apache2::RequestRec at /usr/local/lib/perl5/site_perl/5.8.8/Apache/Reload.pm line 51. 2. I can't install p5-Apache-Reload over ports, as it will complain it expects Apache 1.3. Any advice will be appreciated. Thanks.
Re: [mp2] Apache2::Reload missing in FreeBSD ports
Foo JH wrote: 2. I can't install p5-Apache-Reload over ports, as it will complain it expects Apache 1.3. This would be actually more of a FreeBSD Ports related issue. I guess you should complain at the port maintainer for the dependencies. Apache-Reload is a bundle and should work with Apache2 as well as with Apache 1.x. See [http://www.freshports.org/www/p5-Apache-Reload/] for the port maintainer. You could, of course, just install Apache::Reload via cpan to solve your issues, or tell your package manager to ignore dependencies and install anyway. Regards, Michiel
Would like mod_perl 1.29 to include more information on fatal errors
Hello, We are running Apache/1.3.37 with mod_perl/1.29. We use the regular mod_perl API to install custom access, authentication, authorization, fixup, content, and logging handlers. Once in a great while we run into random Undefined subroutine XX::Clients::YY::ContentHandler::handler called.\n messages, where XX represents our internal namespace for our packages and YY a specific client. A snippet of typical Apache configuration is something like this for a virtual host: PerlAuthenHandler XX::Account::AuthenHandler PerlAuthzHandlerXX::Account::AuthzHandler Files blah SetHandler perl-script PerlHandler XX::Clients::YY::ContentHandler /Files When we get the undefined subroutine message, it looks like this: [Wed Sep 2 08:43:30 2009] [error] Undefined subroutine XX::Clients::YY::ContentHandler::handler called.\n The user sees a white page when this happens. No error message... but no content either. Usually hitting refresh will bring up the page they wanted, but it's obviously bad to have users experience random empty/white pages. The literal backslash and literal n are both (literally) in the logged message in the error log, which is why I think this error is coming from Perl and is just getting passed through by mod_perl to Apache; nothing is interpreting the line and translating the two characters \ and n into a newline. Usually we can track this down in our QA and production environments to a module that relies on a different module that we failed to use. It works most of the time because some earlier hit caused the Apache process to load one of our custom modules that in-turn use'd the module the later module referenced, so it was in coincidentally in memory the vast majority of the time it was referenced. The problem is when a clean/new Apache process served the faulty module *first*, before serving any other custom content, and then we would get the Undefined subroutine type of message. However, we've checked everything we can think of and we're unable to track down the problem in a particular set of custom modules for a client where this problem keeps happening for a small percentage of the hits. Sometimes the problem will also happen in our development environment, but then it is usually due to a compilation error (like bad syntax) where StatINC tried to load the new version of the module from disk and it failed to compile. When that happens, there is nothing in memory for that module so the handler function is not defined. Once the syntax error is fixed the problem goes away (in our development environment; this cause of the problem is never in our QA or production environments) We've ran out of ideas on why the main handler method--in a module that mod_perl should be loading directly--would generate this message. There are no preceeding error messages that we can attribute this error to. We are hoping if we spat out more information about the request (URI, params, etc) and the state of the process (pid, modules loaded, etc) we might be able to see what is going on and fix the problem. I would like to know if someone has a patch that will dump out more information about the hit, such as the requested URI, any parameters that are passed, what perl modules are in memory, the process ID, or anything at all that might help. I'm rusty on my C and I've never dug into mod_perl guts before, so I'm not sure where to even begin to look at adding the output of information myself on a fatal error (one that prevents a properly handled response). From what I can tell, it seems like mod_perl is taking an error from PERL and passing it directly to Apache's error logging mechanism. I'd like to intercept that call and dump out the extra information as well as the original error. Any guidance on patching/hacking mod_perl 1.29 to have more verbose error messages would be greatly appreciated. -- James Funny quotes: There are 10 types of people in the world. Those who understand binary, and those who don't. -- Unknown A computer once beat me at chess, but it was no match for me at kick boxing. -- Emo Philips
Re: [mp2] Apache2::Reload missing in FreeBSD ports
I run FreeBSD + Apache2 + mp2. CPAN 'test Apache::Reload' yields 'pass'. Subsequent CPAN 'test Apache2::Reload' wants to use the same module, so it says 'Has already been tested successfully'. cmac On Sep 3, 2009, at 3:59 AM, Foo JH wrote: Hello guys, I'm wondering if there is any1 using FreeBSD + Apache2 + mp2. In short: there's no Apache2::Reload. I browsed around the web (in particular http://www.mail-archive.com/ d...@perl.apache.org/msg12048.html) , and apparently I'm not the only one who noticed it. People mention Apache::Reload, but on my FBSD7.2: 1. Installing p5-Apache-Reload over package (at v0.07) throw out: Can't locate object method dir_config via package Apache2::RequestRec at /usr/local/lib/perl5/site_perl/5.8.8/ Apache/Reload.pm line 51. 2. I can't install p5-Apache-Reload over ports, as it will complain it expects Apache 1.3. Any advice will be appreciated. Thanks.
Subprocess still running and spawn_proc_prog() returns immediately
I've got an Apache2 problem with a registry script that runs another perl script in a subprocess. The spawn_proc_prog() returns immediately, though the subprocess is still running, which causes a blocking situation when I try to read the stdout/err causing the script to hang indefinitely. The subprocess script doesn't fork or anything like that, yet spawn_proc_prog() is not waiting for it to exit. Any ideas? Need more info? Thanks, folks. Eric ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: Would like mod_perl 1.29 to include more information on fatal errors
On Thu, Sep 3, 2009 at 11:32 AM, James Olsenjame...@planetolsen.com wrote:
I would like to know if someone has a patch that will dump out more
information about the hit, such as the requested URI, any parameters
that are passed, what perl modules are in memory, the process ID, or
anything at all that might help.
I'm rusty on my C and I've never dug into mod_perl guts before, so I'm
not sure where to even begin to look at adding the output of
information myself on a fatal error (one that prevents a properly
handled response).
You could:
- Make s $SIG{__DIE__} handler
- Wrap your application in an eval {}
The data you want is available from either the standard apache log
formats or perl code in Apache::Status, so there's no need to worry
about writing C here.
- Perrin
RE: Subprocess still running and spawn_proc_prog() returns immediately
BTW, using IPC::Run3 -- which I could do since I didn't have to set env vars or a few other things -- worked just fine. Eric -Original Message- From: Berg, Eric: IT (NYK) Sent: Thursday, September 03, 2009 1:31 PM To: modperl@perl.apache.org Subject: Subprocess still running and spawn_proc_prog() returns immediately I've got an Apache2 problem with a registry script that runs another perl script in a subprocess. The spawn_proc_prog() returns immediately, though the subprocess is still running, which causes a blocking situation when I try to read the stdout/err causing the script to hang indefinitely. The subprocess script doesn't fork or anything like that, yet spawn_proc_prog() is not waiting for it to exit. Any ideas? Need more info? Thanks, folks. Eric ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Error with File::upload
I'm managing uploaded files in a web application and getting the error: [Thu Sep 03 15:18:14 2009] [error] [client 128.196.45.237] Can't chdir to :: No such file or directory at /opt/lampp/lib/perl5/site_perl/ 5.10.0/i686-linux/ModPerl/RegistryCooker.pm line 623.\n, referer: https://www.pharmacy.arizona.edu/avi/edit_av3.pl Examination of the upload directory shows that the file is in fact uploading to the correct place, so I don't know what the issue is. The only html that is processed is : META HTTP-EQUIV=Refresh CONTENT=2; URL=$path/admin.pl Google has been quite uninformative. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
Re: [mp2] Apache2::Reload missing in FreeBSD ports
Thanks Hiro, I wonder: if nobody is to advise otherwise, how will one know out that it is possible to install p5-Apache-Reload with the WITH_MODPERL2=yes option, without digging into the make file? Hiroyuki Hanai wrote: just FYI. I'm wondering if there is any1 using FreeBSD + Apache2 + mp2. In short: there's no Apache2::Reload. With ports-current, you will be able to install Apache2::Reload by: $ cd /usr/ports/www/p5-Apache-Reload $ sudo make WITH_MODPERL2=yes install h.hanai
