New comment by dotnetfox on void-packages repository

https://github.com/void-linux/void-packages/issues/34458#issuecomment-998391488

Comment:
> It's just the first time usbmuxd won't work; you just have to kill it the first time, and everything starts working fine.

This happens only when the device is plugged in before stage 2 of runit, I take it?

You see, runit runs udev on stage 1 in order to initialize all devices, yet it catches usbmuxd.

I believe running usbmuxd on stage 1 is a bad timing, given that this stage is designated for initialization, not hotplugging.

Eventually udev is butchered by runit and this time is run as service; but what becomes of usbmuxd which is running since stage 1? Nothing. Since udev was butchered, nothing is monitoring it.

This comes to be a reason as to why you have to kill it manually (udev is not my area of expertise, feel free to correct me if I am wrong).

My suggestion may sound foolish, but here is the workaround for you: try not to connect your device before stage 2 of runit (in your case until you reach the login screen).

As for the real solution with udev, I have nothing to suggest. Checking existence of a daemon and spamming it with `usbmuxd -x`? No idea.

Alpine, for example, chooses to live without udev: https://git.alpinelinux.org/aports/tree/testing/usbmuxd/001-confiure-no-udev.patch. Maybe they live with the same problem (or do not support udev, who knows?).