We have configured both log4j.xml and log4j2.xml for our application due to certain limitations.
The legacy rolling file appender is configured in log4j.xml and the same file appender is used in log4j2.xml. The logs are written to the same file until the threshold for rolling reached. When a new backup file created, the logs defined in log4j2.xml are still writing to the backup file instead of the main file. Is there any way to solve this problem?
Related
I was asked to assist in debugging a peculiar issue, related to log4J.
They are facing issues with the rolling file appender. There are multiple EJB applications writing to the same log file. Each application has its own log4j.properties.
Issue: The latest log files are being written to a file trace.log.x instead of trace.log. Is there any setting which needs to be added? I could not really find an anomaly. Below are the settings.
log4j.rootLogger=INFO, A3
log4j.appender.A3=org.apache.log4j.RollingFileAppender
log4j.appender.A3=org.apache.log4j.RollingFileAppender
log4j.appender.A3.File=$variable/trace.log
log4j.appender.A3.MaxFileSize=10MB
log4j.appender.A3.MaxBackupIndex=5
I was wondering if I need to set the log4j at the server level instead of the app level. I don't like the idea though. I am not in favour of log file being shared. There is no log file corruption, but looks like the wrong file is getting updated
I am running a executable jar file, which logs using log4j.xml(version 1.2).
Whenever i change the log level in the xml file, i have to restart the java application for the new log level to reflect.
Can i add some configuration in the log4j.xml so that new log level will be taken into account without application restart?
Thanks,
-Venkat
Log4j 1.x has reached end of life on August 5, 2015. So I would like to recommend you to use log4j 2.x which supports this with the monitorInterval configuration.
However according to the log4j 1.x docs here it does support log level changes runtime.
How can I change log behavior at runtime?
Log behavior can be set using configuration files which are parsed at
runtime. Using configuration files the programmer can define loggers
and set their levels.
The PropertyConfigurator defines a particular format of a
configuration file. See also the examples/Sort.java example and
associated configuration files.
Configuration files can be specified in XML. See log4j.dtd and
org.log4j.xml.DOMConfigurator for more details.
See the various Layout and Appender components for specific
configuration options.
In addition to configuration files, the user may disable all messages
belonging to a set of levels. See next item.
I'm using Log4j for logging my system events.
Initially I used the Log4j properties file and then shifted to log4j.xml file.
My application has another property file - system.properties - that takes the configuration parameters.
I want the log output file to be specified in the application properties file - system.properties and refer the properties file in the log4j.xml file and also update the configuration.
Is it possible with this log4j.xml configuration?
You can do it by using ant scripts. Load the system.properties file in ant and replace the value inside the log4j.xml file.
Refer to this link on how to update XML file.
How to update an XML document with Ant
I have an application running on Websphere in a Windows server environment utilizing log4j. The system is logging and appears to be adhering to the MaxFileSize limit as defined in the log4j.properties (20KB - see below), but is not rolling the log files. Rather, it is simply overwriting the existing log file.
Here is my log4j.properties file defined in Websphere:
log4j.rootLogger=debug, file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=F:\\<log_file_directory\\<log_file_name>.log
log4j.appender.file.MaxFileSize=20KB
log4j.appender.file.MaxBackupIndex=50
log4j.appender.file.Append=true
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
My theory is that the application / JVM is holding on to a reference to the log file when log4j tries to roll the file, and that Windows is seeing that file in use and preventing it from being moved. But I don't know this for sure.
Anyone see any reason why the log files wouldn't be rolling over? Or could my theory be correct?
The solution to my problem was to set up log4j as a shared jar file within WebSphere. Each individual application had a file descriptor open to log4j, preventing the logs from rolling when they hit the MaxFileSize.
Once I set up log4j as a shared jar and bounced the server, the logs rolled as expected. I tested this with multiple sizes for MaxFileSize and all worked as expected.
I have a jar file which internally use log file to write messages. Using this jar I have developed a Perl module. The usage of this module is across out firm. So I have given 666 permissions on all the log files so that everyone can use the module. The issue is the jar file internally uses log4j and the appender is DailyRollingFileAppender which is resetting the permissions on the log files to 664 after rolling and certain people are not able to use the module.
Is there a way to mention to log4j to retain the existing permissions of the log file ? If not, can anyone suggest alternative ?
This is the responsibility of the operating system. When Log4j rolls a log, the OS will create that new file according to its own rules.
You should be able to reproduce this manually, by opening a shell in the log directory and running touch testfile - the file testfile should exhibit the same permissions as new log4j files.
You need to look at the file permissions on the directory, those that are inherited by new files in that directory. You may also need to tinker with the user's umask setting.
If you can reproduce the problem without using log4j or java, then it becomes easier to solve, but would be best asked on superuser.com.