Hi David,
On 6/21/19 5:57 PM, David Holmes wrote:
Hi Peter,
On 21/06/2019 7:55 am, Peter Levart wrote:
As far as I know, cron jobs that cleanup /tmp typically remove files
that have not been modified for a while.
On Fedora for example, there is a systemd timer that triggers once
per day and executes systemd-tmpfiles which manages volatile and
temporary files and directories. The configuration for /tmp is the
following:
# Clear tmp directories separately, to make them easier to override
q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d
The age field (10 days for /tmp) has the following meaning:
The age of a file system entry is determined from its last
modification timestamp (mtime), its last access timestamp (atime),
and (except for directories) its last status change
timestamp (ctime). Any of these three (or two) values will
prevent cleanup if it is more recent than the current time minus the
age field.
So the solution could be for attach thread (if it is already started)
to update mtime or ctime of the .java_pid<pid> socket file
periodically so cleanup job would leave it alone.
What do you think?
I'm not keen on having the attach listener thread periodically wakeup
just to do this.
The required frequency would be very low. Once a day would be more than
enough. cron jobs are usually set-up to remove files that have not been
touched for several days.
Can we not change permissions to protect the file form external
deletion and ensure the VM cleans it up itself?
If VM crashes, the file is not deleted and it would be wrong if it
persisted forever (or until reboot) because of permissions. Besides, I
don't think there is a (portable, POSIX) permission that would prevent
removing the file since cron job executes as root to be able to remove
files created by several users. /tmp directory normally has "sticky" bit
set, meaning that anybody can create files in it (ugo+w permission), but
only owner of the file or owner of the dir or root can delete the file.
cron jobs that remove /tmp files are set-up for the following reason:
Processes usually clean-up after themselves but this is not guaranteed
if they terminate with a crash or unhandleable signal (such as KILL).
Regards, Peter
David
Regards, Peter
On 6/20/19 10:49 PM, David Holmes wrote:
Sorry it took me a while to understand the specifics of the problem. :)
David
On 20/06/2019 3:37 am, nijiaben wrote:
Yes Alan, I mean this
------------------ Original ------------------
*From: * "Alan Bateman"<alan.bate...@oracle.com>;
*Date: * Thu, Jun 20, 2019 02:54 PM
*To: * "nijiaben"<nijia...@perfma.com>; "David
Holmes"<david.hol...@oracle.com>;
"serviceability-dev"<serviceability-dev@openjdk.java.net>;
"jdk8u-dev"<jdk8u-...@openjdk.java.net>;
"hotspot-runtime-dev"<hotspot-runtime-...@openjdk.java.net>;
*Subject: * Re: A Bug about the JVM Attach mechanism
On 20/06/2019 05:10, nijiaben wrote:
> :
> I know this mechanism, can we provide means of recovery to avoid
unavailability caused by accidental deletion?
>
Are you concerned about tmpreaper or cron jobs that periodically
cleanup
/tmp? There may indeed be an issue for applications that run for weeks
or months. If someone is using jmap, jcmd or other tools using the
attach API then it will trigger the attach listener to start. When
they
come back in a few weeks then the .java_pid<pid> file may have been
removed so they cannot attach. Is this what what you are pointing out?
-Alan
