INN 2.4.3 and news.daily errors with buffindexed overview storage

Jeffrey M. Vinocur jeff at litech.org
Tue Oct 17 16:23:12 UTC 2006


On Tue, 17 Oct 2006, Mike Brudenell wrote:

>      /usr/local/news/bin/news.daily expireover lowmark

Incidentally, I see that I'm using "news.daily expireover lowmark delayrm" 
(the reason I added delayrm is lost in the mists of time).  I suppose you 
could try that just for kicks and see if somehow it makes a difference; it 
shouldn't hurt anything.

> expireover start Tue Oct 17 00:00:54 BST 2006: (-z/usr/local/news/log/ 
> expire.rm -Z/usr/local/news/log/expire.lowmark)
> Can't unlink @03016362303200000000001E5FA900000001@: read only  
> storage api
> Can't unlink @03016362303200000000001E754800000001@: read only  
> storage api
>
> [...]

Okay, so nothing surprising in your storage.conf or cycbuff.conf.


> ======================================================================
> 
> expire.ctl
> ----------
> /remember/:10
> *:A:1:32:90
> york:A:1:32:90
> york.*:A:1:32:90
> york.test:A:0.1:0.1:0.1

None of this actually matters since you're not passing -N to expire, but
it's kinda silly to have expiration times substantially shorter than the
frequency with which you run news.daily (e.g. 24 hours in your case), 
since it means the user-visible behavior will change drastically depending 
on the time of day when the post was made.

But anyway, since you've got exclusively CNFS storage, and you're not
using -N, there's really no reason that any articles should be being
expired at all.  So we're going to have to figure out why expire is trying 
to get rid of those articles (more on this below), plus why it doesn't 
work.


> ======================================================================
> 
> Output from contrib/showtoken.in for some of the tokens
> -------------------------------------------------------
> echo @03016362303200000000001E5FA900000001@ | perl contrib/showtoken.in
> @03016362303200000000001E5FA900000001@ type=cnfs class=1 buffer=cb02  
> offset=3cbf5200 cycnum=1
> 
> echo @03016362303200000000001E754800000001@ | perl contrib/showtoken.in
> @03016362303200000000001E754800000001@ type=cnfs class=1 buffer=cb02  
> offset=3cea9000 cycnum=1
> 
> echo @03016362303200000000001E87EB00000001@ | perl contrib/showtoken.in
> @03016362303200000000001E87EB00000001@ type=cnfs class=1 buffer=cb02  
> offset=3d0fd600 cycnum=1
> 
> echo @03016362303200000000001EE68900000001@ | perl contrib/showtoken.in
> @03016362303200000000001EE68900000001@ type=cnfs class=1 buffer=cb02  
> offset=3dcd1200 cycnum=1
> 
> echo @03016362303200000000001F2D3C00000001@ | perl contrib/showtoken.in
> @03016362303200000000001F2D3C00000001@ type=cnfs class=1 buffer=cb02  
> offset=3e5a7800 cycnum=1

Okay, so they are stored in cycbuffs as expected.  Can you use 
~news/bin/sm to check on a few of the articles and find out if there's 
anything that would make them need to be expired sooner (e.g. an Expires 
header), or anything else they have in common?  Also, if there are any 
articles you don't mind deleting, you could try `sm -r` on one to see if 
you get the same error message (about being read-only) as expire does.

...

But I still don't have a good answer for you.  I'm hoping the above 
investigation will lead somewhere useful, 'cause this is funny.


> Does this imply the other cycbuffs aren't being used?

Oh, you put the SEQUENTIAL flag in your cycbuff.conf, so INN is using the
cycbuffs one at a time.  (That's a sensible thing to do, unless your
server is under a lot of load and you think distributing the disk I/O
would help.)  FYI, ~news/bin/cnfsstat is useful for checking on the in-use
status of your cycbuffs; it gives you a little more detail than ls -l.


-- 
Jeffrey M. Vinocur
jeff at litech.org


More information about the inn-workers mailing list