[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: screen defscrollback memory exhaustion
From: |
Dave Kuhlman |
Subject: |
Re: screen defscrollback memory exhaustion |
Date: |
Thu, 14 Aug 2014 16:05:30 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Ricardo F. Teixeira <address@hidden> writes:
>
> Hi guys,
>
> Does anyone know how to set the size of the defscrollback buffer to
unlimited?
I'm not sure what your needs are. But, if you know in advance of running a
command that you want to capture the output, look into using the `script`
command. For example:
$ script my_log.txt
will save subsequent screen output to the file my_log.txt and will continue
doing so until you log out of that session created by `script`.
Dave
>
> Lookin' through the man page I saw no reference in setting an unlimited
value:
>
> defscrollback num
> Same as the scrollback command except that the default setting for new
> windows is changed. Initial setting is 100.
>
> Clearly by setting the -k value to nothing (screen -h) will throw the
> help menu. A negative integer doesn't a solve the problem either,
> 'cause screen will print an error message and will exit.
>
> screen.c
> [626] if (nwin_options.histheight < 0)
> [627] exit_with_usage(myname, "-h: %s: negative scrollback size?",
*av);
>
> The only option left is to assign a higher value to this parameter.
> However I learned, from the hard way, that screen -h 10000000 will
> just hang a system with low resources - screen consumed more than 1GB
> of memory!
>
> Lookin' on the source code for an answer, I noticed that screen
> doesn't perform any boundaries check and will try to maintain
> scrollback entirely in RAM.
>
> On a bad perspective this leads to (another) problem: anyone with
> access to a setuid screen binary (most GNU/Linux distributions have
> this by _default_) can literally hang a production system.
>
> So, does anyone have ideas on how to achieve this without freeze the
system?
>
> Thanks,
>
> R.
>