Bug 990197 - do not store history in /tmp
do not store history in /tmp
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: konsole (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F18TmpOnTmpfs
  Show dependency treegraph
 
Reported: 2013-07-30 10:41 EDT by Karel Volný
Modified: 2015-05-15 12:14 EDT (History)
6 users (show)

See Also:
Fixed In Version: konsole-4.11.5-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-29 00:07:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
make konsole history use kde cache instead of kde tmp (500 bytes, patch)
2013-08-05 15:33 EDT, Rex Dieter
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 173283 None None None Never

  None (edit)
Description Karel Volný 2013-07-30 10:41:16 EDT
Description of problem:
My system just broke because of running out of space in /tmp
Please change the default konsole configuration not to store history in /tmp (or, possibly the whole KDE not to use /tmp/kde-something).
Oh, and next time, remember whom (not) to vote for FESCo.[*]

Version-Release number of selected component (if applicable):
konsole-4.10.5-1.fc19.x86_64

How reproducible:
always

Steps to Reproduce:
1. run konsole
2. enable unlimited history
3. run something with lots of output

Actual results:
after a while (as the konsole history fills space of the size of half of your RAM), you start seeing various breakages, abrt reporting crashes that it is unable to process, commands spitting out errors on trivial operations etc.

Expected results:
no such problems

Additional info:
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
[*] https://lists.fedoraproject.org/pipermail/devel/2012-December/174883.html
Comment 1 Kevin Kofler 2013-08-03 06:48:54 EDT
IMHO:
systemctl mask tmp.mount
and move on. And fight on to get this "feature" reverted.

The whole point of creating a temporary file is so that it is NOT in RAM. tmp-on-tmpfs is a completely broken-by-design and useless "feature". And as I understand it, KDE upstream does not support it at all. It is not realistic to make KDE work properly with that screwed-up setup.
Comment 2 Kevin Kofler 2013-08-03 07:03:20 EDT
To elaborate on this:
The issue is that /tmp served 2 use cases:
1. to communicate between applications, when a file is required and
2. to put stuff on disk rather than in RAM.

tmp-on-tmpfs improves performance for the apps in category 1, but requires the apps in category 2 to adapt, by moving to /var/tmp. The correct implementation would have been to create a new tmpfs in, say, /run/tmp, and to adapt the apps in category 1 instead! That would have been both:
* compatible, because the semantics of /tmp would not have changed unexpectedly, and
* safe, because a category 1 app not adapted to /run/tmp would just have meant a minor performance hit (which has always been there), whereas a category 2 app not adapted to tmp-on-tmpfs does not work at all and can even crash the whole system!

The way this has been forced through really sucks. In particular, the FESCo policies need to be fixed so that a +4, -4 stalemate always means the feature is rejected, even if it was previously approved! In other words, reconsidering a feature should mean the approval is considered null and void and there is a new feature approval vote (which requires +5 to pass), NOT that there's a "feature approval revocation" vote which requires +5 to revert the feature. This tmp-on-tmpfs catastrophe would have been averted if reconsidering a feature were implemented properly in the policies. It just does not make sense that a feature that was approved by mistake (due to missing facts or outright false advertising) needs to pass a lower bar to stay approved than a feature that hasn't been voted on yet.
Comment 3 Karel Volný 2013-08-05 04:25:16 EDT
(In reply to Kevin Kofler from comment #1)
> IMHO:
> systemctl mask tmp.mount
> and move on.

does not work for me ... I mean, this helps the machine it is run on but it wouldn't disable this crap for all the machines I manage and will install in the future, for once and all

> And fight on to get this "feature" reverted.

I'll gladly do, just tell me what can I do so that it has any effect ...?

> The whole point of creating a temporary file is so that it is NOT in RAM.
...
> To elaborate on this:
...

no need to tell me, I've watched the case

unfortunately, seems we're stuck with this nonsense, so let's try at least mitigate the effects

if someone breaks my right arm, I just have to learn scratch my right ear with left hand

...
> does not make sense that a feature that was approved by mistake (due to
> missing facts or outright false advertising) needs to pass a lower bar to
> stay approved than a feature that hasn't been voted on yet.

just to add to this, it was pretty disgusting to hear arguments like "this can be reconsidered and reverted if testing shows problems" and then the "reconsideration" took place before any testing was done - because there were troubles with the installer (to put it euphemistically) there was about zero people running a fresh install that would include tmp-on-tmpfs by the time of the second vote
Comment 4 Karel Volný 2013-08-05 04:38:18 EDT
(In reply to Kevin Kofler from comment #2)
> ... outright false advertising ...

oh, I cannot resist ...

"Debian's next release defaults to tmpfs on /tmp, too."[1]

"Debian is a very conservative distro. I would not expect them to be the first ones to adopt this."
...
"Maybe we should focus on our own bugs, instead of staying stuck in fear of bugs in Debian."[2]

so, when Debian does (plans to do) the same, it is a good reason why to do it, but when Debian does not do the same, we just don't care about Debian, hmmm

(I mention that as the false advertising on [1] is still unfixed)

[1] http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
[2] https://fedorahosted.org/fesco/ticket/940
Comment 5 Rex Dieter 2013-08-05 15:33:58 EDT
Created attachment 782987 [details]
make konsole history use kde cache instead of kde tmp
Comment 6 Kevin Kofler 2013-08-05 18:31:00 EDT
But it's not a cache, it's a temporary file.

Interestingly, my KDE "tmp" path is ~/.kde/tmp-localhost.localdomain and it's a real directory, not a symlink.
Comment 7 Karel Volný 2013-08-07 10:04:27 EDT
(In reply to Kevin Kofler from comment #6)
> Interestingly, my KDE "tmp" path is ~/.kde/tmp-localhost.localdomain and
> it's a real directory, not a symlink.

lucky you ...

$ ls -l .kde/tmp*
lrwxrwxrwx. 1 kvolny kvolny 15  1. lis  2012 .kde/tmp-kvolny.[some internal domain].com -> /tmp/kde-kvolny
lrwxrwxrwx. 1 kvolny kvolny 15  1. lis  2012 .kde/tmp-kvolny.[another internal domain].com -> /tmp/kde-kvolny

I wouldn't mind if KDE would store such files in ~ instead of /tmp
Comment 8 Rex Dieter 2013-08-07 10:08:25 EDT
You're welcome to set/define env var KDETMP to point anywhere you like.  See also:
http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
Comment 9 Karel Volný 2013-08-07 10:52:13 EDT
(In reply to Rex Dieter from comment #8)
> You're welcome to set/define env var KDETMP to point anywhere you like.

ok, I can reconfigure lots of things, but the question is what should be the default for Fedora so that the unsuspecting users do not run into troubles with limited /tmp space ... breaking something by choosing insane default and then telling people "you can reconfigure" it is not a nice thing to do, and when one default setting has been broken already and it doesn't seem it is going to be fixed, it'd be nice to compensate by adjusting the other default setting ...

> See also:
> http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy

thanks
Comment 10 Rex Dieter 2013-08-07 10:57:46 EDT
I'm not disagreeing with you, at all.  I'm the one who made the proposed patch to move this out of /tmp (ala KDETMP) by default, after all (see comment #5)

I was simply giving a response to satisfy your comment:
"I wouldn't mind if KDE would store such files in ~ instead of /tmp"
to highlight that is indeed possible to do, if you choose.
Comment 11 Karel Volný 2013-08-08 07:41:24 EDT
(In reply to Rex Dieter from comment #10)
> I was simply giving a response to satisfy your comment:
> "I wouldn't mind if KDE would store such files in ~ instead of /tmp"
> to highlight that is indeed possible to do, if you choose.

sorry for not being explicit enough, I've meant not just my system, but rather as the configuration default ... what are the reasons to store user data outside user's home?

I can imagine remotely mounted home scenario where it may cost bandwidth, but I'm not sure how common Fedora use case would that be; anything else against moving from /tmp to ~/.kde/tmp?
Comment 12 Rex Dieter 2013-08-08 07:53:31 EDT
I'm not privy to the full history behind it, but I believe a primary factor was that these items need a guarantee to be on local filesystems, hence, they live in /tmp and /var/tmp by default
Comment 13 Rex Dieter 2014-09-23 12:53:10 EDT
Sorry for the extended delay, I'd kinda forgotten about this.

%changelog
* Tue Sep 23 2014 Rex Dieter <rdieter@fedoraproject.org> 4.14.1-2
- do not store history in /tmp (#990197)
Comment 14 Fedora Update System 2014-09-23 14:49:12 EDT
konsole-4.14.1-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/konsole-4.14.1-2.fc21
Comment 15 Fedora Update System 2014-09-23 14:50:48 EDT
konsole-4.11.5-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/konsole-4.11.5-2.fc19
Comment 16 Fedora Update System 2014-09-24 14:26:57 EDT
Package konsole-4.14.1-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing konsole-4.14.1-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11303/konsole-4.14.1-2.fc21
then log in and leave karma (feedback).
Comment 17 Fedora Update System 2014-09-29 00:07:29 EDT
konsole-4.14.1-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2014-10-03 23:26:25 EDT
konsole-4.11.5-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.