In F15 systemd's tmpfiles logic is used to clean up /tmp from time to time. As it appears /tmp/hsperfdata_* needs to be excluded from that. (Though I do wonder why these files are stored in /tmp if they cannot be deleted without ill effects... They probably should moved somewhere else eventually). Please include a drop-in file /etc/tmpfiles.d/openjdk with the following contents to your package: <snip> x /tmp/hsperfdata_* </snip> This will teach the tmpfiles mechanism to ignore these files when cleaning up. For details about this see tmpfiles.d(5) and systemd-tmpfiles(8). We prefer having these per-package rules in the packages themselves instead the boot scripts. This rule will work only with systemd v18, which is still on its way through bodhi. Relevant bugs: https://bugzilla.redhat.com/show_bug.cgi?id=674194 https://bugzilla.redhat.com/show_bug.cgi?id=527425
As far as i know, those files my be deleted without ill influence. They SOMETIMES causes troubles, when hotspot is running and using this files when they are deleted. Can you be more specific?
If you have a long-running VM, but never use jps/jstat, the PID-named file in /tmp/hsperfdata_${user}/${PID} will have atime of the last time the VM was started. So the files may be eventually deleted, and following attempts to use jps/jstat will fail. See the two bugs in comment 0. The correct place for those files would probably be somewhere in /var/run, see bug 527425 comment 7.
Created attachment 479424 [details] proposed patch
(In reply to comment #2) > The correct place for those files would probably be somewhere in /var/run, see > bug 527425 comment 7. Nah, /var/run is for PID files and sockets and stuff. I think /var/lib/openjdk/ is probably a better place.
Patch looks fine, but I actually made a mistake above: The file needs to be called /etc/tmpfiles.d/openjdk.conf, i.e. the suffix ".conf" matters, since we ignore all files dropped in there with a different suffix to avoid those rpm save files.
(In reply to comment #4) > (In reply to comment #2) > > The correct place for those files would probably be somewhere in /var/run, see > > bug 527425 comment 7. > > Nah, /var/run is for PID files and sockets and stuff. > > I think /var/lib/openjdk/ is probably a better place. Pardon my ignorance, but do you have any pointers to how to setup such a place to store these user files? Upstream obviously uses /tmp because that is the only guaranteed place on any system to store random file independent of the user/id executing the process. It could be made configurable of course. But is there a good guide for how to set this up (so that it works both for distros that support such a special place, and for people who might build and run their java binaries self-compiled and/or on some older system?)
Hmm, so this is per-user data? Why not place it in $HOME/.openjdk/ then?
(In reply to comment #7) > Hmm, so this is per-user data? Why not place it in $HOME/.openjdk/ then? Yes it is. That is why the directory the pid files are stored in is called hsperfdata_${user}. But if they are stored in some directory under $HOME, then they won't be automagically removed are they? I believe they are stored under /tmp because the process could crash or terminate unexpectedly, and so some way is needed to clean up afterwards.
(In reply to comment #8) > But if they are stored in some directory under $HOME, then they won't be > automagically removed are they? I believe they are stored under /tmp > because the process could crash or terminate unexpectedly, and so some > way is needed to clean up afterwards. But the bug report is about the fact that we should *not* remove them automatically. i.e. Apparently those files are written using mmap() which does not update mtime, and hence the cleanup tools would -- if this file is not explicitly excluded -- assume that the files have not been accessed in ages and removes them. The summary: If they are supposed to be removed eventually, then we can drop the exclusion, but the Java tools would have to update the mtime from time to time manually. If they are not supposed to be removed eventually, then they should be moved to ~/.openjdk/ (or maybe something following the XDG basedir spec). Note that placing files in /tmp with a guessable name (such as the username or PID of the caller) is unsafe anyway, since it allows attackers to just take the names you might want to use later on and hence block you from running your profiler.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping