RFR: 8146879: Truncate new UL log files

[Marcus Larsson]

Hi,

On 01/15/2016 02:15 PM, Stefan Särne wrote:
>
> 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.

Alright, I'm convinced. Defaulting to appending rather than overwriting 
seems like a slightly better default.

I'll update the patch to make this a configurable option where appending 
is the default.

Thanks,
Marcus

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