|
Grex > Helpers > #149: Grex System Problems - Spring 2006 | |
|
| Author |
Message |
| 17 new of 333 responses total. |
mcnally
|
|
response 317 of 333:
| 
Jun 14 08:16 UTC 2006 |
One of the things which is causing mail failures, I believe,
(but not the only one) is that periodically /var/spool runs out
of free inodes. It runs out of free inodes because there's a
totally absurd number of files in several subdirectories of
/var/spool/exim which never, ever seem to get cleared out.
Can someone who's familiar with exim tell me what purpose the
various subdirectories of /var/spool/exim serve and how files
in there are supposed to be purged? Because we don't seem to
be doing it properly..
|
keesan
|
|
response 318 of 333:
|
Jun 14 21:52 UTC 2006 |
I am still getting mail from June 8 - better late than never. Thanks again
STeve et al.
|
cross
|
|
response 319 of 333:
|
Jun 14 23:18 UTC 2006 |
This response has been erased.
|
keesan
|
|
response 320 of 333:
|
Jun 15 00:48 UTC 2006 |
I was able to reply to a few June 7 mails that just showed up but now I am
getting an STMP greeting failure when I try to send mail. We picked the wrong
week to try to sell a car. Turns out lots of people were interested a week
ago.
|
keesan
|
|
response 321 of 333:
|
Jun 15 01:22 UTC 2006 |
Today I have been getting mail progressively from June 9, June 8, June 7 and
now June 6. I wondered why people had stopped writing. Thanks again.
|
keesan
|
|
response 322 of 333:
|
Jun 15 01:56 UTC 2006 |
In among the June 7 I just got a May 23 mail! Rane was saying it took up to
12 days to get mail at grex, but this is about 21 days. How does the mail
manage to get so bogged down? Can exim be instructed to deliver the oldest
mails first instead of the newest ones?
|
steve
|
|
response 323 of 333:
|
Jun 15 04:09 UTC 2006 |
There are some old pieces of mail in the queue which I think will now
get liberated. Exim is likely going to get a little more tweaking
before this is all over. But mails are moving fairly quickly now.
It took about 1.5 minutes for mail to get from msu.edu to grex, and
faster than that the other way around.
|
rcurl
|
|
response 324 of 333:
|
Jun 15 07:57 UTC 2006 |
Wow! The e-mail dam has burst. But, thanks!
|
gull
|
|
response 325 of 333:
|
Jun 16 23:57 UTC 2006 |
Re resp:317: I don't have the permissions to see what's
in /var/spool/exim here, but on my own machine I see four directories.
db/ - This only has four files in it, on my system. I think it
contains Exim's retry database.
input/ - This holds the message queue. If I remember right there are
two files per message, one containing just the headers and one
containing the message body. If you've got a lot of crap in there, you
need to figure out why messages are stacking up in the queue. A common
culprit is undeliverable bounce messages, which Exim "freezes" and
keeps in the queue until the time set in the
"ignore_bounce_errors_after" option is reached. You want this time
*short* because undeliverable bounces are almost always the worthless
backscatter from spam runs. Right now Grex has this set to 2 days,
which I'd say is on the long side.
msglog/ - This holds log information about messages that are in
transit. The files here (one per message) are normally deleted once
the message is delivered, although sometimes they get missed and
linger. Again, if this is full, it might be because you have a long
queue. This information is duplicated in the main log, so it's safe to
say "message_logs=false" in the beginning part of exim.conf and delete
the contents of this directory. This should help the inode problem.
scan/ - This is a temporary directory where messages are unpacked while
they're scanned by external software like ClamAV or SpamAssassin. I
don't think Grex is running either of those programs, so there
shouldn't be anything in there.
|
mcnally
|
|
response 326 of 333:
|
Jun 17 00:18 UTC 2006 |
The msglog directory has tens, or possibly hundreds, of thousands of
files, some of them dating back to 2004.
I presume those aren't from messages Grex is still attempting to deliver..
|
gull
|
|
response 327 of 333:
|
Jun 17 00:39 UTC 2006 |
Remember that Grex crashed a lot, for a while. Most likely Exim never
got to delete those files due to a crash, or perhaps there's a bug that
causes them to occasionally escape deletion.
Like I said, they're safe to delete, and if you set
"message_logs=false" you shouldn't have to deal with them anymore.
They're really only useful for troubleshooting delivery problems, and
the same info can be gleaned from the other logs with a bit of effort.
|
cross
|
|
response 328 of 333:
|
Jun 19 00:18 UTC 2006 |
This response has been erased.
|
gull
|
|
response 329 of 333:
|
Jun 20 20:35 UTC 2006 |
I'm not arguing with that. I've got four old message log files on my
own small server, and I have no idea why. Frankly, I think the whole
individual-message-log thing is a misfeature that should be removed, or
turned off by default.
UNIX software in general doesn't seem to clean up after itself very
well. If it did there wouldn't be a need for periodic /tmp cleaning
scripts to get rid of old, stale lockfiles and the like.
|
eprom
|
|
response 330 of 333:
|
Jun 21 23:43 UTC 2006 |
its officially summer
|
keesan
|
|
response 331 of 333:
|
Jun 22 01:29 UTC 2006 |
I could not dial either number just now and connect - they both just rang.
|
naftee
|
|
response 332 of 333:
|
Jun 22 02:10 UTC 2006 |
what !
m-net seems to be down :(
|
scholar
|
|
response 333 of 333:
|
Jun 22 02:13 UTC 2006 |
:(
plz fix
|