Re: heavy swapping may kill system?

["Matt Emmerton" <matt@xxxxxxxxxxxxx>]

> I had a DragonFly 1.8.2 system lock up on me completely - even the console
> was frozen.  All that was printed was a long series of this:
>
> swap_pager_getswapspace: failed
>
> I hit the power button and rebooted, but I've noticed an ongoing series of
> this: (from dmesg)
>
> > pid 788 (imapd), uid 1006: exited on signal 6
> > pid 806 (imapd), uid 1006: exited on signal 6
> > pid 815 (imapd), uid 1006: exited on signal 6
> > pid 825 (imapd), uid 1006: exited on signal 6
> > swap_pager_getswapspace: failed
> > swap_pager_getswapspace: failed
> > swap_pager_getswapspace: failed
> > swap_pager_getswapspace: failed
> (repeat...)
>
> Investigating, one of the user accounts has some multi-gigabyte backup
> files in ~, and imap-uw is trying to index them as mail messages.  The
> error here lies either in my configuration or imap-uw, but: it appears to
> have locked up the system after a while.  Should that runaway application
> have been able to bring down the entire computer that way?

IMO, this is what ulimit (and friends) are for.

Here's what ulimit says on my 1.9 box:

root@jekell# ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  3214
open files                      (-n)  6429
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited
root@jekell#

With unlimited -m/-v/-b/-f/-t settings, there's nothing to restrict a
process from attempting to consume more memory (phys or virt) or CPU than is
available.  In your case, having -m/-v set to reasonable limits would have
prevented uw-imap from bringing down the system -- as once those limits were
exceeded, a malloc or shmget would have failed and the process would have
likely died - instead of bringing down the system.

It seems to me that in the BSD world, the default limits are quite
permissive (ie, unlimited), whereas in the "commercial" Un*x world (ie, AIX,
Solaris, etc) the ulimits are set to reasonable restrictive limits.  On the
AIX boxes I use, I always end up having to change my ulimit sessions since
files get truncated at 1G, and applications fail because they can't allocate
enough memory and core files always get truncated.  It's quite a pain, but
it's also quite useful from an administration POV since rogue users aren't
abel to take the system down.

Regards,
--
Matt Emmerton