On Mon, 02 Oct 2017 23:00:01 +0200, Alexander Bluhm wrote:
> I think it should be like this. Our kernel errnos are a bit
> inconsistent, but I think main cause for EADDRNOTAVAIL is when a
> local address is missing.
OK millert@ for after the unlock.
- todd
On Mon, Oct 02, 2017 at 11:54:19AM -0600, Todd C. Miller wrote:
> On Mon, 02 Oct 2017 19:05:37 +0200, Alexander Bluhm wrote:
>
> > Although I think the bug that syslogd was running into was failure
> > in source address selection. Then the temporary bind failed as
> > there was no suitable addres
On Mon, 02 Oct 2017 19:05:37 +0200, Alexander Bluhm wrote:
> Although I think the bug that syslogd was running into was failure
> in source address selection. Then the temporary bind failed as
> there was no suitable address. There is no "specified address".
But the source address was specified
On Fri, Sep 29, 2017 at 11:00:44AM -0600, Todd C. Miller wrote:
> ... let's also update send(2) to document EADDRNOTAVAIL
> as a possible error. The description is lifted from connect(2).
>
> OK?
Yes, we should document the additional case.
Although I think the bug that syslogd was running into
Hi!
I have seen it number of times but haven't had time to investigate it
further. I have another ugly workaround to fix it. In my case it
happens because the route to the syslog target is learned via bgp and
the bgp is not up when syslogd tries to send first message. Your patch
fixes it.
Rivo
O
On Fri, 29 Sep 2017 13:44:51 +0200, Alexander Bluhm wrote:
> A customer has seen a "Can't assign requested address" error from
> syslogd(8) at boot time and then sending messages per UDP did not
> work. It is a carp(4) setup.
>
> So I would suggest to add EADDRNOTAVAIL to the error numbers that
Hi,
A customer has seen a "Can't assign requested address" error from
syslogd(8) at boot time and then sending messages per UDP did not
work. It is a carp(4) setup.
So I would suggest to add EADDRNOTAVAIL to the error numbers that
are ignored when doing UDP sendto(2). Otherwise syslogd would no
