binding multiple sockets can be useful. an example is being able to receive messages from journald (which requires binding a specific path) but also from a classical udp port.
implementation-wise, -syslogd-socket should be an array of strings
binding multiple sockets can be useful. an example is being able to receive messages from journald (which requires binding a specific path) but also from a classical udp port.
implementation-wise, -syslogd-socket should be an array of strings
plus: being able to bind to systemd-activated sockets would be great!
here is some doc: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation
go-syslog doesn't seem to be very collaborative towards adding "custom" listeners: it doesn't have anything similar to a Serve method, so the operation of listening and serving are coupled.
However, we already forked go-syslog as part of #23, so we could improve it on this aspect, too. It shouldn't be so hard.
go-syslog doesn't seem to be very collaborative towards adding "custom" listeners: it doesn't have anything similar to a `Serve` method, so the operation of listening and serving are coupled.
However, we already forked go-syslog as part of #23, so we could improve it on this aspect, too. It shouldn't be so hard.
socket activation done in b0cd779 + f7caefd; the limitations of go-syslog have been fixed forking go-syslog even more.
The issue isn't fixed because the subject still needs to be addressed; however, work has been done that will make it easier to do it.
socket activation done in b0cd779 + f7caefd; the limitations of go-syslog have been fixed forking go-syslog even more.
The issue isn't fixed because the subject still needs to be addressed; however, work has been done that will make it easier to do it.
binding multiple sockets can be useful. an example is being able to receive messages from journald (which requires binding a specific path) but also from a classical udp port.
implementation-wise, -syslogd-socket should be an array of strings
plus: being able to bind to systemd-activated sockets would be great!
here is some doc: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation
go-syslog doesn't seem to be very collaborative towards adding "custom" listeners: it doesn't have anything similar to a
Servemethod, so the operation of listening and serving are coupled.However, we already forked go-syslog as part of #23, so we could improve it on this aspect, too. It shouldn't be so hard.
socket activation done in
b0cd779+f7caefd; the limitations of go-syslog have been fixed forking go-syslog even more.The issue isn't fixed because the subject still needs to be addressed; however, work has been done that will make it easier to do it.