RFR: 8146879: Truncate new UL log files

Dmitry Samersoff dmitry.samersoff at oracle.com
Fri Jan 15 09:58:06 UTC 2016


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


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


More information about the serviceability-dev mailing list