On Wed, 28 Mar 2012 12:57:06 -0700 (PDT) david@lang.hm wrote:
On Wed, 28 Mar 2012, Rainer Gerhards wrote:
You don't know what you are going to break and you restrict yourself to the limitations of the current interface. It is not that I am against it, just if we want to improve it it might be best to redo it entirely.
I am strongly against changing the existing interface. This will break so many things that nobody will use it...
I agree that we need to not break any existing applications. What I am hoping for is that we can extend the interface in a way that's fully backwards compatible.
In this case, /dev/log is write-only for existing applications. They will never try to read anything from it.
This breaks assumptions, notably that the original protocol is unidirectional. The writer is not prepared to receive data, and if it does, weird things may happen. The writer may conclude that the syslog server has gone berserk. On the other hand if the unix domain socket is SOCK_STREAM and the data (capability packet) is not read by the client, the socket buffer can get full and the write may block, stalling the syslogd.
There are so many unforeseen problems to this approach that it's best not to try hacking it. There should be a new interface, like we said earlier.
Another reason why I think it is better to create another interface and a new protocol is that the current syslog encapsulated JSON passing over /dev/log is pretty inefficient. To pass the structured data over to the syslogd locally, some other format (binary) should be used. Having syslogd parse the locally received syslog+JSON is pretty inefficient.
Regards, Botond