On Thursday, April 19, 2001, at 07:38 AM, Philip Hazel wrote:
> On Thu, 19 Apr 2001, Florian Laws wrote:
>
>> I have problems with Exim 3.22 which seems to leak
>> file handles on two Linux machines:
>> #1: SuSE Linux 6.2, Kernel 2.2.18, glibc 2.1.1,
>> one IDE disk
>> #2: SuSE Linux 6.4, Kernel 2.2.16 + raid patches,
>> glibc 2.1.3, two SCSI disks as software RAID.
>>
>> Under heavy load, both machines seem to run out of
>> available file descriptors, no processes can run anymore
>> because of that.
>
> Well, Exim is implemented mainly in short-lived processes. The daemon is
> the only long-lived process, and its code has been extremely stable for
> a very long time, so I doubt very much whether it would leak file
> handles[*]. Every other Exim process lives for only a short time.
> Therefore, I find it hard to believe that Exim as a whole could leak
> file handles. Of course, if the system is very busy and there are
> zillions of Exim processes, they may try to use a large number at once.
I have seen this on Linux. It is not an Exim problem -- at least on my
system. I am running an older linux kernel (2.2.17) and Exim 3.14.
Sometimes an exim process will get stuck in state 'D' and will never
quit. It will fill up the process table and leave the mainlog open.
So, when it is rotated with exicyclog, the mainlog was moved, compressed
and deleted, but it was never released on disk because a process still
had an open handle to it.
I may be wrong, but that sounds astoundingly like a linux bug. To fix
it, I just run lsof everyday to find "the bad guys" and kill them.
It sounds like something else is wrong in your set up. Use lsof (run it
as root with no options) and see if there is any specific process
abusing resources. I doubt it is exim.
As a side note, we set our max files to 65535 and max inodes to twice
that.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
