We use Apache/mod_perl 2 and occasionally get a child httpd process that spins
out of control, either consuming ever-increasing amounts of memory or max cpu.
Usually due to an infinite loop or other bug in a specific part of the site -
this sort of thing happens.
I would like to monitor for suc
We use Mason 1.x inside a custom web framework (which I've recently gotten
permission to release open-source), under mod_perl/Apache 2. Working on a
transition to Plack and Mason 2, but we've already integrated the superior
stack traces and debug console from Plack middleware.
On Jun 15, 2011,
Thanks André. I haven't touched the site in a while but it's due for an
overhaul (and conversion to Mason 2) so will hopefully fix things then.
On Feb 24, 2011, at 12:56 PM, André Warnier wrote:
> This being said, I would like to report a small bug, I believe more of the
> web server than Mason
ote:
> oops is there any big player using Mason these days?
>
> On Tue, Feb 22, 2011 at 2:24 AM, Perrin Harkins wrote:
>> In case any of you Mason users on the mod_perl list aren't on the Mason
>> list...
>>
>> - Perrin
>>
>> -- Forward
rin Harkins wrote:
>>> In case any of you Mason users on the mod_perl list aren't on the Mason
>>> list...
>>>
>>> - Perrin
>>>
>>> -- Forwarded message --
>>> From: Jonathan Swartz
>>> Date: Mon, Feb
On Feb 22, 2011, at 6:55 AM, Phil Carmody wrote:
> --- On Tue, 2/22/11, Jonathan Swartz wrote:
>> I'm pleased to
>> announce Mason 2, the first major version of Mason in ten
>> years:
>>
>>http://search.cpan.org/perldoc?Mason
>>
>> Mason
I'm pleased to announce Mason 2, the first major version of Mason in ten years:
http://search.cpan.org/perldoc?Mason
Mason is a templating framework for generating web pages and other dynamic
content. Mason 2 has been rearchitected and reimplemented from the ground up,
to take advantage of m
On May 27, 2010, at 1:04 PM, Perrin Harkins wrote:
On Thu, May 27, 2010 at 11:11 AM, Michael Schout
wrote:
My solution involved forking off a watcher process when the server
starts up.
Wouldn't it be simpler to start a separate daemon for this? You could
launch it from apachectl if you do
On Jan 27, 2010, at 2:45 PM, Perrin Harkins wrote:
On Tue, Jan 26, 2010 at 7:42 PM, Jonathan Swartz
wrote:
On our site we create a new CGI::Session object at the beginning of
the
request, so that it can be used anywhere in the web code.
However, sessions are rarely written to, so at the
This never got a response. Which surprises me, since I think it is a
legitimate and nasty bug.
So is the silence because
1) people don't think it's really a bug
2) people glazed over while reading the description
3) ??
Thanks :)
Jon
On Jan 8, 2010, at 6:15 AM, Jonathan Swartz w
On our site we create a new CGI::Session object at the beginning of
the request, so that it can be used anywhere in the web code.
However, sessions are rarely written to, so at the end of the request
I'd like to avoid actually writing out a new session to backing store
unless a param actual
(A continuation of:
http://marc.info/?l=apache-modperl&m=117507879929572&w=2
http://marc.info/?l=apache-modperl&m=119072925228529&w=2
)
I've just spent many frustrating days debugging a situation that
turned out to be caused by mod_perl's closing of file descriptor 1
(STDOUT).
Here's the re
Server::Control allows you to control servers ala apachectl, but with
better diagnostics and many more features. It includes both a drop-in
replacement for apachectl (”apachectlp”) and an OO interface.
Though it was designed with Apache in mind, there are also subclasses
for HTTP::Server::S
On Oct 2, 2009, at 3:25 PM, Perrin Harkins wrote:
On Fri, Oct 2, 2009 at 5:54 PM, Jonathan Swartz
wrote:
Ok, one more question. Disregarding graceful for the moment - is HUP
completely reliable with mod_perl at this point, or is there still
a reason
(as there once supposedly was) to do a
On Sep 25, 2009, at 10:48 AM, Clinton Gormley wrote:
If I don't ever plan to use graceful restarts, and I believe that
smaller restart times are an unqualified Good, is there any reason
why
I shouldn't ALWAYS use a script like the above? And is there any way
to avoid PerlModule modules from
Nope, I still get the error in the logs. It just takes a few seconds
to show up.
On Sep 25, 2009, at 11:20 AM, Clinton Gormley wrote:
Hm. No compile errors would be bad. But I put an error in one of my
modules (that only gets loaded the second time) and started apache,
and got error log out
There's only one small gotcha that I've found, and that occurs in this
situation:
- apache isn't running
- you do : apachectl restart
- there is a compile time bug, and apache dies
The gotcha is that you don't get any STDERR or log output in this
situation. However, you're only ever likely to
I was looking into why our server's restarts take so long, and I
finally remembered that Apache runs its initialization step twice on
startup (http://tinyurl.com/krr25). This means that my startup.pl is
loaded twice, along with any modules that it loads.
So I moved startup.pl to startup_rea
On Sep 11, 2009, at 3:53 PM, Fred Moyer wrote:
On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz
wrote:
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz
wrote:
It seems like it's available separately in Apache-Reload
distribution:
http://cpan.uwinnipeg.ca/dist/Apache-Reload
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz
wrote:
It seems like it's available separately in Apache-Reload
distribution:
http://cpan.uwinnipeg.ca/dist/Apache-Reload
But it's already pretty much a straw-man option for me. :)
Problem: some modules fail to reload properly.
ck in as dependencies?
On Sep 11, 2009, at 2:52 PM, Perrin Harkins wrote:
On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz
wrote:
This is the nicest solution I've seen so far. The only problem I
can see is
its performance - each potentially-changing module has to be loaded
on eac
On Sep 11, 2009, at 2:52 PM, Perrin Harkins wrote:
On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz
wrote:
This is the nicest solution I've seen so far. The only problem I
can see is
its performance - each potentially-changing module has to be loaded
on each
request. **
How long
as of mod_perl-2.0.4,
Apache2::Reload is gone (so you can remove that from your list of
options).
--
Devin
On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote:
I'm thinking about an improved solution to recognizing module changes
in a running server, without restarting the server.
These
I'm thinking about an improved solution to recognizing module changes
in a running server, without restarting the server.
These are the solutions I know about:
1) Apache2::Reload / Module::Reload
These check whether modules have changed on each request, and if so,
clear their symbols and re
> We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},
> $ENV{SERVER_PORT}, $r->server->port and the like to generate
external
> redirects.
>
If these are really external redirects, they must happen through a
"Location:" response header, no ?
In that case, what about leaving your code a
We've got a bunch of legacy code that uses $ENV{SCRIPT_URI},
$ENV{SERVER_PORT}, $r->server->port and the like to generate external
redirects.
This has worked fine til now, but now we are moving to a system where
our external port != our internal port - the load balancer is going to
forwar
I'm running into the problem using Linux::Smaps on RHEL with an Apache
server on port 80. Namely, that the httpd child doesn't have
permissions to look at the smaps file.
Linux::Smaps: Cannot open /proc/20074/smaps: Permission denied
or
Linux::Smaps: Cannot open /proc/self/smaps:
Yup, I'm trying to figure out a way to integrate generation of conf
files, since that's another common activity, I'm sure.
Ok, I'll put it out there.
Jon
On Jun 5, 2009, at 3:18 PM, Perrin Harkins wrote:
On Fri, Jun 5, 2009 at 5:21 PM, Jonathan Swartz
wrote:
Over the
httpd, obviously
I'm guessing that my code, with subclassing, could work equally well
for apache, lighttpd, and HTTP::Server::Simple.
Jon
On Jun 5, 2009, at 2:21 PM, Jonathan Swartz wrote:
Over the years I've developed (as I'm sure many have :)) a small
home-grown replacement fo
Over the years I've developed (as I'm sure many have :)) a small home-
grown replacement for apachectl, to make start/stop/restart easier.
It's in library form, and among other things it
* detects whether the server is actually running, by contacting the port
* waits to make sure the server st
We want to periodically analyze our apache error logs, and send out
email reports with summaries of new errors that have occurred since
the last report. Ideally, similar errors would be combined into
groups, and reported in order of frequency.
This seems like a common task (something I've w
I'm wondering if anyone uses Apache's graceful stop feature (http://
httpd.apache.org/docs/2.2/stopping.html#gracefulstop) with mod_perl
servers.
The mod_perl guide section on starting and stopping (http://
perl.apache.org/docs/general/control/
control.html#Safe_Code_Updates_on_a_Live_Produc
> On Thu, 2003-11-13 at 16:47, Jonathan Swartz wrote:
> > So the default MySQL driver does locking just like Apache::Session, and
> > there's no built-in way to turn it locking. So it's possible that the
same
> > locking problems that plague Apache::Session would h
> On Thu, 2003-11-13 at 15:18, Jonathan Swartz wrote:
> > Interesting! I'll take a look. Have you seen any comparisons of features
> > anywhere?
>
> No, I don't think anyone has written up a comparison.
Well, at first glance it looks promising - lots of documenta
> > > The latest Apache::Session on CPAN is version 1.54, released in
October
> > 2001.
> >
> > Perhaps this answers my previous question. :)
>
> Yes, it is far from actively maintained. I've been considering
> recommending that people use CGI::Session instead, since it is better
> documented and
Perrin Harkins writes:
> Sorry if I came off overly critical. Many people have had problems
> trying to use Mason with Apache::Session because of that article. This
> is why on the Mason website the link to that article describes it as
> outdated and steers people to newer documentation. (It pr
36 matches
Mail list logo
