Loading ...
Sorry, an error occurred while loading the content.

perl 5.8 safe signals and broken pipes in apache

Expand Messages
  • Jim Albert
    Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a timely manner. I was asked to post a
    Message 1 of 13 , Jun 15, 2004
    • 0 Attachment
      Last week I had a problem where I could not get my
      Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a
      timely manner. I was asked to post a description of this problem and
      solution to this list so that it might be included in future mod_perl
      documentation.

      Feel free to adjust this description as necessary when integrating it
      into the appropriate documentation.

      The Problem:
      Use a PerlFixupHandler to catch when the pipe from browser to httpd
      server has been broken such as when the user presses the browser stop
      button.

      In conf.d/perl.conf
      PerlFixupHandler Apache::SIG2

      where Apache::SIG2.pm is defined in this example as:

      ----------
      package Apache::SIG2;

      # This package adapted by Jim Albert from the original mod_perl1
      # Apache::SIG.pm by Doug MacEachern and Doug Bagley
      # This PerlHandler can be used to prevent httpd children from killing
      # off non-mod-perled CGIs when the user presses the Stop button.

      use strict;
      use Apache::RequestRec;
      use ModPerl::Util;
      use Apache::Const;

      sub handler {
      my $r = shift;
      if (!$r->main) {
      $SIG{PIPE} = \&PIPE;
      }

      return OK;
      }

      sub PIPE {
      my($signal) = @_;
      print STDERR ("User pressed stop button.\n");
      # Kill off the httpd child before it can kill any running CGIs.
      # Or do whatever other cleanup is appropriate.
      CORE::exit();
      }

      1;
      ----------

      With the introduction of perl 5.8.0, this handler no longer works as
      expected because of the introduction of perl safe signals.
      See:
      http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)

      What happens with perl 5.8 and safe signals is that the apache httpd
      child does receive the SIGPIPE, but it is delayed and the perl CGI
      program has already been killed. The httpd child does not act on the
      SIGPIPE until it receives the next httpd request.

      The Solution:
      An Apache server_startup.pl script can be used to turn off perl safe
      signals with the following line:
      $ENV{PERL_SIGNALS} = "unsafe";
      The server_startup.pl script can be included via the following line in
      perl.conf:
      PerlRequire conf/server_startup.pl
      The ability to revert back to "unsafe" signals is available as of perl
      5.8.1.

      --
      Jim Albert



      --
      Report problems: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
    • Eric
      Jim, Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find
      Message 2 of 13 , Jun 15, 2004
      • 0 Attachment
        Jim,

        Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's.

        I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while.

        The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail? I know me and I will manage to mess it up if I can :)

        Below are some examples from the POSIX module, it should work :). I found most of this somewhere when doing research on perl daemons but the child one I added on and I am currently using all of the below, I just did some cutting of other things.

        use POSIX ();
        use POSIX 'WNOHANG';
        use FindBin ();
        use File::Basename ();
        use File::Spec::Functions;

        my $script = File::Basename::basename($0);
        my $SELF = catfile $FindBin::Bin, $script;

        my $sigset = POSIX::SigSet->new();
        my $action = POSIX::SigAction->new('sigHUP_handler',
        $sigset,
        &POSIX::SA_NODEFER);
        my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
        $sigset,
        &POSIX::SA_NODEFER);
        my $action_child = POSIX::SigAction->new('sigCHLD_handler',
        $sigset,
        &POSIX::SA_NODEFER);

        POSIX::sigaction(&POSIX::SIGHUP, $action);
        POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
        POSIX::sigaction(&POSIX::SIGCHLD, $action_child);

        sub sigHUP_handler {
        print "got SIGHUP\n";
        exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
        }
        sub sigALRM_handler {
        print "got ALARM timeout\n";

        }
        sub sigCHLD_handler {
        while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
        }
        }


        ## do your while (1) and fork etc...



        I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application..

        Thanks,

        Eric

        At 02:55 PM 6/15/2004, Jim Albert wrote:
        >Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a timely manner. I was asked to post a description of this problem and solution to this list so that it might be included in future mod_perl documentation.
        >
        >Feel free to adjust this description as necessary when integrating it into the appropriate documentation.
        >
        >The Problem:
        >Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been broken such as when the user presses the browser stop button.
        >
        >In conf.d/perl.conf
        >PerlFixupHandler Apache::SIG2
        >
        >where Apache::SIG2.pm is defined in this example as:
        >
        >----------
        >package Apache::SIG2;
        >
        ># This package adapted by Jim Albert from the original mod_perl1
        ># Apache::SIG.pm by Doug MacEachern and Doug Bagley
        ># This PerlHandler can be used to prevent httpd children from killing
        ># off non-mod-perled CGIs when the user presses the Stop button.
        >
        >use strict;
        >use Apache::RequestRec;
        >use ModPerl::Util;
        >use Apache::Const;
        >
        >sub handler {
        > my $r = shift;
        > if (!$r->main) {
        > $SIG{PIPE} = \&PIPE;
        > }
        >
        > return OK;
        >}
        >
        >sub PIPE {
        > my($signal) = @_;
        > print STDERR ("User pressed stop button.\n");
        > # Kill off the httpd child before it can kill any running CGIs.
        > # Or do whatever other cleanup is appropriate.
        > CORE::exit();
        >}
        >
        >1;
        >----------
        >
        >With the introduction of perl 5.8.0, this handler no longer works as expected because of the introduction of perl safe signals.
        >See:
        >http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
        >
        >What happens with perl 5.8 and safe signals is that the apache httpd child does receive the SIGPIPE, but it is delayed and the perl CGI program has already been killed. The httpd child does not act on the SIGPIPE until it receives the next httpd request.
        >
        >The Solution:
        >An Apache server_startup.pl script can be used to turn off perl safe signals with the following line:
        >$ENV{PERL_SIGNALS} = "unsafe";
        >The server_startup.pl script can be included via the following line in perl.conf:
        >PerlRequire conf/server_startup.pl
        >The ability to revert back to "unsafe" signals is available as of perl 5.8.1.
        >
        >--
        >Jim Albert
        >
        >
        >
        >--
        >Report problems: http://perl.apache.org/bugs/
        >Mail list info: http://perl.apache.org/maillist/modperl.html
        >List etiquette: http://perl.apache.org/maillist/email-etiquette.html


        --
        Report problems: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
      • Jim Albert
        Great! It s always nice to have multiple solutions to a problem. I believe Stas Bekman also pointed to the POSIX sigaction solution when he first pointed me
        Message 3 of 13 , Jun 15, 2004
        • 0 Attachment
          Great! It's always nice to have multiple solutions to a problem. I
          believe Stas Bekman also pointed to the POSIX sigaction solution when he
          first pointed me in the right direction in solving this problem, but
          setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very
          quickly.

          I might give the POSIX sigaction solution a try myself since I too
          wasn't incredibly comfortable with resorting to old signal handling for
          my entire httpd servers. My guess is that your POSIX sigaction solution
          would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which
          is not supported until perl5.8.1.

          Assuming your solution also solves this problem, it should also be
          included in any documentation regarding "safe signals" and apache/mod_perl.

          Eric wrote:

          > Jim,
          >
          > Thank you! This was a big help to me in that I ran into this problem from two directions recently, with a perl daemon and with Apache::SIG.. I did find some info about fixing this for real rather than using unsafe signals. They mostly seemed to point to using the POSIX sigaction methods rather Perl's.
          >
          > I did end up getting my daemon to work without either dying after the first command or spawning endless children that would not die, those were my two choices before :) Only a part of this was related to the signal problem, but it was the hard part for a while.
          >
          > The child signal was what was causing me big problems. I know this is far from a complete answer, but I hope it might send someone off on the right path if they don't want to set the ENV var. I was worried about doing it that way, because what happens a year from now when I upgrade my server and we somehow forget about that little detail? I know me and I will manage to mess it up if I can :)
          >
          > Below are some examples from the POSIX module, it should work :). I found most of this somewhere when doing research on perl daemons but the child one I added on and I am currently using all of the below, I just did some cutting of other things.
          >
          > use POSIX ();
          > use POSIX 'WNOHANG';
          > use FindBin ();
          > use File::Basename ();
          > use File::Spec::Functions;
          >
          > my $script = File::Basename::basename($0);
          > my $SELF = catfile $FindBin::Bin, $script;
          >
          > my $sigset = POSIX::SigSet->new();
          > my $action = POSIX::SigAction->new('sigHUP_handler',
          > $sigset,
          > &POSIX::SA_NODEFER);
          > my $action_alrm = POSIX::SigAction->new('sigALRM_handler',
          > $sigset,
          > &POSIX::SA_NODEFER);
          > my $action_child = POSIX::SigAction->new('sigCHLD_handler',
          > $sigset,
          > &POSIX::SA_NODEFER);
          >
          > POSIX::sigaction(&POSIX::SIGHUP, $action);
          > POSIX::sigaction(&POSIX::SIGALRM, $action_alrm);
          > POSIX::sigaction(&POSIX::SIGCHLD, $action_child);
          >
          > sub sigHUP_handler {
          > print "got SIGHUP\n";
          > exec($SELF, @ARGV) or die "Couldn't restart: $!\n";
          > }
          > sub sigALRM_handler {
          > print "got ALARM timeout\n";
          >
          > }
          > sub sigCHLD_handler {
          > while (my $reaperpid = waitpid(-1,WNOHANG)>0) {
          > }
          > }
          >
          >
          > ## do your while (1) and fork etc...
          >
          >
          >
          > I wish I could paste in my whole daemon thing, but it is too far along with to many things specific to my bosses application..
          >
          > Thanks,
          >
          > Eric
          >
          > At 02:55 PM 6/15/2004, Jim Albert wrote:
          >
          >>Last week I had a problem where I could not get my Apache2/mod_perl2/perl5.8.3 web server to catch a SIGPIPE signal in a timely manner. I was asked to post a description of this problem and solution to this list so that it might be included in future mod_perl documentation.
          >>
          >>Feel free to adjust this description as necessary when integrating it into the appropriate documentation.
          >>
          >>The Problem:
          >>Use a PerlFixupHandler to catch when the pipe from browser to httpd server has been broken such as when the user presses the browser stop button.
          >>
          >>In conf.d/perl.conf
          >>PerlFixupHandler Apache::SIG2
          >>
          >>where Apache::SIG2.pm is defined in this example as:
          >>
          >>----------
          >>package Apache::SIG2;
          >>
          >># This package adapted by Jim Albert from the original mod_perl1
          >># Apache::SIG.pm by Doug MacEachern and Doug Bagley
          >># This PerlHandler can be used to prevent httpd children from killing
          >># off non-mod-perled CGIs when the user presses the Stop button.
          >>
          >>use strict;
          >>use Apache::RequestRec;
          >>use ModPerl::Util;
          >>use Apache::Const;
          >>
          >>sub handler {
          >> my $r = shift;
          >> if (!$r->main) {
          >> $SIG{PIPE} = \&PIPE;
          >> }
          >>
          >> return OK;
          >>}
          >>
          >>sub PIPE {
          >> my($signal) = @_;
          >> print STDERR ("User pressed stop button.\n");
          >> # Kill off the httpd child before it can kill any running CGIs.
          >> # Or do whatever other cleanup is appropriate.
          >> CORE::exit();
          >>}
          >>
          >>1;
          >>----------
          >>
          >>With the introduction of perl 5.8.0, this handler no longer works as expected because of the introduction of perl safe signals.
          >>See:
          >>http://www.perldoc.com/perl5.8.4/pod/perlipc.html#Deferred-Signals-(Safe-Signals)
          >>
          >>What happens with perl 5.8 and safe signals is that the apache httpd child does receive the SIGPIPE, but it is delayed and the perl CGI program has already been killed. The httpd child does not act on the SIGPIPE until it receives the next httpd request.
          >>
          >>The Solution:
          >>An Apache server_startup.pl script can be used to turn off perl safe signals with the following line:
          >>$ENV{PERL_SIGNALS} = "unsafe";
          >>The server_startup.pl script can be included via the following line in perl.conf:
          >>PerlRequire conf/server_startup.pl
          >>The ability to revert back to "unsafe" signals is available as of perl 5.8.1.
          >>
          >>--
          >>Jim Albert
          >>
          >>
          >>
          >>--
          >>Report problems: http://perl.apache.org/bugs/
          >>Mail list info: http://perl.apache.org/maillist/modperl.html
          >>List etiquette: http://perl.apache.org/maillist/email-etiquette.html
          >
          >




          --
          Report problems: http://perl.apache.org/bugs/
          Mail list info: http://perl.apache.org/maillist/modperl.html
          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
        • Eric Frazier
          Hi, Very glad I could be of some help, even though most of this was copy and paste and googling. I was in fact testing this on a FreeBSD server with 5.8.0, the
          Message 4 of 13 , Jun 15, 2004
          • 0 Attachment
            Hi,

            Very glad I could be of some help, even though most of this was copy and paste and googling. I was in fact testing this on a FreeBSD server with 5.8.0, the production server is 5.8.4.

            Eric

            At 03:39 PM 6/15/2004, Jim Albert wrote:
            >Great! It's always nice to have multiple solutions to a problem. I believe Stas Bekman also pointed to the POSIX sigaction solution when he first pointed me in the right direction in solving this problem, but setting $ENV{PERL_SIGNALS} = "unsafe"; got me going with perl 5.8 very quickly.
            >
            >I might give the POSIX sigaction solution a try myself since I too wasn't incredibly comfortable with resorting to old signal handling for my entire httpd servers. My guess is that your POSIX sigaction solution would work with perl5.8.0 unlike the $ENV{PERL_SIGNALS} solution which is not supported until perl5.8.1.
            >
            >Assuming your solution also solves this problem, it should also be included in any documentation regarding "safe signals" and apache/mod_perl.


            --
            Report problems: http://perl.apache.org/bugs/
            Mail list info: http://perl.apache.org/maillist/modperl.html
            List etiquette: http://perl.apache.org/maillist/email-etiquette.html
          • Eric
            Hi, I was just reminded of this happening and thought it might be useful to people here since lots of people like me use Storable for persistence with
            Message 5 of 13 , Jun 15, 2004
            • 0 Attachment
              Hi,

              I was just reminded of this happening and thought it might be useful to people here since lots of people like me use Storable for persistence with mod_perl.

              FreeBSD 4.10 changed the way Perl is compiled in the ports collection. They added the use64bitint flag which was not there before. That led to some issues with Storable that the Storable perldoc goes into in a lot of detail. It was all one big adventure until I found that out about the ports change. We never had a problem with Storable working across different databases on different machines until this happened. I just thought it might be a good warning to put out.. You will end up with the version errors that the perldoc talks about. See 64 bit data in perl 5.6.0 and 5.6.1

              I ended up just removing the use64bitint and did a make deinstall make clean etc...
              But I guess in the sprit of my last post I really should make a conversion program to load the old Storable data and re-write it with the new. Otherwise the next FreeBSD update could lead to a headache... :)


              Thanks,

              Eric


              --
              Report problems: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
            • Stas Bekman
              Eric Frazier wrote: Jim, Eric, so can you please put this thread together into one doc piece that can be added to the docs? --
              Message 6 of 13 , Jun 30, 2004
              • 0 Attachment
                Eric Frazier wrote:

                Jim, Eric, so can you please put this thread together into one doc piece that
                can be added to the docs?


                --
                __________________________________________________________________
                Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                mailto:stas@... http://use.perl.org http://apacheweek.com
                http://modperlbook.org http://apache.org http://ticketmaster.com

                --
                Report problems: http://perl.apache.org/bugs/
                Mail list info: http://perl.apache.org/maillist/modperl.html
                List etiquette: http://perl.apache.org/maillist/email-etiquette.html
              • Jim Albert
                ... I had just noticed that I received none of the mod_perl mailings in the past 10 days or so. Looks like the mod_perl list mail server is on a spam
                Message 7 of 13 , Jun 30, 2004
                • 0 Attachment
                  Stas Bekman wrote:

                  > Eric Frazier wrote:
                  >
                  > Jim, Eric, so can you please put this thread together into one doc piece
                  > that can be added to the docs?
                  >
                  >

                  I had just noticed that I received none of the mod_perl mailings in the
                  past 10 days or so. Looks like the mod_perl list mail server is on a
                  spam blacklist.

                  relay=hermes.apache.org [209.237.227.199]
                  Rejected from 209.237.227.199 - see http://spews.org/bounce.html

                  I understand spews is one of the more aggressive blacklists, but perhaps
                  one the list admins should look into getting this IP out of spews?

                  --
                  Jim Albert



                  --
                  Report problems: http://perl.apache.org/bugs/
                  Mail list info: http://perl.apache.org/maillist/modperl.html
                  List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                • Stas Bekman
                  ... This issue was raised on the apache infrastructure list and someone told that one shouldn t even bother to do that, because of the draconian rules
                  Message 8 of 13 , Jun 30, 2004
                  • 0 Attachment
                    Jim Albert wrote:
                    > Stas Bekman wrote:
                    >
                    >> Eric Frazier wrote:
                    >>
                    >> Jim, Eric, so can you please put this thread together into one doc
                    >> piece that can be added to the docs?
                    >>
                    >>
                    >
                    > I had just noticed that I received none of the mod_perl mailings in the
                    > past 10 days or so. Looks like the mod_perl list mail server is on a
                    > spam blacklist.
                    >
                    > relay=hermes.apache.org [209.237.227.199]
                    > Rejected from 209.237.227.199 - see http://spews.org/bounce.html
                    >
                    > I understand spews is one of the more aggressive blacklists, but perhaps
                    > one the list admins should look into getting this IP out of spews?

                    This issue was raised on the apache infrastructure list and someone told that
                    one shouldn't even bother to do that, because of the draconian rules spews.org
                    uses (I'm just repeating their words) and I guess the admins aren't going to
                    do that. Therefore there is nothing we can do about it. I suppose you could
                    contact infrastructure #at# apache.org.

                    --
                    __________________________________________________________________
                    Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                    http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                    mailto:stas@... http://use.perl.org http://apacheweek.com
                    http://modperlbook.org http://apache.org http://ticketmaster.com

                    --
                    Report problems: http://perl.apache.org/bugs/
                    Mail list info: http://perl.apache.org/maillist/modperl.html
                    List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                  • Eric Frazier
                    Hi, Who ever is admining your mail server might want to look into using a *responsible* list. Spews routinely causes horror for many innocents, sometimes
                    Message 9 of 13 , Jun 30, 2004
                    • 0 Attachment
                      Hi,

                      Who ever is admining your mail server might want to look into using a
                      *responsible* list. Spews routinely causes horror for many innocents,
                      sometimes blocking whole datacenters over one account.

                      Almost any other list is an improvement, I have noticed many lists follow
                      along behind http://www.spamhaus.org/ for example, and they have reasonable
                      people you can talk to. It is MUCH more likely you will fix the problem by
                      getting your admin to change his blacklist choice than that you will be
                      able to get the mod_perl list off the spews listing. They will only rinse
                      and repeat, "Get rid of the spammer, or move your ISP"

                      Yes, folks, it is that bad these days. spam means unsolicited email, but
                      also it means lots of people don't get their legitimate email. I frankly
                      think the whole thing is a nightmare with no end in sight..



                      Thanks,

                      Eric


                      At 01:10 PM 6/30/2004, Jim Albert wrote:
                      >Stas Bekman wrote:
                      >
                      >>Eric Frazier wrote:
                      >>Jim, Eric, so can you please put this thread together into one doc piece
                      >>that can be added to the docs?
                      >
                      >I had just noticed that I received none of the mod_perl mailings in the
                      >past 10 days or so. Looks like the mod_perl list mail server is on a spam
                      >blacklist.
                      >
                      >relay=hermes.apache.org [209.237.227.199]
                      >Rejected from 209.237.227.199 - see http://spews.org/bounce.html
                      >
                      >I understand spews is one of the more aggressive blacklists, but perhaps
                      >one the list admins should look into getting this IP out of spews?
                      >
                      >--
                      >Jim Albert
                      >
                      >
                      >
                      >--
                      >Report problems: http://perl.apache.org/bugs/
                      >Mail list info: http://perl.apache.org/maillist/modperl.html
                      >List etiquette: http://perl.apache.org/maillist/email-etiquette.html


                      --
                      Report problems: http://perl.apache.org/bugs/
                      Mail list info: http://perl.apache.org/maillist/modperl.html
                      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                    • Jim Albert
                      ... Not a big deal; one can always allow access to a particular server on their own mail server if they decide to trust the server. If the admins don t want to
                      Message 10 of 13 , Jun 30, 2004
                      • 0 Attachment
                        Stas Bekman wrote:

                        > Jim Albert wrote:
                        >
                        >> Stas Bekman wrote:
                        >>
                        >>> Eric Frazier wrote:
                        >>>
                        >>> Jim, Eric, so can you please put this thread together into one doc
                        >>> piece that can be added to the docs?
                        >>>
                        >>>
                        >>
                        >> I had just noticed that I received none of the mod_perl mailings in
                        >> the past 10 days or so. Looks like the mod_perl list mail server is
                        >> on a spam blacklist.
                        >>
                        >> relay=hermes.apache.org [209.237.227.199]
                        >> Rejected from 209.237.227.199 - see http://spews.org/bounce.html
                        >>
                        >> I understand spews is one of the more aggressive blacklists, but
                        >> perhaps one the list admins should look into getting this IP out of
                        >> spews?
                        >
                        >
                        > This issue was raised on the apache infrastructure list and someone told
                        > that one shouldn't even bother to do that, because of the draconian
                        > rules spews.org uses (I'm just repeating their words) and I guess the
                        > admins aren't going to do that. Therefore there is nothing we can do
                        > about it. I suppose you could contact infrastructure #at# apache.org.
                        >

                        Not a big deal; one can always allow access to a particular server on
                        their own mail server if they decide to trust the server. If the admins
                        don't want to make an attempt to get the IP pulled out of spews, I
                        wouldn't push it.

                        --
                        Jim Albert



                        --
                        Report problems: http://perl.apache.org/bugs/
                        Mail list info: http://perl.apache.org/maillist/modperl.html
                        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                      • Lupe Christoph
                        ... For this partivular case, please read http://spews.org/ask.cgi?S3056 ... Off-topic (I m only using perl for this, not mod_perl ;-) ) Since last weekend,
                        Message 11 of 13 , Jul 1, 2004
                        • 0 Attachment
                          On Wednesday, 2004-06-30 at 13:42:16 -0700, Eric Frazier wrote:

                          > Who ever is admining your mail server might want to look into using a
                          > *responsible* list. Spews routinely causes horror for many innocents,
                          > sometimes blocking whole datacenters over one account.

                          For this partivular case, please read
                          http://spews.org/ask.cgi?S3056

                          > Almost any other list is an improvement, I have noticed many lists follow
                          > along behind http://www.spamhaus.org/ for example, and they have reasonable
                          > people you can talk to. It is MUCH more likely you will fix the problem by
                          > getting your admin to change his blacklist choice than that you will be
                          > able to get the mod_perl list off the spews listing. They will only rinse
                          > and repeat, "Get rid of the spammer, or move your ISP"

                          > Yes, folks, it is that bad these days. spam means unsolicited email, but
                          > also it means lots of people don't get their legitimate email. I frankly
                          > think the whole thing is a nightmare with no end in sight..

                          Off-topic (I'm only using perl for this, not mod_perl ;-) )

                          Since last weekend, I'm collecting RBL hits and misses for spam and ham.
                          Spews is definitely a bad idea. It blocks hermes.apache.org even at
                          level 1.

                          I have written a Perl program that tries to find the "best" RBLs. It
                          eliminates all RBLs that hit servers delivering ham. Then it lets me
                          manually insert RBLs, then it selects by effectiveness. I manually set
                          Chian/Korea blocking and blocking of dynamically assigned addresses.

                          Without manually set RBLs, the hitlist is this:

                          cbl.abuseat.org dynablock.njabl.org no-more-funn.moensted.dk
                          bl.spamcop.net dnsbl-2.uceprotect.net list.dsbl.org spam.dnsbl.sorbs.net
                          cn-kr.blackholes.us multihop.dsbl.org psbl.surriel.com sbl.spamhaus.org
                          dul.dnsbl.sorbs.net dnsbl-3.uceprotect.net ipwhois.rfc-ignorant.org
                          mail-abuse.blacklist.jippg.org

                          cbl.abuseat.org dynablock.njabl.org no-more-funn.moensted.dk
                          bl.spamcop.net catch 90% of the spamming adresses. uceprotect and
                          rfc-ignorant are too dangerous and will probably eliminated by the
                          false-positive checker in a while.

                          I have 18 IP addresses that sent Spam and were not blocked by any list,
                          even the most aggressive ones. 27 addresses were only recognized by
                          aggressive lists, 264 are recognized by the above list of RBLs.

                          Here are the overly aggressive RBLs:

                          blackholes.five-ten-sg.com
                          block.blars.org
                          l1.spews.dnsbl.sorbs.net
                          l2.spews.dnsbl.sorbs.net
                          spews.blackholes.us
                          dnsbl.jammconsulting.com

                          Whoever read this far and is still interested - mail me if you want the
                          code.

                          HTH,
                          Lupe Christoph
                          --
                          | lupe@... | http://www.lupe-christoph.de/ |
                          | "... putting a mail server on the Internet without filtering is like |
                          | covering yourself with barbecue sauce and breaking into the Charity |
                          | Home for Badgers with Rabies. Michael Lucas |

                          --
                          Report problems: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html
                          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                        • Stas Bekman
                          ... so any chance someone can put together the solutions from Eric and Jim, and the other suggestions I gave in the reply to the Jim s original question? And
                          Message 12 of 13 , Jul 21, 2004
                          • 0 Attachment
                            Stas Bekman wrote:
                            > Eric Frazier wrote:
                            >
                            > Jim, Eric, so can you please put this thread together into one doc piece
                            > that can be added to the docs?

                            so any chance someone can put together the solutions from Eric and Jim,
                            and the other suggestions I gave in the reply to the Jim's original
                            question? And then we will add them to the online docs. I'd really like
                            to concentrate on finishing the mp2 API at this time, to get mp2 out
                            sooner. So your help is appreciated.

                            The relevant threads are:
                            http://marc.theaimsgroup.com/?t=108681694700001&r=1&w=2
                            http://marc.theaimsgroup.com/?t=108733667200002&r=1&w=2

                            Thanks.

                            --
                            __________________________________________________________________
                            Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                            http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                            mailto:stas@... http://use.perl.org http://apacheweek.com
                            http://modperlbook.org http://apache.org http://ticketmaster.com

                            --
                            Report problems: http://perl.apache.org/bugs/
                            Mail list info: http://perl.apache.org/maillist/modperl.html
                            List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                          • Stas Bekman
                            ... Well, it s now documented here: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Problems_with_Catching_Signals_under_Perl_5_8_x_
                            Message 13 of 13 , Nov 24, 2004
                            • 0 Attachment
                              Stas Bekman wrote:
                              > Stas Bekman wrote:
                              >
                              >> Eric Frazier wrote:
                              >>
                              >> Jim, Eric, so can you please put this thread together into one doc
                              >> piece that can be added to the docs?
                              >
                              >
                              > so any chance someone can put together the solutions from Eric and Jim,
                              > and the other suggestions I gave in the reply to the Jim's original
                              > question? And then we will add them to the online docs. I'd really like
                              > to concentrate on finishing the mp2 API at this time, to get mp2 out
                              > sooner. So your help is appreciated.
                              >
                              > The relevant threads are:
                              > http://marc.theaimsgroup.com/?t=108681694700001&r=1&w=2
                              > http://marc.theaimsgroup.com/?t=108733667200002&r=1&w=2

                              Well, it's now documented here:
                              http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Problems_with_Catching_Signals_under_Perl_5_8_x_


                              --
                              __________________________________________________________________
                              Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                              http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                              mailto:stas@... http://use.perl.org http://apacheweek.com
                              http://modperlbook.org http://apache.org http://ticketmaster.com

                              --
                              Report problems: http://perl.apache.org/bugs/
                              Mail list info: http://perl.apache.org/maillist/modperl.html
                              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                            Your message has been successfully submitted and would be delivered to recipients shortly.