The mailing list for listmasters using Sympa

[Mike Hitch <address@concealed>]

On Thu, 20 May 2010, Erik Olson wrote:

> On Thu, 20 May 2010, Miles Fidelman wrote:
>
> > After installing 6.0.1, I notice the wwwsympa processes seem to eat up a 
> > huge amount of CPU cycles.  Restarting Apache brings my compute load back 
> > to a reasonable level.  Then, after a few interactive sessions w/ the Sympa 
> > interface, I'm running 4 wwwsympa processes, and each one is eating up a 
> > quarter of the available cyles - pinning computer load at 100%
> >
> > Is anybody else seeing this kind of behavior?  Is any of this tunable?
>
> I have seen a similar issue very occasionally on my system.
> I think it's a nasty bug, but no idea how to diagnose it.  It has something 
> to do with authentication, because if the user in question who is bringing 
> causing the wwwsympa process to spike clears their cookies on the browser 
> (causing them to re-authenticate), it calms down and works. So far I've seen 
> this two or three times since installing 6.0.1 last February.
>
> Give it a try (clear cookies on your browser) and see if that fixes your 
> problem as well.

  I have also noticed this.  I also found that clearing the cookies would 
let me re-athenticate and continue.  I also determined that it occurred 
when I tried to edit a subscriber entry.  I am in the process of moving 
our mailing lists from OpenVMS Message Exchange, and have been working on 
conversion of a large number of lists and importing them into Sympa. 
While testing this process, I have been munging the real addresses into a 
set of test addresses, and found that trying to edit one of those 
subscriber's options would cause this.  Some experimenting showed that the 
address format I was using would cause this.  I was changing the email 
address to "address@concealed", and that if I changed the '+' 
character to something else, it wouldn't cause a looping wwwsympa process. 
I also found that the '/' character, which was present in some of the 
addresses in our existing lists, would have the same problem, even without 
a munged address.

  I can't remember what led me to the session table in the database, but I 
eventually found that the redirect_url stored in the data_session of the 
sesion_table had the unencoded url, and if I replaced that string with 
something else, or even changed the '+' or '/' characters to an encoded 
form, I was able to continue using that session and didn't need to 
re-athenticate.

  After some more digging around in wwsympa.fcgi, I found that the 
redirect_url was being formed from a 'base_url', 'path_cgi', and the 
PATH_INFO environment variable.  The PATH_INFO contains the un-encoded 
data after the cgi in the url.  If I replace the 'path_cgi' and PATH_INFO 
with the REQUEST_URI (which contains the encoded characters), I don't see 
any hanging processes or browser timeouts.

  Here's the patch I came up with to test this:

--- /home/sympa/bin/wwsympa.fcgi.orig   2010-04-04 10:42:29.000000000 
-0600
+++ /home/sympa/bin/wwsympa.fcgi        2010-04-03 16:21:27.000000000 
-0600
@@ -1253,7 +1253,8 @@ my $birthday = time ;
      ## POST is not handled
      ## A lot of other methods where used in the past (before session was 
introduced in Sympa). We must clean all.
      unless ($temporary_actions{$action} || $ENV{'REQUEST_METHOD'} ne 'GET') 
{
-        $session->{'redirect_url'} = 
$param->{'base_url'}.$param->{'path_cgi'}.$ENV{'PATH_INFO'};
+##      $session->{'redirect_url'} = 
$param->{'base_url'}.$param->{'path_cgi'}.$ENV{'PATH_INFO'};
+        $session->{'redirect_url'} = 
$param->{'base_url'}.$ENV{'REQUEST_URI'};
      }

      $action ||= &Conf::get_robot_conf($robot, 'default_home');


---
Mike         Hitch                        
address@concealed
Operations Consulting,  Information Technology Center
Montana State University, Bozeman, MT     USA