On macOS 27.x (Apple silicon) I've been measuring how launchd stops a job, and two behaviors don't match the documentation. Method: a throwaway job whose script traps SIGTERM and logs it, bootstrapped with different ExitTimeOut values, then stopped with launchctl bootout while timing when the process dies. Observed (LaunchAgent in the gui domain; the same results in the system domain with a LaunchDaemon): ExitTimeOut 45 -> `launchctl print` reports 45; SIGTERM, then SIGKILL at 45 s ExitTimeOut 61 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 90 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 120 -> reports 60; SIGTERM, then SIGKILL at 60 s ExitTimeOut 0 -> reports 0; SIGKILL after ~0.1 s, SIGTERM never deliveredman launchd.plist says of ExitTimeOut: "The amount of time launchd waits between sending the SIGTERM signal and before sending a SIGKILL signal when the job is to be stopped. The default value is system-defined. The value zero is interpreted as infinity and should not be used, as it can stall system shutdown forever." So: is there a 60-second ceiling on ExitTimeOut? It isn't documented that I can find, and it applies in both domains. And is zero meant to be "infinity" as documented, or an immediate SIGKILL as observed? Finally, is there a supported way for a service to be given more than 60 seconds to exit when launchd stops it — or is 60 seconds simply the maximum? Happy to file a Feedback with a minimal repro if that's useful.

When trying to update from beta 2 to beta 3 and from beta 3 to the revised beta 3 build, softwareupdate failed at the personalization step. This was because a USB-C accessory passed through to a VM via Virtualization.framework was holding the USB-C controller. This blocked I²C access to the AppleTypeCRetimer chip during the preflight personalization phase. In the unified log, this appears as: AppleTypeCRetimerIICDeviceHandle readRegister: Read result 0xe00002d5 AppleHPMLibRT13Interface: HPM is NOT in ADFU, modeData=0x20505041 [SPI] MSUParsedToleratedFailureForStep | step:update_usbcretimer → FAILURE MSUPreflightUpdate | FAILURE → "failed to copy firmware identity" 0xe00002d5 = IOKit I²C device not responding 0x20505041 = "APP " — HPM stuck in application mode, can't enter ADFU (firmware update mode) Without retimer firmware identity, the SFR installer can't complete personalization I was able to work around this by physically unplugging the passed through device (which is suboptimal for a headless server in a rack). Feedback ID: FB23772773 Hardware: Mac16,9 (Apple Silicon) Update: macOS 27 Beta 3 (26A5378j → 26A5378n), full OTA via Software Update Failure: SUMacControllerErrorPreflightPersonalizeFailed (7723) → MSU_ERR_PERSONALIZATION_FAILURE (2) → "failed to copy firmware identity" (1259)

Hi, I wanted to develop a small tool to launch Home Assistant OS in a Virtualization.framework VM. Something lean (no UI, no daemons), zero-config, and Apple Silicon only. I got that running, but I wanted to also use bridge networking and USB device pass-through which require the com.apple.vm.networking and com.apple.developer.accessory-access.usb entitlements, respectively. I was unable to use those for local development using ad-hoc signing, so I guess it requires a paid Apple Developer account and official approval so that they can be enabled in provisioning profiles. I'm open to reactivating my developer subscription which I let expire years ago, but wanted to first assess the chances of getting approval (no point in renewing the subscription if I won't get the permission in the end). I could make this an open source project, if it helps.

I'm using a Mac Studio in a homelab context and use Homebrew to manage the installed services. The services include things that access the local network, for example Prometheus which monitors some other servers, a reverse proxy which fronts other web services on the network, and a DNS server which can use another as upstream. Local Network Access permissions make it impossible to reliably perform unattended updates of services because an updated binary requires a GUI login to grant local network permissions (again). I use brew services to manage the services as launchd agents, i.e. they run in a non-root GUI context. I know that I can also use sudo brew services which instead installs the services as launchd daemons, but running services as root has negative security implication and generally doesn't look like a good idea to me. If only there was a way to disable local network access checks altogether…