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

[David Holmes]

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
>> >>>
>> >>
>> >
>>
>