screen-users
[Top][All Lists]
Advanced

[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.
> 







reply via email to

[Prev in Thread] Current Thread [Next in Thread]