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

[Laurence Cable]

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

- 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
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250130/ab9607b4/attachment-0001.htm>