On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik <[email protected]> wrote: > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able to > read data from SOCK_DGRAM. This has two consequences: first, to be able > to attach rsyslog on the host end one first needs to copy the data > between the two socket types, e.g. using socat. Second, messages longer > than 1024 characters are sometimes split into two. The second message is > thus missing the syslog header and the receiving rsyslogd doesn't know > where to file it. Is there a recommended workaround for those things > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > SOCK_STREAM)?
I ran into a similar problem. Doesn't it seem wierd that RSyslog: - can write TO a pipe, but it can't natively read FROM a pipe. - can read FROM a UNIX socket, but can't natively write TO a UNIX socket. The only protocols that Rsyslog can both read to AND write from are network sockets (UDP, TCP, RELP) and real files. Maybe everybody just uses UDP for local intra-daemon message routing? I guess real file I/O would work, too, but that seems kind of ugly to me (lots of needless I/O to a particularly slow subsystem). Or maybe there hasn't been much demand to support multiple local daemon instances with combined message processing. I decided to use the 'omprog' module to write via 'socat' to the '/dev/log' socket. I like your method, too. And thank you for mentioning 'socat', that's what gave me the idea to go in this direction, in the first place. > 2) I seem to be unable to get the forwarding template right. For network > forwarding (which is also supported in Anaconda), simply putting no > explicit formatting does the trick: > *.* @@ some.host > The received logs can be matched for anything: severity, facility, > hostname and programname. > > This is not the case when logs are forwarded through the character device: > *.* /dev/virtio_ports/port_name > > Using the implicit formatting the receiving syslog won't parse the > programname. > > I tried using the predefined ForwardFormat but then the receiving > rsyslogd parsed hostname as the programname and the programname remains > part of the final message. Is that the expected behavior? What worked > for me in the end was creating a template based on the ForwardFormat but > with the %HOSTNAME% part omitted: I can live with that for know since I > know the message came from a certain socket so it can be only one host. > Still: it seems weird there's no forwarding format provided that would > retain 100% of the information parsable by another rsyslog reading from > a socket. I'm probably just missing something? I don't think the problem is your forwarding format--I don't think it's possible for RSyslog to handle a HOSTNAME field, properly, in messages received via socket. Based on my own tests, I believe that 'imuxsock' and 'imudp' use different logic to parse incoming messages. 'imuxsock' always assumes that the hostname is the local host, so it doesn't have the conditional logic to differentiate between "forwarded" messages (which have an extra HOSTNAME field between the timestamp and tag) versus regular local messages (no HOSTNAME). This is a pretty reasonable assumption, really--the local UNIX socket doesn't traditionally have any way to receive messages forwarded from other hosts. Rainer could probably confirm this, or we could compare those two modules' sources. RSyslog is a fantastic piece of software, and its feature set has come a long way. But all of Rainer's excellent work has expanded our imaginations about what Syslog can do, and maybe our imaginations are advancing faster than he can code new features. -Ryan _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
