A Bug about the JVM Attach mechanism

[David Holmes]

On 21/06/2019 11:57 am, Peter Levart wrote:
> 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.

I would have thought it more prudent to remove files for which the 
owning process no longer exists. :(

Cheers,
David
-----

>> 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.Bateman at oracle.com>;
>>>>> *Date: * Thu, Jun 20, 2019 02:54 PM
>>>>> *To: * "nijiaben"<nijiaben at perfma.com>; "David 
>>>>> Holmes"<david.holmes at oracle.com>; 
>>>>> "serviceability-dev"<serviceability-dev at openjdk.java.net>; 
>>>>> "jdk8u-dev"<jdk8u-dev at openjdk.java.net>; 
>>>>> "hotspot-runtime-dev"<hotspot-runtime-dev at 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
>>>
>