On 6/22/19 3:07 AM, David Holmes wrote:
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. :(
I don't know if there is a way to reliably associate a file with an
"owning" process. Sure /tmp/.java_pid<pid> has the process ID encoded in
its name, but that is java specific and a generic cron job knows nothing
about that pattern by default. If the process still has the file open,
there is a way to detect that and "tmpwatch" for example has an option
--fuser that skips open files. There are other tools for managing
temporary files that can't do that (systemd-tmpfiles for example) and
only use file's timestamps to determine if the file is still "alive" or
not...
Regards, Peter
Cheers,
David
