Messages in this thread | | | Date | Mon, 15 Nov 1999 14:14:39 -0500 | From | Derek Martin <> | Subject | Possible 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/
| |