Bug 19714

On Wed, 05 Jul 2000 08:58:03 MST, marc_bigler@yahoo.com wrote:

> >Description:
> I keep having the message: 
> 
> swap_pager_getswapspace: failed
[...]
> >How-To-Repeat:
> I really don't know it appeared suddently.

The reason we ask for How-To-Repeat is so that we can reproduce the
behaviour on our own machines and then analyze the problem.

Can you either try this on another box or try to produce an exact set of
steps which trigger the behaviour?  My first impression (though I'm no
expert at all in this area of FreeBSD) is that this could be
hardware-related, especially if the problem appeared suddenly.

Ciao,
Sheldon.

Comment 2 Sheldon Hearn 2000-07-06 11:58:34 UTC

Responsible Changed
From-To: freebsd-bugs->dillon

I've asked for more information, in which Matt will probably be 
interested.

I'm hoping as a third party with the same problem clicking the "submit
followup" link is the right thing to do here; my apologies if it's a mistake...

I just want to note that I have the same problem immediately upon upgrading
to 4.1.1-RELEASE (from 2.something actually...). Only in my case the process
generally killed is the X server, leaving the console in an unusable state
(dpms screenblanking still on) which I can't reset short of resetting my
machine. I'm running the same Xfree86 3.3.6 as I was before the upgrade and as
far as I've been able to tell there aren't any memory hungry extra programs
running at the time X gets killed (no cron jobs etc) and the machine is 
basically idle (not used by me). It seems to happen to me every few days.
My swapinfo: 

Device          1024-blocks     Used    Avail Capacity  Type
/dev/rwd0s1b         108104    15072    93032    14%    Interleaved

A typical /var/log/messages entry (found after reboot):

Oct 17 16:49:50 haywire /kernel: swap_pager_getswapspace: failed
Oct 17 16:49:52 haywire last message repeated 13 times
Oct 17 19:44:31 haywire /kernel: pid 236 (XF86_Mach64), uid 0, was killed: out of swap space

   Tim

    Well, generally the only way swap_pager_getswapspace() can fail
    is if something runs the system out of memory.

    In order to prevent this from occuring you need to configure enough
    swap space and set your system resources (/etc/login.conf) such that
    no single process can run the system out of memory.  For example, if
    you have 100MB of swap you should limit per-process data to around
    32MB (the 'datasize' resource in /etc/login.conf).  See also the
    'limit' shell command.

    I would also approach the problem from the other side --- configure
    more swap.

    If you have a runaway process, then hopefully with appropriate limits
    in place the system will kill it when it tries to use too much memory
    rather then the system itself running out of memory and killing 
    something important, like X. 

    Once you have identified the offending process, you can take steps
    to fix it or otherwise not run it.  With appropriate resource limits
    in place, the system will log a message when it finds the offending
    process rather then log a message about running out of swap entirely.

    The rule of thumb is to configure at least 2x the amount of swap as
    you have memory.   If you don't have much memory, though, you should
    still configure at least 128MB of swap.  Personally speaking, I 
    usually configure at least 256MB of swap on all my machines precisely
    to deal with the situation where a process might run away -- to prevent
    the runaway from being able to take down the whole system.

						-Matt

On Mon, 23 Oct 2000 23:59:36 -0700 (PDT), Matt Dillon <dillon@earth.backplane.com> wrote:
>     Once you have identified the offending process, you can take steps
>     to fix it or otherwise not run it.  With appropriate resource limits
>     in place, the system will log a message when it finds the offending
>     process rather then log a message about running out of swap entirely.

It turns out it was the xscreensaver hack "strange" from xscreensaver
version 2.15; it was growing at a rate of about 1K/sec. This is the same
binary that ran fine for a much longer period of time with the older version
of freebsd, so I'm still puzzled as to why it should start happening with
the upgrade. It turns out it still leaks memory if I recompile
xscreensaver-2.15, but not once I downloaded the latest version 3.25 and
compiled it. So the problem is fixed on my machine as far as I'm concerned,
but I'm still suspicious there may be something that causes X-using a.out
compatibility programs to leak memory or something. Thanks,
   Tim

Comment 6 Matt Dillon 2001-12-10 22:57:39 UTC

State Changed
From-To: open->closed

closing old bug report.   

Side note: we recently fixed the code in the kernel 
that kills processes when the machine runs out of VM.    The kernel 
calculates a process's total INCORE+SWAP useage now rather then just the 
INCORE size and the result is that it now generally kills the correct 
process.