SUMMARY: syslog: streams vs datagram

Sorry for the late summary.  I'll spare you the tales of woe about how 
busy I was, etc., etc.  You've heard them all before.

I received two helpful replies (thanks Wes Garland and Kuba!)

Funny how sometimes a bug turns into a feature.  Wes reported that he 
actually relies on this behaviour (0x0a -> 0x20 mapping) for his stuff 
to work.  Given that this is the way Solaris has handled the datagram 
interface to syslog for a long time, I suspect few other things and 
applications may break if Sun ever fixed it.

Kuba mentioned that he had also had this problem, and that a log of 
research and workarounds did not solve anything.   His advice, as I 
suspected all along, was to use syslog-ng, which works the way syslog 
should work.   He even suggested that in the future syslog-ng might be 
adopted as a standard syslog, and not be seen as just another third 
party solution. 

I also found a summary from 2002 from Steve Jones ["SUMMARY: syslog(3) 
and openlog(3)"] where he also ran into this behaviour.  He noticed that 
when using the logger command that Solaris did it one way, and Linux and 
AIX did it another way.   Aren't standards wonderful?

Wes also asked:
   1. Are you using syslog to send the messages, or writing raw packets?
   2. If not, try splitting your UDP packets at the carriage return.

Actually we are using neither.  We use the following C interfaces:
    openlog
    syslog
    closelog
 
Unfortunately Java does not provide access to these C library calls so 
we have had to create a shared object that we access in Java using JNI.  
Our Java application is using multiple classloaders and JNI has a 
limitation that the same shared library can't be referenced by multiple 
classloaders.
 
We were hoping to use the datagrams interface into syslog (which can be 
done entirely in Java) however the datagrams interface has the 
undesirable characteristics:
    1 - Lines with \n are not automatically split
    2 - Lines logged by syslog daemon via datagrams do not display [ 
<message id> <facility>.<log level> ]
 
We were hoping there was a Solaris patch or some syslog configuration 
which would have the datagrams version behave the same as the domain 
streams version.  We currently don't understand why the datagram 
behaviour has to be different than the domain streams behaviour.

I will recommend to the developers that they consider using syslog-ng 
instead at their next opportunity.

Thanks again,
Mike




on 6/3/2005 5:33 PM Mike van der Velden said:

> Greetings,
>
> We develop a turnkey application that runs on Solaris 9, on small to 
> midrange Sun servers (eg. 240s, 480s).
>
> Recently, our developers noted that syslog's streams interface behaves 
> differently than its datagram interface.
> We are running into unusual behaviour with the syslog daemon in 
> Solaris 9.
>  
> If we send the syslog daemon a message like: "some text\nsome more 
> text" and we sent it to the UDP port 514 then the syslog daemon stores 
> the log message as a single line.
>  
> If we send syslog the same message but use domain sockets then the 
> syslog daemon stores the log message as 2 lines.
>  
> We're interested in finding out if we can configure syslog so we get 
> the same behaviour when we send the message to the UDP port 514.
>
>
> I've looked for syslogd patches, but the patches that are available do 
> not address this issue.  I've googled, and it does appear to be a 
> problem that has been around for a while.
>
> Basically, if we send messages using domain sockets, the message gets 
> treated properly.  But over UDP, the message headers are treated 
> differently, the \n are replaced by spaces, and a few other things, I 
> am told.
>
> Has anyone else come across this?
>
> I have suggested that they try syslog-ng, but I am told they really 
> don't want to add an additional 3rd party packages to our existing 
> distribution.   So, fixes to the existing syslog are preferred.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers