RFR: 8146879: Truncate new UL log files

Stefan Särne stefan.sarne at oracle.com
Fri Jan 15 13:15:21 UTC 2016


I will second what others have already said.

I do not think the existing logs should be removed (even if this has 
been the case before).

A quite likely scenario is that when a critical application hangs, crash 
or misbehaves, a quick restart is done. After the service is up again, 
the detective work starts to understand why it happened and if the jvm 
log is truncated, one good source of info would be lost.

So I would expect default is to either append (or backup earlier log) 
and to also log rotate.

Cheers,
Stefan



Den 2016-01-15 kl. 10:58, skrev Dmitry Samersoff:
> Marcus,
>
> Generally speaking (out of scope of this changes)
>
> 1. Appending (i.e. seek before write) isn't free
> 2. I'm against of overwriting the log on restart.
>
> So personally, I would prefer:
>
> a) Have a /signal/DCMD/linecount threshold/ that cause VM to close
> existing log file and start new one with a simple numbering (i.e. close
> jvm.log.001 start jvm.log.002)
>
> b) Print clear visible banner to a log on JVM start and continue writing
> to the same file.
>
> c) Implement syslog support.
>
> Leave everything else to variety of log management tools that allows to
> implement wide variety of security and rotation policies.
>
> -Dmitry
>
>
> On 2016-01-15 12:27, Bengt Rutisson wrote:
>>
>> On 2016-01-14 23:43, Kim Barrett wrote:
>>> On Jan 14, 2016, at 10:00 AM, Marcus Larsson
>>> <marcus.larsson at oracle.com> wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to make sure UL truncates existing
>>>> log files before writing to them. Since files are opened in append
>>>> mode, truncation isn't done automatically, so instead the patch adds
>>>> an attempt to remove the log file before opening it.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>
>>>> Testing:
>>>> Included test through JPRT
>>>>
>>>> Thanks,
>>>> Marcus
>>> Deleting possibly critical data seems like a good way to generate a
>>> mob of angry users.
>>
>> The GC log has always been overwritten on a restart. The propsed change
>> to the UL file handling makes the log files work similar to how they
>> used to work. So, I think we will get less problems with users after
>> this change than before it.
>>
>> Bengt
>



More information about the serviceability-dev mailing list