Article delegate-en/4036 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]

Newsgroups: mail-lists.delegate-en

[DeleGate-En] NNTP-Delegate will not cache in Linux
02 Aug 2008 20:04:50 GMT Jeff <>


I have been struggling for a week now with NNTP-Delegate. Everything works
great and as expected except for caching. It just does not seem to work. I
have tested under Fedora and a new version of Kubuntu Linux. Under the
assumption that delegated is written for Unix primarily, I can't understand
why it does not work..

Some extra info:
- am running the daemon as superuser (root/root)
- definitely have permissions to write to the cache folder (have tried
various folders)
- there is ample space on the hard drive
- caching is turned on (see config file below)
- running latest version of delegate (though it has been the same for 9.8.2
through the latest development version that I have tried)
- tested by a client downloading a batch of articles from the proxy (which
fetches content from an upstream server - tested both with an NNTP origin
server *and* an upstream delegated NNTP proxy) and then re-downloading [in
my configuration, the cached download throughput is ~ 10 times faster and
also verified on debugging output]
- tested with and without authentication to origin server (NNTP content is
supplied without any problems)

Config file:
MOUNT="= nntp://19x.2xx.4x.6x:8119/ rw"  # tested with and without rw -
makes no difference
ERRORLOG='errors.log[date+.%w]' # no errors in the error log file

I can't figure out what the problem is. I have monitored the output
countless times using -v, -vv, -fv and there seem to be no errors reported.
So I'm putting it down to a platform specific problem.

At one point, delegate was writing NNTP articles to the hard drive but still
not serving them from the cache on second requests. It is as if it is not
checking if the articles are even in the cache. As you can see above, I'm
not specifying a very short expiry time so instant expiry should not be a
reason for the problem.

Some samples of logging output: (as this is extensive, I'm only going to
post some things which I think may be useful)

08/02 21:08:12.00 [10842] 15+0: CLOSE previous cache: private=0 TIMEOFF=0
08/02 21:08:12.00 [10842] 15+0: setLISTcache: private=0 created=0 TIMEOFF=0
08/02 21:08:12.00 [10842] 15+0: with LIST ACTIVE [wildmat] =
08/02 21:08:12.00 [10842] 15+0: CACHE hostname: ->
08/02 21:08:12.01 [10842] 15+0: checking pathhost of in junk...
08/02 21:08:12.32 [10841] 14+0: CACHE hostname:>
08/02 21:08:12.32 [10841] 14+0: shared with parent? :
08/02 21:08:12.32 [10841] 14+0: CACHE hostname: ->
08/02 21:08:12.32 [10841] 14+0: reuse LIST [wildmat][age=1] 215 List
08/02 21:08:12.32 [10841] 14+0: CACHE hostname: ->

I have seen references to OpenCACHE in the logging output but it is not in
my current logs as it is not writing to cache at all at the moment. Perhaps
if there is a part of the output that would be useful, I can post that for
you? Or some other way I can verify what is going on and perhaps restrict
debugging to the caching portion only?

Any help would be appreciated, while I don't think it is a problem with your
software - I feel like I am hitting a brick wall :(

Thanks and regards,

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]