> Not likely; I nuked my spool when upgrading. At any rate, I'm sure there > will be another beta soon which will give me another opportunity to nuke. Heh! The stats file has a version id which is designed to prevent problems with upgrades to the stats structures. There should be no need to ever nuke the entire cache - just cache.mmap for those system that use it, although I'm considering removing the possibility of maintaining state in cache.mmap at all. It was only ever designed as a work around for systems with with broken shared memory handlers (and thus could not use anonymous shared memory regions). nntpcached is designed to be long lived. the b1 on nntpcache.org has run without problems (well without sigsegv problems in the master process) for two weeks now. Also Herbet Xu has introduced some nice patches that essentially re-populate the shared memory cache state based on the per-server cache when nntpcached-update does its stuff. > > The only thing that I see isn't working on the stats is the CPU times > >for the master CPU, and this only seems to occur on FreeBSD. > > Yes, system CPU time of 55y106d1h10m42s definitely doesn't seem right :-) > > Evan I suspect this has to do with the `hoary bitch' :) of a problem Aaron identified in b3. My revamping of internal task handling and task_info introduced an over-write problem on task exit. Although I'm not sure why this is only seen on FreeBSD. Cheers, Jul;ian.
