RE: File system full causes log4cxx to crash
Probably a limit you can configure with your shell. In bash it's ulimit -c unlimited to get full core dumps and ulimit -a to see the settings (0 bytes by default on my shell.) It and gdb might not be helpful anyway if your log4cxx library is stripped of debugging symbols. If you do pursue getting a core, please don't send it to me :). Install gdb and get the stack trace. We're a month from beta and I still have other bugs to fix, so I'm putting this one to rest for now...
RE: File system full causes log4cxx to crash
With 0.9.7 your app threw and exception and aborted when the log volume filled up. Putting a try/catch around the log call prevented the crash. I put the same try/catch in my wrapper functions and that worked as well, so that's all there was to it. I like simple solutions. Thanks for pointing me in the right direction. -Original Message- From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 5:46 PM To: Log4CXX User Subject: RE: File system full causes log4cxx to crash Okay, thanks, I'll give it a try. -Original Message- From: Jacob L. Anawalt [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 4:24 PM To: Log4CXX User Subject: Re: File system full causes log4cxx to crash On 2008-09-22 17:03, Peter Steele wrote: We're using 0.9.7 in fact, under FreeBSD. Our case is bit more Maybe we need to catch this IOException in our wrapper functions? The IOException was in the 0.10.x code. I didn't see any exception around the writing to files in 0.9.7. As near as I could tell the iostream library was handing the full filesytem error by not writing any more but the rest of the program and logging kept working. Perhaps it is something with the C wrappers. You could try my test program with a small file based filesystem loop mounted at /mnt -- Jacob Anawalt Gecko Software, Inc. [EMAIL PROTECTED] 435-752-8026
RE: File system full causes log4cxx to crash
Looking at FileOutputStream::write in svn head I see that if apr_file_write doesn't return APR_SUCCESS, it throws an IOException with the write call's status. I am not familar enough with the code to see who/what should catch that, but to work like 0.9.7 I'd expect it to be caught at some appropriate level to disable that particular appender. (Maybe in WriterAppender::append?) If the exception is not caught perhaps it is the crash you see. We're using 0.9.7 in fact, under FreeBSD. Our case is bit more complicated in that we are using log4cxx in a C application, with wrapper functions to let us call the log4cxx functions from our C layer. Maybe we need to catch this IOException in our wrapper functions? I'll have to investigate this. Thanks for the idea. Peter
RE: File system full causes log4cxx to crash
Does not one have any comments on this? Surely someone must have experienced this scenario, specially the volume where logs are being recorded becoming filled up. From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2008 11:46 AM To: Log4CXX User Subject: File system full causes log4cxx to crash We've experienced several cases of our logging volume becoming full during the course of execution of our application. What we would like to happen in this case is simply to lose any log further messages that are written after the file system becomes full, but what happens instead is log4cxx crashes and brings down our application. We're using the RollingFileAppender on a Unix box. Is there some way to configure log4cxx to behave a little less drastically in a case like this? Ideally, the best behavior in a case like this would be for log4cxx to delete the oldest backup log file and continue logging, but even simply suspending logging would be better than a crash. Any suggestions?
RE: Building a debug version of log4cxx
It looks like I can do this with this make CXXFLAGS=-g -O0 By default the build uses -O2 and for gdb we need -O0. I think defining this flag will do the trick. From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2008 3:01 PM To: Log4CXX User Subject: Building a debug version of log4cxx We've been getting some core dumps in our application that are appear to be occurring in the middle of calls in the log4cxx library. We want to build a debug version of log4cxx for our FreeBSD boxes so we can properly analyze the core dumps with gdb. What's the trick in build a debug version of log4cxx? Can both the debug and release versions be installed on the same system?
Building a debug version of log4cxx
We've been getting some core dumps in our application that are appear to be occurring in the middle of calls in the log4cxx library. We want to build a debug version of log4cxx for our FreeBSD boxes so we can properly analyze the core dumps with gdb. What's the trick in build a debug version of log4cxx? Can both the debug and release versions be installed on the same system?
RE: Is this a bug or user error?
I've heard of this SocketServer. I'll have to check it out. Thanks.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 7:44 AM
To: Log4CXX User
Subject: RE: Is this a bug or user error?
Peter -
We've had the exact same requirement on platform we did, which used
Log4j... and ended up running the included SocketServer app and then
logging everything to the socket-server, which actually wrote out the
combined file.
Renny Koshy
President CEO
Rubix Information Technologies, Inc.
www.rubixinfotech.com
Peter Steele [EMAIL PROTECTED]
08/18/2008 10:35 AM
Please respond to
Log4CXX User log4cxx-user@logging.apache.org
To
Log4CXX User log4cxx-user@logging.apache.org
cc
Subject
RE: Is this a bug or user error?
A multi-file-appender would be a great addition. I guess in the meantime
the only solution is to either have all of the applications log to their
own log file or implement a log server. We clearly can't continue to use
the configuration we have now...
-Original Message-
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2008 11:27 AM
To: Log4CXX User
Subject: Re: Is this a bug or user error?
On Aug 15, 2008, at 10:59 AM, Peter Steele wrote:
We use the DailyRollingAppender, defined as follows in our config
file:
appender name=FILE
class=org.jboss.logging.appender.DailyRollingFileAppender
errorHandler
class=org.jboss.logging.util.OnlyOnceErrorHandler/
param name=File value=logfile/
param name=Append value=true/
!-- Rollover at midnight each day --
param name=DatePattern value='.'-MM-dd/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p [%c{1}] %m%n/
/layout
/appender
Several applications log to the same log file using this appender.
What's happening is when the rollover occurs at midnight, some
processes still log to the original file, which has now been
renamed, whereas others log to the main log file as they should. I'm
suspecting that this is an error on our part and we should not have
multiple processes all log to the same file, although I've heard
that others do this. What's the solution?
log4cxx's RFAs mimics log4j's RFAs and having multiple independent
applications attempt to write to the same location is a common
misconfiguration problem in the log4j world. There is no mechanism
(at least using java.io) to detect the situation, so the best we can
do is to tell people not to do it.
You are apparently running on non-Windows platform. What is occurring
is that one application rolls over renaming the previous log file and
creates the new log file, when other applications decide that it is
time to roll over, then fail to create the new log file and continue
to write to their old handle (which has been renamed since they
originally opened it).
There has been a long stalled initiative to develop a
MultiFileAppender for log4j which may handle the situation more
gracefully (not its main objective), but that development has been
stalled for a year or so.
Is this a bug or user error?
We use the DailyRollingAppender, defined as follows in our config file:
appender name=FILE
class=org.jboss.logging.appender.DailyRollingFileAppender
errorHandler
class=org.jboss.logging.util.OnlyOnceErrorHandler/
param name=File value=logfile/
param name=Append value=true/
!-- Rollover at midnight each day --
param name=DatePattern value='.'-MM-dd/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p [%c{1}] %m%n/
/layout
/appender
Several applications log to the same log file using this appender.
What's happening is when the rollover occurs at midnight, some processes
still log to the original file, which has now been renamed, whereas
others log to the main log file as they should. I'm suspecting that this
is an error on our part and we should not have multiple processes all
log to the same file, although I've heard that others do this. What's
the solution?
RollingFileAppender question
We are using a RollingFileAppender defined as follows:
appender name=FILE class=org.apache.log4j.RollingFileAppender
param name=maxFileSize value=200MB /
param name=maxBackupIndex value=12 /
param name=File value=${LOGNAME} /
param name=Append value=false/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern
value=%d{MM-dd HH:mm:ss.SSS} %5p %c{1} - %m%n /
/layout
/appender
This works the way we want with one exception: When our app that uses
this appender starts up it overwrites the existing log file. This is of
course because we have Append set to false. What we'd like to have
happen is that if there is an existing log file have a rollover occur
immediately so that no log data is lost. Can that be setup or is our
only option is to set Append to true?
RE: Maximum backup index for RollingFileAppender
It would have been nice if some kind of renaming scheme was used that was near zero-cost. For example, a date/time stamp... -Original Message- From: Jostein Tveit [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 11:42 PM To: Log4CXX User Subject: Re: Maximum backup index for RollingFileAppender Dale King [EMAIL PROTECTED] writes: 12 is a hardcoded limit because this requires renames of all backup files which is expensive It would have been nice if log4cxx issued a warning or error message if the value was set to a value outside the boundaries. -- Jostein Tveit [EMAIL PROTECTED]
Microsecond timestamps
Does the ConversionPattern parameter support microsecond timestamps?
RE: How to set a FileAppender to STDOUT?
In Java, stdout is normally accessed using a console appender. Why are you using this construct in the first place? In the end it looks that we're not going to need to do this after all so it is a moot point... Peter
How to set a FileAppender to STDOUT?
What do I need to specify in the File parameter to mean STDOUT? I have this: appender name=FILE class=org.apache.log4j.FileAppender param name=File value=System.out/ ... which works in log4j but this just creates a file called System.out in log4cxx. What's the magic formula?
RE: How to set a FileAppender to STDOUT?
Here's my un-magic invocation: appender name=FILE class=org.apache.log4j.ConsoleAppender Changing to ConsoleAppender isn't an option in our case unfortunately... Thanks for the reply...
RE: How to set a FileAppender to STDOUT?
Our developers can set the log filename through an environment variable. I wanted to find an option that let them dump their logs to stdout, simply by using a magic filename, as you can do in log4j... -Original Message- From: Jacob L. Anawalt [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 4:09 PM To: Log4CXX User Subject: Re: How to set a FileAppender to STDOUT? Peter Steele wrote: Changing to ConsoleAppender isn't an option in our case unfortunately... Would you mind sharing why it's not an option? I just see the ends of writing to stdout and must be missing some critical difference. Thank you, -- Jacob Anawalt Gecko Software, Inc. [EMAIL PROTECTED] 435-752-8026
RE: Using the syslog appender in log4cxx
Any luck with this? I will post the full configuration files for syslog and log4cxx as well as my sample program if it might help. No, I never did get LOCAL7 to work
RE: Using the syslog appender in log4cxx
I was able to get local7 to work on 0.9.7 using a simple logging test program (a.out) and the syslog appender snippet I included earlier. I added a local7 configuration line to my syslog.conf and reloaded that. Did you specify LOCAL7 as the facility in the config file?
Setting log file name dynamically
I am using the following code to set the log file dynamically instead of
defining it in the xml file:
DOMConfigurator::configure(config);
LoggerPtr logger = Logger::getLogger(cat_name);
FileAppenderPtr appender = logger-getAppender(FILE);
Pool p;
appender-setFile(log_name);
appender-activateOptions(p);
This works with one small side effect. It seems I have to provide a
default setting for the File parameter in the xml config file, otherwise
the configure command complains when the app runs. So I tried doing
this:
appender name=FILE class=org.apache.log4j.FileAppender
param name=Append value=true /
param name=File value=TBD /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p [%t] [%c{1}]
%m%n/
/layout
/appender
but this ended up creating an empty file called TBD before the call to
setFile had a chance to run. I have a workaround where I set File to
/dev/null instead of TBD and this seems to work. Is there a
better/correct way to do this?
]
RE: Setting log file name dynamically
We don’t use property files, only the xml config file. I tried defining my
appender as
appender name=FILE class=org.apache.log4j.FileAppender
param name=Append value=true /
param name=File value=${LOGNAME} /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p [%t] [%c{1}] %m%n/
/layout
/appender
but made the call
setenv(LOGNAME, tester.log, 1);
in my app and tried sending a log message to this logger. The message
disappeared though--no “tester.log” was created. Not sure where the message got
logged…
From: David Schornack [mailto:[EMAIL PROTECTED]
Sent: Monday, June 09, 2008 12:26 PM
To: Log4CXX User
Subject: Re: Setting log file name dynamically
Yes, there is a much easier method, at least this works very well for me.
In log4j.properties, define the following ...
log4j.rootLogger=info, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=../data/${logfile.name}
and then in your code you simple set the name as follows ...
logger = Logger::getLogger(MyApp);
setenv(logfile.name, MyApp.log, 1);
Very simple!
David
On Mon, 2008-06-09 at 11:38 -0700, Peter Steele wrote:
I am using the following code to set the log file dynamically instead of
defining it in the xml file:
DOMConfigurator::configure(config);
LoggerPtr logger = Logger::getLogger(cat_name);
FileAppenderPtr appender = logger-getAppender(FILE);
Pool p;
appender-setFile(log_name);
appender-activateOptions(p);
This works with one small side effect. It seems I have to provide a default
setting for the File parameter in the xml config file, otherwise the configure
command complains when the app runs. So I tried doing this:
appender name=FILE class=org.apache.log4j.FileAppender
param name=Append value=true /
param name=File value=TBD /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p [%t] [%c{1}] %m%n/
/layout
/appender
but this ended up creating an empty file called TBD before the call to setFile
had a chance to run. I have a workaround where I set File to /dev/null instead
of TBD and this seems to work. Is there a better/correct way to do this?
]
RE: Using the syslog appender in log4cxx
I've been able to get the syslog appender to work, with one exception. For our Java apps that use log4j, I have set up a custom entry in /etc/syslog.conf for the local7 facility so that messages targeting this facility are all logged to a custom log file. In my log4j config file I simply have to set the Facility parameter to LOCAL7 to have log messages directed to this custom log file. This doesn't seem to work for log4cxx. I tried setting Facility to LOCAL7 and the log messages disappeared. It seems I have to use DAEMON, and this directs log messages to /var/log/messages. I'd prefer to have log4cxx send log messages to the same LOCAL7 log file that we use for our Java apps. Any suggestions on how to accomplish this? -Original Message- From: Peter Steele [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 6:30 AM To: Log4CXX User Subject: RE: Using the syslog appender in log4cxx While this version is no longer supported by the developers, the following syslog appender works on my Debian systems running 0.9.7: Thanks for the xml snippet, I'll give this a try. And we may very well upgrade to the latest version, but we have 65+ machines with 0.9.7 so it's a bit of a job to get everything upgraded... To troubleshoot, I'd start simple and go forward. Verify the rest of your log4cxx.xml is correct by making sure it will log to the console and then to a file. Then I'd try simpler syslog configurations without filters, error handlers and using localhost. Right now file and console logging work fine, it's just the syslog appender that's causing us problems, even using localhost without filters. Hopefully your xml code will do the trick. Going forward from there use tools like logger(1) to verify your facility, sysloghost and other settings. I'm not familiar with logger; I'll have to check it out. Thanks. Peter
RE: Using the syslog appender in log4cxx
That is a bug in version 0.10.0 Local 2 and higher was not implemented correctly. See this difference to see the cut-and-paste error: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/main/cpp/syslog appender.cpp?r1=613005r2=654960pathrev=654960diff_format=l It has already been fixed in the trunk version of the repository. See this revision: http://svn.apache.org/viewvc?view=revrevision=654960 We're still stuck on 0.9.7, so this may be the motivation we need to upgrade
Is it safe to has different processes on the same machine log to the same file?
This is what we're doing right now and it appears to be working fine. Is this safe to do though, as a general rule?
RE: Using the syslog appender in log4cxx
While this version is no longer supported by the developers, the following syslog appender works on my Debian systems running 0.9.7: Thanks for the xml snippet, I'll give this a try. And we may very well upgrade to the latest version, but we have 65+ machines with 0.9.7 so it's a bit of a job to get everything upgraded... To troubleshoot, I'd start simple and go forward. Verify the rest of your log4cxx.xml is correct by making sure it will log to the console and then to a file. Then I'd try simpler syslog configurations without filters, error handlers and using localhost. Right now file and console logging work fine, it's just the syslog appender that's causing us problems, even using localhost without filters. Hopefully your xml code will do the trick. Going forward from there use tools like logger(1) to verify your facility, sysloghost and other settings. I'm not familiar with logger; I'll have to check it out. Thanks. Peter
