Re: Wait for interface existence?

[Roy Marples <roy%marples.name@localhost>]

On 30/08/2023 21:57, Mouse wrote:
> > > > > I find myself wanting a tool that waits until a certain set of
> > > > > network interfaces exists.  [...]
> > > > ifwatchd?
> > > Related, but I don't see any way to get what I want out of ifwatchd
> > > without significant additional tooling around it.
> [paragraph-length-line damage repaired manually]
> > You would write an arrival and departure script for ifwatchd.  Each
> > one would test for the existence of non existence of your
> > requirements using ifconfig or any other tools and then take whatever
> > action is required.
>
> I notice you completely ignored my stated desire (in text I cut when
> trimming, above) to shut it down once it has found the interfaces.  I
> don't know whether this is because you didn't notice that text, because
> you were hoping it would go away if you didn't address it, because you
> think it's trivial, because you wanted to leave it as an exercise for
> the reader, because you think the right answer is to have only one
> (long-running) ifwatchd handling all the "wait for theses interfaces"
> runs, or what.

Well, it's the right answer because that's how ifwatchd has been designed.
If you need to wait for state to say all interfaces are ready then you also need 
a system to say that interfaces have become non ready - state can and will change.

The only reason why ifconfig waits for addresses to become ready is to avoid 
arbitary sleeps in our rc system so that daemons can bind to specific addresses.
This in itself is bad - said daemons should really wait for the address to 
become ready rather than just bailing. IPv6 addresses expire, etc. But that is 
the easier fix so that the rc system starts a fair bit quicker and is less error 
prone.

> Furthermore, ifwatchd's documentation is rather sorely
> lacking in relevant respects (the only description of scripts'
> arguments is not applicable to arrival and departure events, because it
> includes a non-optional address parameter).

Documentation is always lacking, patches welcome.

> I can see two ways to do this with ifwatchd.
>
> One is to extend it to provide a way for the scripts to shut ifwatchd
> down, then write the relevant scripting.
>
> The other is to run a single ifwatchd, handling all such runs in
> parallel, with significantly more complicated scripting and some kind
> of state storage.
>
> Either of those would be a good deal more code than what I did to
> ifconfig and would have correspondingly more failure modes.

So *why* do you feel the need to shutdown ifwatchd.
If you're waiting for an interface to appear, that implies it's hotplugged 
somehow. If it can be hotplugged, it can easily be unplugged. If ifwatchd is 
shutdown, this fail state cannot be detected.

The fact that you mention state storage implies that the problem you are trying 
to solve is fairly complex (or the state is) - can you share this with us?
I mean an interface just being there is pretty boring - it can't do much until 
it gets an address and then it becomes interesting :)

> It appears your stance is that that's the right answer.  If - if! -
> that is NetBSD's stance as well, I will take that as a lack of interest
> in adding the capability to ifconfig and will leave my own tree at
> ifconfig -W.

The last time I checked, I'm not Mr NetBSD.
But I also belive in doing the right thing, but I for one dont understand what 
the right thing is yet.

Roy