Bug 990197

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.

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.

(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

(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

Created attachment 782987 [details]
make konsole history use kde cache instead of kde tmp

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.

(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

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

(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

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.

(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?

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

Sorry for the extended delay, I'd kinda forgotten about this.

%changelog
* Tue Sep 23 2014 Rex Dieter <rdieter> 4.14.1-2
- do not store history in /tmp (#990197)

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

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

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

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.

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.