When a remote target is configured and networking is not yet up we drop messages and retry with the next message. For some use-cases this is not good enough.
NetBSD syslogd has implemented struct buf_msg which is used for queuing messages for certain log targets. They do not support UDP remote hosts (F_FORW) with this mechanism, only F_FILE, F_TTY, F_FIFO, F_PIPE, and possibly (the new secure TLS over TCP mech) F_TLS, but the concept should work also for UDP. Look for F_FORW, UdpSend() and cases EHOSTDOWN, EHOSTUNREACH, and ENETDOWN.
Grafting the struct buf_msg construct onto sysklogd would entail a lot of work since it means refactoring the internals and irrevocably going down the NetBSD track with the sysklogd project. This is not necessarily a bad thing, would only make it harder to port features from FreeBSD. However, the NetBSD implementation is the current state of the art and includes support for, e.g., TLS which we want to add anyway.
The most important constraint, however, is adding a high watermark for memory use to message_queue_add(), to prevent this buffering mechanism from eating up all available memory on embedded targets. This watermark should be configurable by the user, similar to the log rotation feature. The queuing should probably also be implemented as ring buffer, so that when we reach the high water mark for buffered messages, we drop the first one(s) to make room for new messages.
troglobit
commented
4 years ago
When a remote target is configured and networking is not yet up we drop messages and retry with the next message. For some use-cases this is not good enough.
NetBSD syslogd has implemented
struct buf_msgwhich is used for queuing messages for certain log targets. They do not support UDP remote hosts (F_FORW) with this mechanism, onlyF_FILE,F_TTY,F_FIFO,F_PIPE, and possibly (the new secure TLS over TCP mech)F_TLS, but the concept should work also for UDP. Look forF_FORW,UdpSend()and casesEHOSTDOWN,EHOSTUNREACH, andENETDOWN.http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/syslogd/syslogd.c?rev=1.131&content-type=text/x-cvsweb-markup
Grafting the
struct buf_msgconstruct onto sysklogd would entail a lot of work since it means refactoring the internals and irrevocably going down the NetBSD track with the sysklogd project. This is not necessarily a bad thing, would only make it harder to port features from FreeBSD. However, the NetBSD implementation is the current state of the art and includes support for, e.g., TLS which we want to add anyway.The most important constraint, however, is adding a high watermark for memory use to
message_queue_add(), to prevent this buffering mechanism from eating up all available memory on embedded targets. This watermark should be configurable by the user, similar to the log rotation feature. The queuing should probably also be implemented as ring buffer, so that when we reach the high water mark for buffered messages, we drop the first one(s) to make room for new messages.