[Bug] nvpair-node-scanner causes macOS kernel panics (userspace_watchdog_timeout) due to aggressive net.Interfaces() polling

System Information

• OS: macOS (Apple Silicon / arm64)
• Component: nvpair-node-scanner / shared/discovery
• Symptom: Entire system freezes and reboots with a userspace_watchdog_timeout kernel panic.

Description

When running the PAIR macOS application, the system will randomly freeze and trigger a forced watchdog reboot. Analyzing the Apple Diagnostic Reports (/Library/Logs/DiagnosticReports/configd_*.spin) reveals that Apple's core network configuration daemon (configd) gets starved while waiting for a kernel read-write lock (krwlock).

The macOS crash logs explicitly show that this kernel lock is being held by nvpair-node-scanner:

*1 ??? (kernel.release.t6050 + 773428) [0xfffffe000b4a8d34] (blocked by krwlock for reading owned by nvpair-node-scanner [1309] [unique pid 791059] thread 0x6fa35b) 2

Root Cause Analysis

The root cause stems from the Windows mDNS workaround in services/shared/discovery/discovery.go.

The Browse loop executes every 5 seconds. Within this loop, sendMulticastQuery() is called to bypass a Windows-specific bug where grandcat/zeroconf drops UDP packets due to multicast bindings. However, sendMulticastQuery() executes unconditionally on all operating systems.

func sendMulticastQuery(service, domain string) map[string]bool {
    // ...
    ifaces, err := net.Interfaces()
    // ...
    // Iterates through all interfaces, binding and closing UDP sockets

On macOS, calling net.Interfaces() and rapidly binding/closing raw UDP sockets on every valid interface every 5 seconds inside a background daemon causes severe kernel routing table lock contention (krwlock). Over time, this starves configd, triggering the userspace_watchdog_timeout panic.

As the source comment itself notes, standard zeroconf receive/transmit works perfectly on macOS/Linux. This custom per-interface UDP barrage is only necessary on Windows.

Proposed Fix

Guarding the sendMulticastQuery() function so that it only executes on Windows completely eradicates the kernel panics on macOS, while preserving standard zeroconf discovery.

Patch for services/shared/discovery/discovery.go:

import "runtime"

// ...

func sendMulticastQuery(service, domain string) map[string]bool {
	outcomes := make(map[string]bool)
	
	// FIX: Restrict the socket workaround to Windows to prevent macOS krwlock starvation
	if runtime.GOOS != "windows" {
		return outcomes
	}

	msg := new(dns.Msg)
	// ... rest of the function ...
}

We have compiled and deployed this patch locally across our macOS cluster, and it immediately resolved the panics. We highly recommend upstreaming this guard to prevent other macOS users from experiencing severe system reboots.