[Mailman-Users] recovering from a "no space left on device" error

[Mark Sapiro]

Wallace Winfrey wrote:
>
>Currently, qfiles/out has 158 .pck files. When I restarted mailman an
>hour ago, it was at 161. Assuming that mailman processes .pck files
>chronologically, it appears that only 15 messages have come into
>qfiles/out in the last hour, while 18 have gone out. Like I said, is
>there any way to expedite the out queue?


It appears from your subsequent post that running 4 slices of
OutgoingRunner worked for this.


>Many of my qfiles directories have 0-length pck.tmp files:
>
>- qfiles/in has 398 0-length pck.tmp files (168 from today)
>- qfiles/bounces has 342 0-length pck.tmp files
>- qfiles/commands has 178 0-length pck.tmp files
>
>Is it ok to remove these? If so, is there a special way to remove them,
>like bin/discard for heldmsgs? I assume these 0-length files were
>created when the disk ran out of space.


I think you are correct, and yes, just remove them. There will be no
negative consequences from doing so. Since they have no content,
there's no way to recover the individual messages, but the original
senders should have received DSNs from your MTA when the pipe to
Mailman failed.


>Also, qfiles/shunt currently has 11081 pickle files in it. I examined a
>few of them at random, and they all appear to be spam - some go back as
>far as 2006. Is there a proper way to clear out my qfiles/shunt
>directory as well? I did, of course, run unshunt, which temporarily
>cleared out the directory, but then repopulated it again after adding a
>few MB to the end of my mailman/logs/error file.


As you learned, running unshunt was not the thing to do. For unwanted,
shunted messages, just remove the .pck files from qfiles/shunt. If
there are any messages in qfiles/shunt that you want, you need to find
the error log traceback from the shunting of the message and fix the
underlying problem before you can unshunt the message.


>I imagine I can just rm the 0-length files without issue, but manually
>removing .pck files from the data directory in the past has caused me
>headaches, so I wanted to make sure.


The heldmsg*.pck files in data/ are different because there are other
files, pending.pck and request.pck, that have information about them,
and when, for example, generating the admindb page times out because
of too many held messages, you need to remove the entries from the
request.pck, and simply removing the heldmsg*.pck files doesn't do
that. That's why youy need to use bin/discard on these.

But, the files in qfiles/* don't have this problem and can just be rm'd.


>Anything else mailman-related I should take into consideration after
>running out of disk space?


It's possible that one or more config.pck files were corrupted. If
bin/list_lists runs with out error or the listinfo or admin overview
pages work, you should be OK.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan