screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: screen defscrollback memory exhaustion


From: Jürgen Weigert
Subject: Re: screen defscrollback memory exhaustion
Date: Thu, 14 Aug 2014 11:40:05 +0200

No, sorry. It does not work that way. If you ask screen to reserve 10 Million lines of scrollback per window, it will consume a lot of memory. This is normal behavious. Like if you load a 4 GB file into your text editor, it will also consume a lot of memory, and eventually make the system unusable.

I am running my screen sessions with 3000 lines of scrollback ever since. Appears sufficient for most cases.
If you really need the possibility to scroll back infinitly, I'd recommend to check out the logfile options.

cheers, JW-


On Thu, Aug 14, 2014 at 1:53 AM, Ricardo F. Teixeira <address@hidden> wrote:
Hi guys,

Does anyone know how to set the size of the defscrollback buffer to unlimited?

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.

_______________________________________________
screen-users mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/screen-users


reply via email to

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