Detailled innfeed logging?

Christoph Biedl cbiedl at
Sat Jan 28 12:35:34 UTC 2006

Bill Davidsen wrote...

[ no need to Cc: me, I do read the list ]

> If you want to do it "right" you want a status of accepted, rejected, 
> refused, pushed back, dropped, etc, for every article offered to every 
> peer... I have the feeling that in many cases the logs would need more 
> space than the articles and the overhead of formatting would be 
> significant.

If you're feeding a zillion sites you'll need the space for backlog
anyway. But the have-dozen-peers site has no need to be afraid: The
per-site log file would have about the same size as the news log file
itself. And Disk space is not that expensive any more. Furthermore I was
not talking of enabling such an option per default. I'd like to have it
at all in a debugging situation like the one that caused my inital

A site had trouble feeding certain articles, there were received like in
| Jan 24 04:00:13.592 + peerC <msg at id> 1234 (...) peerB (...)
There's no backlog to peerB but the article arrived at peerB three days
later, after a short detour via Russia and Australia. Nothing in the
logs of peerB. How would I debug that?

> I presume you have something more than "log hell out of everything" in 
> mind, sharing that would get you some feedback, but my first thought is 
> that I couldn't afford to have it on all the time, if I did it would be 
> expensive to parse, and if I know enough to turn it on for one site at 
> the right time, I can probably catch what I need with a sniffer or tcpdump.

tcpdump is an excellent tool for short debuggings but plain nightmare
for that. At first it requires root privileges which I do not have on
all systems. Then it will create a huge dump file with a lot of
uninteresting content: The body of the messages, the -s option is not a
safe cure against that problem. And finally I'll need other tools to
gain grep'able Information.


More information about the inn-workers mailing list