I'm developing web application which has commons-logging.jar and for logging log4j.jar.
I got the following message when server start up.
log4j:WARN No appenders could be found for logger (org.apache.struts.util.PropertyMessageResources).
log4j:WARN Please initialize the log4j system properly.
But still log file is created and the format also same as specified in the log4j.properties.
The application log file is creating in Windows environment, But not in Unix environment.
Why it is not creating log file in UNIX ? Folder has write permissions..
Any idea?
Laxman Chowdary
The message you get on server startup is just a warning, your log file should be created inspite of it (you can find an explanation for the message in this post).
Why the file is created in Windows but it doesn't get created in Unix could be caused by lots of reasons: permissions for the user under which your application is running are first, maybe the configured path is still a Windows path (e.g. containing C:\ maybe), perhaps you meant to use an absolute path and forgot to prepend the / to it...
it's hard to say without seeing your configuration. Check these first and maybe update the question with the configs you are using.
Sometimes what can happen is that you use a relative path for the file and the file gets created relative to some folder in Windows and you expect it to be the same in Unix. But the "current folder" might be another in Unix. Maybe the file gets created but it's located in another place? Try searching for it on disk...
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 have Node.js application which is running under Linux system and uses log4js logging library. Log files are daily rolled by Linux rolling system. The question is the following: somebody know how force the log4js to recreate and use original log file when it's renamed somehow?
Note, Log4js continue writes log into renamed file (seems, stream descriptor is kept).
Please note also that I don't want to use log4js DaylyRollingFileAppender because my log folder contains log files generated by various languages (Java, Python, JavaScript, Bash...).
I assume that you use logrotate.
You can try using 'reload' directive in logrotate config file. (see for details: http://www.linuxcommand.org/man_pages/logrotate8.html)
It seems like that log3js can handle SIGHUP. (Issue: https://github.com/nomiddlename/log4js-node/issues/343, Pull request: https://github.com/nomiddlename/log4js-node/pull/403)
Secondary solution is configure it to use 'copytruncate' directive, but it has trade-offs:
https://serverfault.com/questions/688658/rsyslog-with-logrotate-reload-rsyslog-vs-copytruncate
I am trying to use log4j logging framework in a java desktop application.
When I run the code I am getting a message
log4j: log4j:WARN No appenders could be found for logger
I googled for the above error and found that it occurs when the log4j.properties file is not found by the app.
I am creating the desktop app using Eclipse. Currently log4j.properties is within the same folder that contains the source (in 'src' folder). Where should I put this file to make it work properly?
log4j will use a Default Initialization Procedure to find your configuration file. The documentation notes:
The preferred way to specify the default initialization file is through the log4j.configuration system property
If this property is not set - log4j will look at the classpath. In your case you have to place the file in the src directory (assumed that the content will be put in the classes path while you build the system). If you use maven place the file to the src/main/resources directory.
As you placed your file to the src directory check, that the file get transferred to the top level directory of your compiled classes.
Keep the properties file in the classes folder i.e. the folder that contains the classes (specially the main class).
Another reason for getting this error may be the wrong appenders or an appender without setting.
When I start the JBoss server to run my JSP page, it gives the error as:
Failed to create directory structure: C:\Program Files\jboss-4.2.2.GA\server\default\log
and then a pop-up appears saying
Starting JBoss v4.2 at localhost has encountered a problem.
Server JBoss v4.2 at localhost failed to start.
Please tell me what to do?
When starting for the first time for a certain configuration (here being default, if they are not already present, JBoss creates the directories:
$JBOSS_HOME\server\default\data
$JBOSS_HOME\server\default\log
$JBOSS_HOME\server\default\tmp
$JBOSS_HOME\server\default\work
These are used to store and write logs, temporary files and other various files generated.
There is obviously an error when it tries to create the log folder and this is most likely because it does not have permissions to write and create folders. ( Though you would get this every time since JBoss likes to write a lot of logs all the time ).
In Windows Vista/7, the Program Files folder is not (usually) write-able, so an application started by the user cannot create or modify anything there. You could run JBoss as Administrator but DON'T, it's a bad idea. All files which need to be created/modified by an application should usually be stored in the user's folder, Application Data or somewhere else on the hard drive.
Possible solutions:
Either install your JBoss server somewhere else where you have write access. ( It needs this also when running normally like for storing logs )
Configure JBoss to store logs and other files in different directories, outside of your normal Program Files one. For example to specify a different directory for logs you can set the JVM startup property jboss.server.log.dir ( Specify it at startup by using java -Djboss.server.log.dir=C:/I_can_write_here/. You can find the properties for other directories (and a lot more) at http://community.jboss.org/wiki/JBossProperties
The obvious thing to check is which, if any, of the directories in the quoted path are missing:
C:\Program Files\jboss-4.2.2.GA\server\default\log
Obviously, you have bigger problems than just this if C:\Program Files\ is missing, but you may have other directories missing.
You may need to run an initialize step to validate your configuration and create the directories.
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.