On Wed, 28 Mar 2012, Botond Botyanszki wrote:
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.
I guess I am not seeing how the writer would detect that there is data available to be read.
I am also expecting that 99.999+% of writers will be doing so via the glibc syslog() call, so if it behaves sanely there is very little to worry about.
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.
I agree that this could be a problem, but this is why I specified a one-time short write. The expectation being that in the short term when most writers are traditional syslog, this message will never be read and will sit in the socket buffer until it is closed.
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.
I agree that detecting it at parse time is inefficient, and I agree that a binary protocol would be better, but a binary protocol is no longer JSON.
I don't think that pointing structured logs at /bin/slog instead of /bin/log is a good idea because /bin/slog won't exist on systems that don't have an 'advanced' transport, and in those cases plain JSON to /dev/log is the right thing to do.
also, putting structured logs through /dev/slog instead of /dev/log means a change in openlog, which I don't think is a great idea.
David Lang