Description of problem:
when using gnome-terminal log files are stored in /tmp/vte* however these files are unseen to the general user because they are in a deleted state. If you do an lsof | grep gnome-ter you will get something similar to the following out put:
gnome-ter 24040 hward 25u REG 0,19 1283 26129698 /tmp/vteXAA8UY (deleted)
gnome-ter 24040 hward 26u REG 0,19 1056 26129699 /tmp/vteMBB8UY (deleted)
gnome-ter 24040 hward 27u REG 0,19 512 26129700 /tmp/vteXJC8UY (deleted)
Version-Release number of selected component (if applicable):
After performing operations from the gnome-terminal, in lsof | grep gnome-ter, you will find files /tmp/vte* (deleted).
/tmp is getting filled up
/tmp shouldn't get filled up
It seems as if these log files get opened then deleted then written to and only closed once the terminal has been exited, these files are normally not a big deal unless a lot of command line work or keep your terminal open for about a week or more. The correct order of operations for these log files should be to create them, open them, write to them, then close and delete them.
These files contain the scrollback buffer (at most 12 files per terminal – this has been significantly improved since then), and they are closed whenever you close the corresponding terminal. In order to limit the amount of data written to them, choose a proper number of scrollback lines in your profile prefs.
(In reply to Egmont Koblinger from comment #1)
> These files contain the scrollback buffer (at most 12 files per terminal –
> this has been significantly improved since then), and they are closed
> whenever you close the corresponding terminal. In order to limit the amount
> of data written to them, choose a proper number of scrollback lines in your
> profile prefs.
More specifically, since 0.40.x vte does compress the scrollback buffer with zlib:
Author: Egmont Koblinger <firstname.lastname@example.org>
Date: Sun Dec 14 23:14:30 2014 +0100
stream: Compress data with zlib
Compression is implemented in "boa", a new layer between the "snake" storing
64kB units and the buffering layer. Each 64kB unit is compressed separately,
and we rely on the file system leaving sparse blocks.
See bug for the RHEL 7.x counterpart of this.
(In reply to Debarshi Ray from comment #4)
> See bug for the RHEL 7.x counterpart of this.
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
The official life cycle policy can be reviewed here:
This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: