It was thus said that the Great Ryan Lynch once stated: > 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?
The default syslog() call uses a local UDP socket (usually '/dev/log') and there's no overhead a programmer has to do in order to call syslog() (I mean, a programm can call openlog(), but it's not mandatory). So programs (other than syslogd) use local Unix UDP socket. For talking to other syslog daemons, I think the typical scenario is to run one locally, and any forwarding is done via an actual network socket. I never thought of doing relaying to another Unix socket. I know in my case (at home) I send a copy of all logs to 239.255.0.1, which is a multicast address (local segment only) so that I can run other instances of syslogd (or in my case, my own syslogd) on that address (on any machine on the segment); I can even run multiple copies locally listening to that address without issue. Adding support for multicast addresses was simple (about 32 lines of code, but it also supports IPv6). > 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. One issue with using files is that you end up having to poll a file for input. Normally, when you read from files, reading 0 bytes means you've hit the end of the file (and read() doesn't block on end-of-file for actual files). In this case (and in the case if doing a 'tail -f') you have to keep reading the file for more input once you hit the end. In the case of 'tail -f' (and for this, I checked the actual source code) it just sleeps for a second everytime it reads 0 bytes from a file. > 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. I agree, but replace "rsyslog" with "any syslog" (it's why in my own syslogd I only send IP addresses and not hostnames). > 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. If that's the case, then I'm surprised; in my syslogd, all messages (reguardless of source) go through the same parsing engine (then again, I only handle RFC-3164 style messages). I handle messages from the local socket by setting the "hostname" to the actual socket filename; I could have used "localhost" but I felt the actual socket filename would be better in those rare instances where you had a chroot'ed program that wrote to its own "/dev/log" socket so one could see which chroot'ed environment the log message was generated under. -spc _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
