lkml.org 
[lkml]   [1999]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPossible bug in kernel 2.2.12 and 2.2.13
Hi all,

To be perfectly honest, I'm not sure if this post belongs here, and if
it doesn't please feel free to say so; pointers to the right place will
also be appreciated.

I'm having a problem with my mail server, and it seems to be
kernel-related. First, some background on what I'm doing:

We've set up a Linux box with redHat 6.1 as our e-mail server, running
the imap server that ships with RedHat as our pop server for windows
users, and NFS mounting the spool directory on Unix users' worksations
via aoutomounts. We have already figured out that the stock Linux
kernel does not support NFS v3 yet, so we're using vers=2 in our
automount maps. The spool directory is on a 27GB partition on a Mylex
DAC960 RAID controller. I initially had trouble with the mylex, but I
found a web page which mentions that you may need to update the BIOS, so
I downloaded that and flashed the BIOS on the mylex. After that it
seemed to work fine. The machine itself is a dual PII-300 with .5GB of
RAM.

The server seems to work fine until a large number of users start to
pound on it to get mail via ipopd, though we do see numerous messages
about NFS version 3 such as:

svc:
svc:
lockd: unable to monitor 192.X.X.X

At any rate, the NFS problems do not appear to be the source of the
problem. I'll explain why I say that in a moment. What happens is after
about 15 people are trying to get mail via the pop server, the ipop3d
processes all start to hang, staying in a disk wait state, or as the
manpage for top says, "uninterruptable sleep" (status of "D"). Once
this happens, no ipopd will retrieve mail, and they can not be killed,
even with a kill -9. As more users connect to the machine, the load
goes up, and eventually the machine becomes unusable and needs a reboot.

I do not think that the messages pertaining to NFS are indicative of
the problem, since Unix users accessing the spool via NFS are able to
get e-mail until the machine starts to get completely whacked. However,
I conceed that I do not know enough to say wether it is or is not.

My thoughts are that this may be related to
1) a locking bug
2) a Mylex driver bug
3) some other subsystem that I don't understand well enough to
comment on.

I have not ruled out the possiblity of the problem being
hardware-related (or firmware-related), but given that local disk access
and NFS access continue long after the POP daemons get hosed up, I'm
disinclined to think that is the cause. Incidentally, we also see some
copies of sendmail in a disk-wait state, and the main copy of sendmail
starts to reject connections.

If someone knows what could be causing this and has a fix, we'd love
to hear it, but mainly I want to make people aware of a potential
issue. I would love to be CC'd on information regarding this problem.

Incidentally, I've tried both SMP and non-SMP 2.2.12 kernels, and an
SMP 2.2.13 kernel, and we have this problem on all versions, though the
downward spiral seems to be faster on the SMP boxes... I have seen
reports of SMP kernels crashing so this does not surprise me.

Thanks a bunch,
Derek Martin
Unix System administrator
Arris Interactive

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.039 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site