Proposal to change the behavior of the timestamp place holder (%t) in log file paths

[Kevin Walls]

Also relevant are the jcmd commands that take an output filename.  Those have been updated to take %p pid (JDK-8334492) and there was some thought given to adding time/datestamp.  That didn't get completed but will hopefully still happen.

The title of JDK-8204681 might be out of date, it's not just hprof filenames, but all jcmd output files.  More info in https://github.com/openjdk/jdk/pull/20568

Good to keep these things consistent where we can.  8-)

Thanks
Kevin



-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of David Holmes
Sent: Friday, January 31, 2025 2:58 AM
To: Larry Cable <larry.cable at oracle.com>; Kemper, William <kemperw at amazon.com>; serviceability-dev <serviceability-dev at openjdk.org>; hotspot-runtime-dev at openjdk.org
Subject: Re: Proposal to change the behavior of the timestamp place holder (%t) in log file paths

On 31/01/2025 4:03 am, Laurence Cable wrote:
> On 1/30/25 9:42 AM, Kemper, William wrote:
>>
>> Thank you all for your comments. We've gotten by using the pid (%p) 
>> as a means of grouping log files from a process. The log messages 
>> themselves include the uptime, so having the start time of the JVM in 
>> the file name has not been useful (and it would be trivial to add in 
>> from startup scripts). I take your points about using the 
>> modification time of the files and will consider this.
>>
> 
> is not also the case that "trivial to add in from startup scripts" 
> also true for creation time?
> 
> perhaps propose a new substitution variable instead of redefining the 
> existing one?
> 
> e.g: %c

There has been some recent discussion (which I can't locate) about enabling various filename substitutions that match with the different Unified Logging timestamp decorators. Also Zhengyu just filed JDK-8349083.

David

> - Larry
> 
>> ---------------------------------------------------------------------
>> ---
>> *From:* Laurence Cable <larry.cable at oracle.com>
>> *Sent:* Thursday, January 30, 2025 9:14:53 AM
>> *To:* Kemper, William; serviceability-dev; David Holmes; hotspot- 
>> runtime-dev at openjdk.org
>> *Subject:* RE: [EXTERNAL] Proposal to change the behavior of the 
>> timestamp place holder (%t) in log file paths
>> CAUTION: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you can confirm the sender 
>> and know the content is safe.
>>
>>
>>
>> On 1/29/25 5:56 PM, David Holmes wrote:
>> > Adding back serviceability-dev
>> >
>> > David
>> >
>> > On 30/01/2025 11:55 am, David Holmes wrote:
>> >> Plus one to what Kevin says. The current specified behaviour seems 
>> >> to me to be what would be generally desired. If there is a desire 
>> >> for a different kind of timestamp to be used then a proposal to 
>> >> add that would be more appropriate I think. I seem to recall 
>> >> something fairly recent about expanding the notion of "timestamp" that can be used here.
>>
>> +2 for Kevin and David's observations; changing the timestamp from 
>> +JVM
>> start time to create time, removes valuable and otherwise 
>> unobtainable (correlation) metadata from the logfile names, file 
>> creation and modification time is available from the underlying O.S 
>> filesystem if needed.
>>
>> Rgds
>>
>> - Larry
>>
>> >>
>> >> David
>> >>
>> >> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>> >>> Hi,
>> >>>
>> >>> Just checking, but are they sure that's what they want? 8-)
>> >>>
>> >>> This relates to files from unified logging, like java - 
>> >>> Xlog:gc*:file%t.out ...creates: file2025-01-28_21-43-53.out and - 
>> >>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they 
>> >>> will expand to the JVM's PID, startup timestamp and host name, 
>> >>> respectively."
>> >>>
>> >>> (Administratively, I think unified logging is under the runtime 
>> >>> group, cc’d.)
>> >>>
>> >>> Using the JVM start time, across all log files, identifies the 
>> >>> set of files that come from the same process.  They will 
>> >>> generally sort together when viewing a directory.  If a single 
>> >>> file gets copied around, it can still be traced back in its 
>> >>> group.   When there are multiple sets of logs in the same 
>> >>> directory, the sets should still sort together.   I see the 
>> >>> filename purpose as to identify the log, or set of logs.
>> >>>
>> >>> Using a new timestamp for each file, the filenames do not 
>> >>> identify the files as being part of the same run.  They may sort 
>> >>> together, but may not if another log series is in the same 
>> >>> directory, and once separated it's hard to regroup them.
>> >>>
>> >>> Using the pid as well will help, but if we see a lot of 
>> >>> low-numbered PIDs then this won't be unique. (With the current 
>> >>> startup timestamp, you will probably use %p for pid in the file 
>> >>> as well, in case JVMs start at the same moment.)
>> >>>
>> >>> Thanks
>> >>>
>> >>> Kevin
>> >>>
>> >>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> 
>> >>> *On Behalf Of *Kemper, William
>> >>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>> >>> *To:* serviceability-dev at openjdk.org
>> >>> *Subject:* Proposal to change the behavior of the timestamp place 
>> >>> holder (%t) in log file paths
>> >>>
>> >>> The timestamp place holder in a log filename currently expands to 
>> >>> the startup time of the JVM. When the log is rotated, the 
>> >>> filename containing this timestamp is suffixed with a file 
>> >>> number. My colleagues had expected the placeholder to be 
>> >>> evaluated when the current log file is rotated. They expected the 
>> >>> name of each rotated file to indicate the time the file was 
>> >>> created. I think this expectation is not unreasonable, so I 
>> >>> wanted to discuss the possibility of changing how/when the 
>> >>> timestamp placeholder is evaluated. If there is any appetite for 
>> >>> a change like this, I am willing to do the work. I would prefer 
>> >>> to sort out the details before coding anything, rather than 
>> >>> discussing them in a surprise pull request.
>> >>>
>> >>> Thank you for reading,
>> >>>
>> >>> William
>> >>>
>> >>
>> >
>>
>