We're using pound as a proxy to several different websites running on
the same host.  I've noticed though that, when 'LogLevel' is set to 2,
there's no indication in the logs which back end the request was sent
to. It just says something like...

Sep 25 10:00:45 pound pound: x.x.x.x GET /user/login HTTP/1.1 - HTTP/1.1
200 OK (:3003)

When I bump the LogLevel up to 3, then successful requests show the full
URL, which lets me figure out which backend was used, but if there's an
error, it just says.

Sep 25 10:32:10 pound pound: no back-end "GET /user/login HTTP/1.1" from
x.x.x.x

Is there a way to get a better idea of where pound is routing traffic,
especially when it fails?   We're troubleshooting some backend processes
mysteriously dying and so far the pound logs have proven to be
completely useless in our investigation of the HTTP request that
directly preceded the problem.

On Mon, 2006-09-25 at 11:01 -0600, Jon Garvin wrote:
> We're using pound as a proxy to several different websites running on
> the same host.  I've noticed though that, when 'LogLevel' is set to 2,
> there's no indication in the logs which back end the request was sent
> to. It just says something like...
> 
> Sep 25 10:00:45 pound pound: x.x.x.x GET /user/login HTTP/1.1 - HTTP/1.1
> 200 OK (:3003)

This is fixed in the latest release 2.1.3

> When I bump the LogLevel up to 3, then successful requests show the full
> URL, which lets me figure out which backend was used, but if there's an
> error, it just says.
> 
> Sep 25 10:32:10 pound pound: no back-end "GET /user/login HTTP/1.1" from
> x.x.x.x

It's hard to show in the logs where the request was sent to if it was
never sent anywhere. You may want to search the logs for "back-end dead"
and "back-end resurrected" messages.

> Is there a way to get a better idea of where pound is routing traffic,
> especially when it fails?   We're troubleshooting some backend processes
> mysteriously dying and so far the pound logs have proven to be
> completely useless in our investigation of the HTTP request that
> directly preceded the problem.

We would happily look at your patch for improved logging.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert Segall wrote:
> This is fixed in the latest release 2.1.3
>
>   
Ahh, thanks. I guess I should read the release notes more often.