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