Re: problem with error_log_spread.pl

Jay West wrote:

> Some time ago I raised this issue, but it hasn't been resolved yet:
>
> I have a number of websites which are configured with the following line....
>
> CustomLog "|/usr/local/sbin/error_log_spread.pl -g test"
>
> When you do an "apachectl start" to start the webserver, apache starts a
> separate process for each of the error_log_spread.pl invocations. If they
> all go fine, each error_log_spread.pl line generates a linefeed. So if I
> have 10 sites using the above line (but with a different spreadlog group for
> each), an "apachectl start" generates 10 line feeds then returns to a
> command prompt and everything is perfect.
>
> However, about 50% of the time, when I do "apachectl start", I will get some
> number of messages from error_log_spread.pl that say "Could not connect",
> and the balance of linefeeds. For example, one time I do the apachectl start
> I may get 3 "could not connect" messages and 7 linefeeds (total 10 results).
> It is not always the same customlog statements generating the could not
> connect message. If I stop and start apache, I may get 2 could not connects
> and 8 linefeeds. If I do it several times, finally I will just get the 10
> linefeeds. The long and short of it is... out of 10 custom log directives
> calling error_log_spread.pl, SOME number of them fail to connect UPON
> STARTUP ONLY.
>
> What this tells me is that there is some sporadic timing condition where the
> error_log_spread.pl script can't make the initial connection to spread. The
> net effect of this is some of the websites don't get logging when this
> happens. This is especially problematic for us, as the websites are updated
> remotely by the programmers, and the script does this...

Add after:

   print STDERR "Failed multicast $_ to $group: $sperrno\n" if $debug;
+ Spread::disconnect($mbox);
+ ($mbox, $privategroup) = Spread::connect(\%args);

That will attempt a reconnect after every failed multicast attempt ensuring 
that as soon as Spread is available, it will log.

>
> apachectl stop
> wackatrl -f
> (cvs/rsync stuff)
> wackatrl -s
> apachectl start

Very cute... I like that. Any reason you don't:

wackatrl -f
apachectl stop
(cvs/rsync stuff)
apachectl start
wackatrl -s

Seems safer to drop the VIP before stopping apache and bring it up after 
starting it back up.

-- 
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone:  +1 410 872 4910 x201     Fax:  +1 410 872 4911
1024D/82844984/95FD 30F1 489E 4613 F22E  491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

-----------------------------------------------------------
  --              Presenting at ApacheCon                --
  --                November 18th, 2002                  --
  --                 Las Vegas, Nevada                   --
  -- Backhand: understanding and building HA/LB clusters --
  --           http://apachecon.com/2002/US/             --
  --                                                     --
  -- Learn all there is to know about high availability  --
  -- internet systems and load balancing techniques      --
  -- focusing on applications driven by the Apache web   --
  -- server!                                             --
-----------------------------------------------------------