inn-2.3.0, expire with delayrm, tradspool, seems not working

Benedict Lofstedt benedict at
Wed Oct 4 14:42:34 UTC 2000

Katsuhiro Kondou writes:
 > In article <14800.45185.535035.810259 at>,
 > 	Benedict Lofstedt <benedict at> 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
more coredumps.

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

  /news/bin/news.daily noexpire

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.
Expire messages:
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.

--- benedict

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>
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 mailing list