Hi Andrew, I've just force pushed to git
https://salsa.debian.org/debian/runit-services/-/blob/next/debian/extra/netcheck?ref_type=heads call it as (example) /usr/lib/runit-services/netcheck scope=link family=inet scope and family can be omitted (default scope = link, family = any); accepted values are scope=global|link|host; family=inet|inet6. There are issues with ifconfig as especially the scope does not match with ip output; I think ifconfig only provides the scope of the inet6, so for example my interface is of scope=link (instead of scope=global). Wireless is not tested, and still TODO if ip is not installed. Other than that it seems to work. Let me know how it works if you have the chance to test it with gerbera or xl2tpd. On Sat, 18 Oct 2025 13:39:14 +0100 Andrew Bower <[email protected]> wrote: > > Leaving aside my talk about ip address checks for the moment, your > wildcard suggestion got me thinking. > > This seems like a better idea than forcing services to be named a > certain way: > > Any service that wants to provide an LSB-style 'facility' could have > an empty file in its service directory called 'provides-<facility>'. I > have mocked this up like this (and remember ifupdown is down in stage > 1): > > === /usr/lib/runit/facilities === > > facility() { > for i in $(find "$SVDIR" -iregex "[^.]*/provides-$1" -printf "%h ") > do > basename $i > done > } > > sv_if() { > [ $# -gt 1 ] || return > sv "$@" > } > > > === /usr/share/runit/sv.src/network-manager/provides-network === > > I don't find using an include particularly appealing (it feels like sysvinit scripts, I prefer executables and return codes), but anyway I would leave the facilities discussion for another bug; network can be up even if there is no service like network-manager or dhclient, and network-manager or dhclient can fail to bring the network in the desired state even when they are up and running. So I don't think a facility (regardless how it is implemented) is the solution for this bug. Best, Lorenzo
