I found a weird pattern of active jboss logs turning binary when I try to nullify them on RedHat boxes.
I have multiple boxes with different versions on JBoss (eap 4.3 and 5.1) and RedHat (5.9, 6.2) and they all act the same.
Here is what happens:
I have an active server.log or stdout.log that is being used by a running JBoss jvm. Sometimes this file grows big and I need to "rotate it". I normally gzip it with -c argument and then nullify the original log.
I tried to do so by using "cat /dev/null/ > server.log", "> server.log", "cp /dev/null/ server.log" and in all cases ASCII server.log turns binary after that operation.
I tried to create an empty txt file and do the same "cat empty.txt > server.log" and "cp empty.txt server.log" with the same result
I also tried to create a small txt file with some ASCII text in it like "rotating logs" and also either cat it or copy it into server.log.
In all this cases server.log turns binary looking like this:
Have anyone run into something like this before?
What is the proper way to rotate active logs so they remain ASCII?
It's a prod environment so I can't restart jvms in the middle of the day. Daily log rotate is configured, but from time to time we need to do the rotation in the middle of the day.
I know that there is an option to remove server.log completely and then force log rotation from the web console, but we don't have web console access on most boxes, so it's not so much of an option for me.
Any suggestions are appreciated.
I suppose it depend on the implementation what happen if you do such things. Maybe the file is not longer reachable but the logger write to it as long as the JVM is stopped.
What you might do is set append=false and touch the log4j configuration. In that case a new logfile will be created.