Using the syslog appender in log4cxx

Peter Steele wrote:
> anything appearing in the main syslog file for these
applications. What
> other magic do I need to do in log4cxx to get our apps
to log to our
> syslog host? We are using the 0.9.7 release.
>   

While this version is no longer supported by the developers,
the following 
syslog appender works on my Debian systems running 0.9.7:

         <appender name="SYSLOG"
class="org.apache.log4j.SyslogAppender">
                 <param name="Threshold"
value="WARN" />
                 <param name="SysLogHost"
value="localhost" />
                 <param name="Facility"
value="DAEMON" />
                 <layout
class="org.apache.log4j.PatternLayout">
                         <param
name="ConversionPattern"
                                 value="%-4r %-5p %c %x
- %m" />
                 </layout>
                 <filter
class="LevelRangeFilter">
                         <param
name="AcceptOnMatch" value="true"/>
                         <param name="LevelMin"
value="WARN" />
                         <param name="LevelMax"
value="FATAL" />
                 </filter>
         </appender>

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. Going forward from there use tools like
logger(1) to verify 
your facility, sysloghost and other settings.

Good luck,
-- 
Jacob Anawalt
Gecko Software, Inc.
janawaltgeckosoftware.com
435-752-8026

>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

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:psteelemaxiscale.com] 
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

On Thu, Jun 5, 2008 at 10:39 AM, Peter Steele
<psteelemaxiscale.com> wrote:
> 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:psteelemaxiscale.com]
> 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
>
>


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/vie
wvc/logging/log4cxx/trunk/src/main/cpp/syslogappender.cpp?r1
=613005&r2=654960&pathrev=654960&diff_format=l&g
t;

It has already been fixed in the trunk version of the
repository. See
this revision:

http://svn.apache.org/viewvc?view=rev&revision=6549
60


-- 
Dale King

>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/log4c
xx/trunk/src/main/cpp/syslog
appender.cpp?r1=613005&r2=654960&pathrev=654960&
diff_format=l>
>
>It has already been fixed in the trunk version of the
repository. See
>this revision:
>
>http://svn.apache.org/viewvc?view=rev&revision=6549
60

We're still stuck on 0.9.7, so this may be the motivation we
need to
upgrade....

On Thu, Jun 5, 2008 at 2:00 PM, Peter Steele <psteelemaxiscale.com> wrote:
>>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/log4c
xx/trunk/src/main/cpp/syslog
>
appender.cpp?r1=613005&r2=654960&pathrev=654960&
diff_format=l>
>>
>>It has already been fixed in the trunk version of
the repository. See
>>this revision:
>>
>>http://svn.apache.org/viewvc?view=rev&revision=6549
60
>
> We're still stuck on 0.9.7, so this may be the
motivation we need to
> upgrade....
>
>


0.9.7 does not have the bug I described. Not sure why it
wouldn't work
with 0.9.7

-- 
Dale King

On Jun 5, 2008, at 12:55 PM, Dale King wrote:
>
> 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/syslogappender.cpp?r1=613
005&r2=654960&pathrev=654960&diff_format=l 
> >
>
> It has already been fixed in the trunk version of the
repository. See
> this revision:
>
> http://svn.apache.org/viewvc?view=rev&revision=6549
60

Actually, that was a cosmetic error only.  It looked wrong,
but there  
are no potential values for which the code would result in
the wrong  
facility being assigned.

On Thu, Jun 5, 2008 at 10:18 PM, Curt Arnold <carnoldapache.org> wrote:
>
> On Jun 5, 2008, at 12:55 PM, Dale King wrote:
>>
>> 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/vie
wvc/logging/log4cxx/trunk/src/main/cpp/syslogappender.cpp?r1
=613005&r2=654960&pathrev=654960&diff_format=l&g
t;
>>
>> It has already been fixed in the trunk version of
the repository. See
>> this revision:
>>
>> http://svn.apache.org/viewvc?view=rev&revision=6549
60
>
> Actually, that was a cosmetic error only.  It looked
wrong, but there are no
> potential values for which the code would result in the
wrong facility being
> assigned.
>


I saw that when you made the checkin, but I don't understand
why you
think it is only a cosmetic bug. It seems to me that if you
were
trying to configure a syslog appender for LOCAL2 for
instance it would
call setFacility with LOCAL2 as the facility name. This
would call
getFacility( "LOCAL2" ) which will not find a
mapping for "LOCAL2" and
instead of returning the value LOG_LOCAL2 as it should it
will return
LOG_UNDEF. This will cause the facility to default to USER.

I don't know anything about syslog to know what the
ramifications of
that are, but I don't see how you can claim this behavior is
merely
cosmetic.
-- 
Dale King

On Jun 5, 2008, at 11:10 PM, Dale King wrote:
>
>
> I saw that when you made the checkin, but I don't
understand why you
> think it is only a cosmetic bug. It seems to me that if
you were
> trying to configure a syslog appender for LOCAL2 for
instance it would
> call setFacility with LOCAL2 as the facility name. This
would call
> getFacility( "LOCAL2" ) which will not find a
mapping for "LOCAL2" and
> instead of returning the value LOG_LOCAL2 as it should
it will return
> LOG_UNDEF. This will cause the facility to default to
USER.
>
> I don't know anything about syslog to know what the
ramifications of
> that are, but I don't see how you can claim this
behavior is merely
> cosmetic.

The code fragment under question is:

         else if (StringHelper::equalsIgnoreCase(s,  
LOG4CXX_STR("LOCAL0"),
LOG4CXX_STR("local0")))
         {
                 return LOG_LOCAL0;
         }
         else if (StringHelper::equalsIgnoreCase(s,  
LOG4CXX_STR("LOCAL1"),
LOG4CXX_STR("local1")))
         {
                 return LOG_LOCAL1;
         }
         else if (StringHelper::equalsIgnoreCase(s,  
LOG4CXX_STR("LOCAL1"),
LOG4CXX_STR("local2")))
         {
                 return LOG_LOCAL2;
         }
         else if (StringHelper::equalsIgnoreCase(s,  
LOG4CXX_STR("LOCAL1"),
LOG4CXX_STR("local3")))
         {
...

Where the second argument of equalsIgnoreCase is
"LOCAL1" where it  
wasn't intended to be.

equalsIgnoreCase is essentially:

if (arg1.size() != arg2.size() || arg1.size() != arg2)
return false;
for(int i = 0; i < arg1.size(); i++) {
     if (arg1[i] != arg2[i] && arg1[i] != arg3[i])
return false;
}
return true;


if arg1 is "LOCAL1", "local1",
"LoCaL1" or any other variant, it will  
return LOG_LOCAL1, since it will match the second else if. 
It will  
not fall through to the 3 else if or later that would
incorrectly  
match since they have 1 as one of the 2 options for the 6
character.

If arg2 is "LOCAL2", "local2",
"LoCal2" or any other variant, it will  
return LOG_LOCAL2.  equalsIgnoreCase only has to have a
match on one  
of the two potential characters and so as long as one of the
matching  
strings has the right number, it will catch all the expected
matches.   
All of the incorrect matches would already have been
eliminated by the  
second else if.

Basically, the misplaced "LOCAL1" adds the
potential for false matches  
in the later clauses, but any potential false match has
already been  
matched.