4

I'm using java.util.logging for a project and am having a problem with the configuration. I have a logging.properties file that I know is being read because e.g. changes to level and filehandler pattern take effect.

The problem is that even though I attempt to force the existence of only one log file java.util.logging insists on creating additional ones. I have read the docs and here is an example configuration for the FileHandler:

java.util.logging.FileHandler.pattern = server.log
java.util.logging.FileHandler.limit = 500000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.append = false
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

The result is that files get created as server.log.1, server.log.2 etc. Ideally I don't want append to be true (does not seem to make a difference...), I just want a new log file to be created every time I start my program, potentially overwriting an existing file. At any time, there should be no more than count log files in my directory.

Changing append and count does not seem to make any difference. Using %u and %g etc. in the pattern does not seem to make much of a difference either. I still keep getting server.log.n files which clutters the directory.

Each created file also has an accompanying .lck file. Why are they created and could they be the culprit?

Edit:

Don't know why I didn't try this before, but manually removing the .lck files results in things working as desired. So the question now really is: why are .lck files created (improper shutdown?) and how can that be handled?

UmaN
  • 905
  • 1
  • 15
  • 29
  • Lock files are removed when the FileHandler is closed. Normally the FileHandler is closed when the shutdown hook j.u.l.LogManager$Cleaner completes. You mention that you are forcing shutdown with cltr-c. I would assume that the shutdown hook is not executed in that case. – jmehrens Mar 05 '14 at 23:08
  • As you point out, the constructor of LogManager does: Runtime.getRuntime().addShutdownHook(new Cleaner()); . This is supposed to intercept ctrl-c type shutdowns. – UmaN Mar 06 '14 at 11:53

1 Answers1

2

This only happens when the FileHandler detects that the server.log file is locked. You either have two JVMs running at the same time, two instances of a FileHandler open at the same time pointing to the same file name, or another process is locking the server.log file before the FileHandler is opened.

Related: Is java.util.logging.FileHandler in Java 8 broken?, JavaLogger randomly writes to a second file and FileLock.

Community
  • 1
  • 1
jmehrens
  • 10,580
  • 1
  • 38
  • 47
  • That seems like it could be true. However... I am starting my server from a script in a cygwin environment. Forcing it to shutdown with cltr-c leaves no process remaining. I can start the server again and bind to the same port with no problem. Then I can only imagine it is a cygwin problem. But there's no problem just deleting the log files, they don't appear to be locked... – UmaN Mar 05 '14 at 12:48
  • I added a link to the answer. Log the JVM pid on startup then compare the ids in each log file. – jmehrens Mar 05 '14 at 19:11
  • I added code for this, but I don't understand what I am supposed to compare? The pids in the log files are different and ps afterwards show none of these processes still running. – UmaN Mar 06 '14 at 12:02
  • It is possible that cygwin doesn't perform the file locking as expected. Delete all log and lck files. Perform one start and one stop of your job. What files remain and what PIDs are in them? – jmehrens Mar 06 '14 at 20:35