inn-2.3.0, expire with delayrm, tradspool, seems not working
benedict at daimi.au.dk
Wed Oct 4 14:42:34 UTC 2000
Katsuhiro Kondou writes:
> In article <14800.45185.535035.810259 at caligula.daimi.au.dk>,
> Benedict Lofstedt <benedict at daimi.au.dk> wrote;
> } Can't unlink @05000000000300079DFA0000000000000000@
> } and, eventually, I had a core dump.
> Could you do back trace for it?
> } If I don't do 'delayrm', expire works fine ...
> Could you show expire.log for both?
> Katsuhiro Kondou
I have compiled expireover with debugging (-g -O0) and have not had any
Unfortunately, my daily expire routine still doesn't work, so I'm raising
another issue here.
My crontab is like this (since ages...)
01 00 * * * /news/bin/news.daily noexpire
01 01 * * * /news/bin/news.daily expireover notdaily expdir=/news/expire
It would seem that I have been caught in a changed functionality -
expireover was not run under inn-2.2.3 when i used
However, news.daily report from this morning contains 93580 entries of the
type Cant' unlink ..., followed by a log from expireover, but no log from
[...93579 entries snipped ...]
Can't unlink @0500000012730000004D0000000000000000@
Renumbering active file.
expireover start Wed Oct 4 00:05:46 MET DST 2000: ()
Article lines processed 985694
Articles dropped 93580
Overview index dropped 99957
expireover end Wed Oct 4 00:25:25 MET DST 2000
Post expiration status:
the token @0500000012730000004D0000000000000000@ is still in my
historyfile. It corresponds to comp.lang.smalltalk.advocacy:77, which is
still in my spool area. However, the active file shows a low mark of 79
for the newsgroup.
I'm now feeding the tokens to fastrm, and lo and behold, my spool area is
fast being reduced to a more comfortable size.
BTW: the man-page for fastrm contains an anachronism. It has been changed
to mention that the input is a list of tokens, but the final paragraph has
not caught up. The feeding of the list of files into an ``xargs rm''
pipeline is probably *not* a good idea ;-)
Fastrm reads a list of article tokens, one per line, from
its standard input and removes them.
Fastrm exits with a status of zero if there were no
problems, or one if something went wrong. Attempting to
remove a file that does not exist is not considered a
problem. If the program exits with a non-zero status, it is
probably a good idea to feed the list of files into an
``xargs rm'' pipeline.
Benedict Lofstedt <blofstedt at daimi.au.dk>
University of Aarhus, Department of Computer Science Fax: + 45 8942 3255
Building 540, Ny Munkegade, DK-8000 Aarhus C, Denmark. Phone: + 45 8942 3222
More information about the inn-bugs