Hi Lorenzo,

On Fri, Oct 17, 2025 at 11:59:23PM +0200, Lorenzo wrote:
> On Thu, 16 Oct 2025 22:54:59 +0100 Andrew Bower <[email protected]> wrote:
> > Hi Lorenzo,
> > 
> > On Wed, Oct 15, 2025 at 03:36:22PM +0200, Lorenzo wrote:
> > > Control: tags -1 +patch
> > > 
> > > initial version of the service is here
> > 
> > Thanks for adding this support to unblock my service directory
> > contributions!
> > 
> > I don't see a problem in principle with using a new service directory
> > as a dependency for services that require networking, but I think
> > there's a better way to the extent that I think we should not do a
> > service directory.
> > 
> > Let's remember that there is nothing philosophical or practical about
> > runit that means a service directory's dependency needs to be another
> > service, rather than another type of check that can be performed.
> 
> yeah, I agree except the advantage of using a service is that sv check
> waits up to x seconds before giving up. I want to implement this for
> oneshots checks, without a runit service I'll have to implement this
> too.

/usr/bin/timeout comes from coreutils - is that good enough?

sorry I've not thought about it from this angle so need to think some
more - thought I'd get a reply in to answer your questions below though.

> > [snip]
> > 
> > In my contributed service definitions I have entirely omitted network
> > checks that are not needed at all, even if $network was present in the
> > initscript. Instead, I have found out what the real underlying
> > requirement is and implemented that as minimally as possible.
> 
> I'm aware checks that are in the MR are more accurate, but I hoped that
> a less accurate and more generic check could be used: I see that
> probably this idea does not work.
> 
> > [snip]
> > 
> > So how can we do this generally?
> > [snip]
> 
> > I think the answer is to have a library of shell functions we can call
> > to check things. You could put this in invoke-run but I wonder if that
> > is getting a bit full. So maybe another file, either sourced from
> > invoke-run or directly from the run script.
> >
> > Something like:
> >
> > #...
> >
> > . /lib/runit/network-checks
> > 
> > have_network_address scope=global family=inet || exit 1
> > 
> > #...
> 
> ok I'm going to try this, but I have few questions:
> 
> * why map scope= to a number, if I can filter for the word? do we need
>   to filter for something within each scope (and it can be done with
>   the numeric mapping)?

The reason was that I was thinking the scope runs theoretically between
0 and 255 and although most aren't used now in any situations I am aware
of, they could be, and we should be agnostic to this, so you'd say you
need something of at least a certain scope, which works better with a
number. It's probably excessive.

It might be worth us trying out an example implementation and seeing if
it looks sensible or silly.

> * what to do if scope= and or family= are not passed to the command?
>   just fail or have some default for both?

No family would mean any family; missing scope I'm not sure, I think
possibly >=link-local or >=global.

I'm not particularly wedded to those arguments, by the way, I just came
up with it as an example of the sort of thing we could have.

> * what if ip (and or ifconfig) are not found in the system? is it safe
>   to assume that network is not configured and fail in this case?

That's a good question. Needs further thought. Might be worth noting
we're probably doing more than the initscripts would here - they would
just wait until networkmanager/dhclient/networking or whatever services
have been started and possibly failed. So maybe we're over thinking this
and actually need to wait on default-network instead which can launch
those like default-rsyslog does. But I think it would be ugly to have a
service launch another service to do this - is there a way of having an
alias for whichever network setup service is configured?

Reply via email to