cc: @robmry

Tests are failing with ...

setup_ip_tables_linux_test.go:394: cannot restrict inter-container communication: modprobe bridge failed: exec: "modprobe": executable file not found in $PATH

I guess that's because the directory exists, so modprobe wasn't needed before - and now arp_probe doesn't exist, so it is called.

I'm wondering if it'd be best to use a sync.Once to call loadBridgeModules to try the modprobe (without making any checks for files existing), and log the result without returning an error... if br_netfilter is already loaded, it's a cheap call so no real loss. If the sysctl files don't exist after that, getKernelBoolParam will fail and generate an error (the original error you found in the logs). I think that'd just be a bit less to go wrong, and maintain if we ever modify which sysctls we're setting?

Tests are failing with ...

setup_ip_tables_linux_test.go:394: cannot restrict inter-container communication: modprobe bridge failed: exec: "modprobe": executable file not found in $PATH

I guess that's because the directory exists, so modprobe wasn't needed before - and now arp_probe doesn't exist, so it is called.

I'm wondering if it'd be best to use a sync.Once to call loadBridgeModules to try the modprobe (without making any checks for files existing), and log the result without returning an error... if br_netfilter is already loaded, it's a cheap call so no real loss. If the sysctl files don't exist after that, getKernelBoolParam will fail and generate an error (the original error you found in the logs). I think that'd just be a bit less to go wrong, and maintain if we ever modify which sysctls we're setting?

We can but checking for directory existence is a lot cheaper than invoking a binary. I can make this change if you insist.

We can but checking for directory existence is a lot cheaper than invoking a binary. I can make this change if you insist.

Thanks @sshedi - it's looking good. No need to make that change, it was just a thought.

I don't know what's going on with the tests yet, it doesn't look like anything to do with this PR though ...

Edit: it's a buildx regression, people who know-stuff are on the case!

Reverted the bump to latest Buildx stable for our actions in docker/actions-toolkit#508.

I triggered a re-run of failed jobs, should work now.