FAQ
Due to the way FastCGI does its business, when running as an "external"
FastCGI, the perl interpreter and the Catalyst app are initialized before the
FCGI process manager does its forking. Since modern versions of Perl seed
rand() "eagerly" on startup, this leads to all of the FastCGI children
inheriting the same RNG state, and very nonrandom behavior (such as CAPTCHAs
that appear to get "stuck").

I've thought over the problem and decided that the only appropriate place for
a fix is in Engine::FastCGI. A srand anyplace else (including the app code)
would run either too early (not solving the "shared state" problem) or too
late (re-seeding on every request is Bad.)

Attached is a patch that does an srand in each child immediately after
invoking pm_manage, if we are running our own process manager. I can't think
at the moment how to write a test for it, but a behavior test shows that it
completely solved the randomness problem on my end, and I ran an instrumented
version to make sure that it's not srand'ing more than once per child -- it's
not. Patch applies against Catalyst-Runtime/5.80/trunk and
Catalyst-Runtime/5.70/trunk (with negligible fuzz).

Index: lib/Catalyst/Engine/FastCGI.pm
===================================================================
--- lib/Catalyst/Engine/FastCGI.pm (revision 9173)
+++ lib/Catalyst/Engine/FastCGI.pm (working copy)
@@ -130,6 +130,8 @@
$self->daemon_detach() if $options->{detach};

$proc_manager->pm_manage();
+ # Give each child its own RNG state.
+ srand;
}
elsif ( $options->{detach} ) {
$self->daemon_detach();

Search Discussions

  • Florian Ragwitz at Feb 3, 2009 at 10:39 am

    On Mon, Feb 02, 2009 at 05:09:21PM -0600, Andrew Rodland wrote:
    Attached is a patch that does an srand in each child immediately after
    invoking pm_manage, if we are running our own process manager.
    applied to 5.80/trunk as r9178.


    --
    BOFH excuse #147:
    Party-bug in the Aloha protocol.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: Digital signature
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090203/92f6c5d5/attachment.pgp
  • Jonathan Rockway at Feb 3, 2009 at 5:45 pm

    * On Mon, Feb 02 2009, Andrew Rodland wrote:
    Due to the way FastCGI does its business, when running as an "external"
    FastCGI, the perl interpreter and the Catalyst app are initialized before the
    FCGI process manager does its forking. Since modern versions of Perl seed
    rand() "eagerly" on startup, this leads to all of the FastCGI children
    inheriting the same RNG state, and very nonrandom behavior (such as CAPTCHAs
    that appear to get "stuck").

    I've thought over the problem and decided that the only appropriate place for
    a fix is in Engine::FastCGI. A srand anyplace else (including the app code)
    would run either too early (not solving the "shared state" problem) or too
    late (re-seeding on every request is Bad.)
    Wait, is there a reason why we can't do this in FCGI::ProcManager
    instead? This is something that affects everyone using FCGI, not just
    Catalyst.

    --
    print just => another => perl => hacker => if $,=$"
  • Andrew Rodland at Feb 3, 2009 at 6:47 pm

    On Tuesday 03 February 2009 11:45:07 am Jonathan Rockway wrote:
    * On Mon, Feb 02 2009, Andrew Rodland wrote:
    I've thought over the problem and decided that the only appropriate place
    for a fix is in Engine::FastCGI. A srand anyplace else (including the app
    code) would run either too early (not solving the "shared state" problem)
    or too late (re-seeding on every request is Bad.)
    Wait, is there a reason why we can't do this in FCGI::ProcManager
    instead? This is something that affects everyone using FCGI, not just
    Catalyst.
    A reasonable question. I'll see if I can get gbjk's thoughts on the matter.

    Andrew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedFeb 2, '09 at 11:09p
activeFeb 3, '09 at 6:47p
posts4
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase