Bug 9379 - some processes disappear after user send big email message
some processes disappear after user send big email message
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: imap (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-12 09:01 EST by sveta
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-30 19:14:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sveta 2000-02-12 09:01:13 EST
One of local users tried to send big email (3 letters for total 120 MB)to
other local user. Second tried to read them using POP-3. The system buzz
for some time by the harddisk, and third user said me that server is down.
I turn on monitor and saw text "Out of memory for <process>". I tried to
log in and saw "Out of memory for mingetty". I cold reboot server. Mail
actions continued. I log in and saw I have no DNS server running. Several
other processes was absent. One time I enter "ps ax" server said "signal
11" and nothing list. I repeat - and ps worked. I shutdown my server and
saw message about swap error (while shutting down swap). I disconnect
network cables from my server and boot. It buzz harddisk for several
minutes and became normal. I checked filesysem - all is ok. Several
megabytes free. I deleted mail queue and mailbox of receiver manually.
While troubles I saw nearly zero free memory and exact zero free space in
swap. I use 50 MB swap partition. I was surprised by signal 11 error from
ps (happened several times, but after repeat command it worked) and by
disappeared processes (named, arpwatch, may be some other - I cannot say
exact). After first shutdown system worked slowly and unstable, but
worked, while in first report I had to turn it off without halt.
Comment 1 Mike A. Harris 2001-07-30 19:14:23 EDT
On any default Linux installation there are no resource limits set up
to prevent users from using gobs of memory/disk and other resources.
As such, it is relatively easy for any user to hog resources and take
a system down, however most systems have some aspect of trust with users
and as such this does not turn out to be a problem, and is why it is the
default in most (all?) Linux distributions, and other UNIX and Unix like
OS's.

The general idea being that for most systems, sysadmins can police
their users adequately to teach them responsible usage of system resources,
such as "don't send 200Mb file attachments in email" et al.  While I would
try to deter users from sending large mail like that, there is no
technical reason why a 200Mb file attachment could not be sent.  The software
is capable of doing so.  The real problem is that the system that you are
running does not have the resources to handle such.  The solutions that
you might consider include:

1) Instruct users not to send large messages
or
2) Add more resources to the system to handle the worst case
or
3) Implement systemwide resource limitations to protect the system from
   such problems.

#1 is the preferred system if you trust your users to not purposefully
knock the system down.  #2 is only viable if you actually want users
to be able to send such large messages, and the upgrade is worth the
effort.  #3 is implemented by system policy that you must define as
administrator of the affected systems.  There is no way to predetermine
such resource limitations in a general sense, and as such by default
resource limitations are disabled on new installations.  Look at the
manpage for "ulimit" for instructions on limiting resources.  You may
also want to look into disk quota support as well.
Comment 2 Mike A. Harris 2001-07-30 19:16:22 EDT
You can also tell sendmail to limit the maximum size of messages recieved
as well to prevent large messages from being accepted in the first place.

Note You need to log in before you can comment on or make changes to this bug.