On Sun, 27 Nov 2022 12:41:23 +, Klemens Nanni wrote:
> On Sat, Nov 26, 2022 at 07:33:40PM -0700, Theo de Raadt wrote:
> > Yes, that is understandable and suggests "no need to panic".
>
> Sure, I wasn't sure yet as to whether this is the only way open(2) can
> yield EAGAIN (in this use case),
On Sat, Nov 26, 2022 at 07:33:40PM -0700, Theo de Raadt wrote:
> Yes, that is understandable and suggests "no need to panic".
Sure, I wasn't sure yet as to whether this is the only way open(2) can
yield EAGAIN (in this use case), but since you seem to agree..
Todd, do you want to commit this
Yes, that is understandable and suggests "no need to panic".
> On Sat, 26 Nov 2022 11:09:58 -0700, "Theo de Raadt" wrote:
>
> > But "Resource temporarily unavailable" has absolutely no meaning to
> > anyone who will try to do this by hand, it is better for the message
> > to interpret the
On Sat, 26 Nov 2022 11:09:58 -0700, "Theo de Raadt" wrote:
> But "Resource temporarily unavailable" has absolutely no meaning to
> anyone who will try to do this by hand, it is better for the message
> to interpret the situation so that someone can understand.
Agreed, it would be friendlier to
But "Resource temporarily unavailable" has absolutely no meaning to
anyone who will try to do this by hand, it is better for the message
to interpret the situation so that someone can understand.
I think your proposal makes it worse.
Klemens Nanni wrote:
> To debug things, I started slaacd
To debug things, I started slaacd manually from single-user:
boot> b /bsd -s
# slaacd -dv
slaacd: already running
We added the lock and this message to prevent multiple instances in the
installer, where this is indeed the only error case that can happen.
But hitting it
