cnfsstat issue?

[Jesse Rehmer]

Now things seem to be going south fast... I also cannot see any of those 
articles with a news reader either.  Looks like no articles were written 
since around 1:22am this morning.  There are no errors in the logs just 
the following printed every ten minutes since news.daily stuff ran at 1am:

Mar  1 04:24:16 nnrp innd: ctlinnd command s
Mar  1 04:34:16 nnrp innd: ctlinnd command s

I've restarted INN and am getting logging again, but still not able to 
see new articles.  Does anyone have any advice on how to remedy this?  
Would rebuilding the history help at all?

Regards,
Jesse Rehmer

Jesse Rehmer wrote:
> Okay, at first I thought it was a case of not enough articles written 
> out, but now I'm seeing this happen again and it has been several 
> hours with thousands of messages written to the buffer but I'm still 
> seeing this with with cnfsstat -a:
>
>  Buffer bin06, size:  8.00 GBytes, position:  6.76 GBytes  0.84 cycles
>   Newest: 2013-03-01  1:22:58,    0 days, 14:03:37 ago
>   Oldest: 2013-02-28  7:11:48,    1 days,  8:14:47 ago
>
> I can see that there have been thousands of articles going into that 
> buffer:
>
> [news at nnrp db]$ tail -10000 history | cut -f 3 > arts
> [news at nnrp db]$ for i in `cat arts`; do sm -c $i;done | grep bin06 | 
> wc -l
> 5424
>
> This seems to happen after INN has been running for a day or more.  
> I'm also not seeing the position increment either and I think I've had 
> enough news come through that it should have moved on to the next 
> buffer in the metabuff.  I'm at a loss as to how to troubleshoot this 
> further, but I have a feeling it starts after news.daily runs because 
> the stamp for the newest article is right around that time last night.
>
> Any ideas?
>
> Thanks,
> Jesse
>
> Jesse Rehmer wrote:
>> Hi Julien,
>>
>>> First output ("cnfsstat") seems to have been run at 14:59:06.
>>> Second output ("cnfsstat -a") at 14h59h46.  Looks like an article 
>>> was received between the two runs (?)
>>
>> The two commands were ran a few seconds apart.  I tried this multiple 
>> times with the same result.  I'm having a derp moment, because I just 
>> realized that the header is not written back to disk until 25 
>> articles have been written.  In my case alt.bin* is very low volume 
>> and likely did not have 25 articles written to disk in between these 
>> times.  I think I need more coffee.  :-)
>>
>> Cheers,
>> Jesse
>> _______________________________________________
>> inn-workers mailing list
>> inn-workers at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/inn-workers
> _______________________________________________
> inn-workers mailing list
> inn-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/inn-workers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/inn-bugs/attachments/20130301/5aa24504/attachment.html>