I have an application running in Wildfly 8.2.1. In addition to the server.log file in the log directory, my application creates and uses other log files too (also in the log directory). They all end in .log. This is dynamic and programmatic using org.apache.log4j.FileAppender, since the names, contents, and number of files differs from one client to the next.
What I'd like is for Wildfly to automatically rotate these log files too in addition to its own (i.e. server.log). I see in standalone.xml there is a periodic-rotating-file-handler tag with a file subtag that has a path attribute. From reading the Wildfly logging documentation, it seems like I can't use wild cards here? So, path="*.log"? Is this true? If so, how can I achieve the end goal of Wildfly automatically rotating my log files instead of doing it myself?
If you'd like to rotate log files you'd need to use a rotating file handler. The periodic-rotating-file-handler will only rotate it's own file not other files associated with other file handlers.
Since you seem to be creating a log4j file appender have a look at the org.apache.log4j.RollingFileAppender.
Related
I am deploying a Spring Boot 2.0.0-RC1 application as an init.d service, but I can't figure out how to configure the log rotation.
The app logs to /var/log/appname.log, but if I configure logrotate the logging stops after a rotation, because a new file is created, and the stdout/stderr redirection defined in the embedded script does not work anymore.
If I configure the log rotation in my logging system there are two problems: I can't create the files in /var/log, and I still have the redirection defined in the embedded script.
What is the proper solution for this?
I'm facing the same problem in several applications and adding copytruncate param is the solution because your Spring Boot application doesn’t understand that the file has changed (truncated) and is acting like a tail -f command (see How does the “tail” command's “-f” parameter work? for details).
Example:
/opt/payara41/glassfish/domains/domain1/logs/* {
daily
copytruncate
rotate 3
dateext
notifempty
}
copytruncate
Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever.
Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log
file stays in place
I found the solution, it's the option copytruncate in logrotate.
My app deployed on Tomcat uses log4j to write a log file. If I delete that file, then the app does not recreate it. I also tried to recreate it manually, but it remains always empty. Is there any way to delete the log file (not from the app), create a new one in the same path with the same name, and that it can be written by the application?
Is there any way to delete the log file (not from the app), create a new one in the same path with the same name, and that it can be written by the application?
Nope. You need to get the application itself to restart logging.
The problem is that the log4j appender still has a handle for the deleted file, and will continue to write to it ... unaware that it has been deleted.
A better approach would be to have the application itself take care of "rotating" the logfile. Look at the classes that implement the log4j Appender interface for some ideas.
My production setup has 1 physical server with 2 weblogic managed nodes running and deployed with a package war file.
The package war file contains the log4j configuration file which specifies the log file to be written to /log/mypath/mylogfile.log.
Will multiple weblogic managed nodes attempting to read/write to the same log file result in file lock/IO issues?
Yes, you will have issues that will prevent the logs from rolling. Adding the the server name as a variable name with alleviate this, but will give you two log files instead of one. The log path will look like this:
/log/mypath/mylogfile.${weblogic.Name}.log
I find that if there is too much logging going on, such as using full debugging to troubleshoot a high volume production system, we can get stuck threads. I have seen this happen with just one managed server, let alone with several. It might depend on log4j version but it has been a periodic problem for us with high log levels.
I know it is possible to reload log4j's xml configuration while the application is running, but the searching I've done only shows how to do this when the XML config file is edited manually via a text editor.
I want to be able to dynamically change the level of the root logger in my application via a web page and persist that change to the log4j XML configuration, so I won't have to change the log level again if I restart the application. Is it possible to do this, or can the log4j XML file only be updated manually?
I am using log4j 1.2 in my application.
Many thanks in advance!
for any chump who finds themselves stuck dealing with this, it is possible to write out the data as properties using
org.apache.log4j.config.PropertyPrinter;
You can acheive this by PropertyConfigurator configure and watch.
Read the configuration file configFilename if it exists. Moreover, a thread will be created that will periodically check if configFilename has been created or modified. The period is determined by the delay argument. If a change or file creation is detected, then configFilename is read to configure log4j.
I've been given the requirement that the first line of my log files must begin with a specific header. This header should specify that this current file is newly created. Even when log files are automatically rotated.
It seems odd but it is in the specification for the project.
Environment info:
App Server: Glassfish V2
Logging: SL4J
I think you're going to have to subclass the relevant appender and add your own code to do this.
The log file is not written by slf4j. It is written by the logging system behind the facade. The solution will depend on what that logging system is.
Unless that logging system has an existing log file appender that does this, you will need to write a custom appender (using the appropriate API, etc) that writes the header each time it opens a new log file.