From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: USB tethering not working, might be due to a bug in 'usbmux' package.
Date: Tue, 14 Dec 2021 12:56:38 +0100 [thread overview]
Message-ID: <20211214115638.aIv_bivRfsTFVy9TLKJ1-rSlDJpoCWZ9dJ-sqthkOo8@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-34458@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/34458#issuecomment-993467073
Comment:
1. Do **NOT** remove the udev rule from the package. If it doesn't work as expected, mask it by symlinking `/etc/udev/rules.d/39-usbmuxd.rules` to `/dev/null`. You could also add a `noextract` XBPS rule and reinstall the package, but simply removing the file will break package consistency and your change will be wiped out with the next update anyway.
2. The purpose of the udev rule is to autostart the daemon when a device is attached and kill it on detach. When this works reliably, you should be able to use your device without constantly running the service. In practice, I've seen the daemon hang occasionally when udev should be killing it, so I manage the daemon with runit. (I've never had the issue of competing instances that you see.) your results might differ. Try disabling the runit service and reattaching your phone. It might "just work", Apple style.
The "systemd" TAG line in the udev rule is a signal to systemd that a device unit should be created when this device is added to the system. Since Void does not have systemd, this should have no significance. In the absence of evidence that the systemd tag declaration actually causes a problem in the udev autostart rule, we should assume it takes no meaningful action and avoid carrying a patch for no purpose.
I am an infrequent user of usbmuxd. While it seems udev management of the daemon is sometimes flaky, I do not believe (but really don't know) that the flakiness is a hard dependence on systemd components that Void does not provide. If I am wrong and proper automatic management of the daemon *requires* that systemd manage device units, Void should stop shipping a useless udev rule.
next prev parent reply other threads:[~2021-12-14 11:56 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 5:19 [ISSUE] " austinrojers
2021-12-10 21:17 ` dotnetfox
2021-12-11 10:08 ` austinrojers
2021-12-11 10:08 ` [ISSUE] [CLOSED] " austinrojers
2021-12-11 19:02 ` dotnetfox
2021-12-11 19:03 ` dotnetfox
2021-12-12 3:12 ` austinrojers
2021-12-12 3:13 ` austinrojers
2021-12-12 3:14 ` austinrojers
2021-12-12 3:15 ` austinrojers
2021-12-12 3:15 ` austinrojers
2021-12-12 3:16 ` austinrojers
2021-12-12 4:39 ` dotnetfox
2021-12-12 4:40 ` dotnetfox
2021-12-12 4:52 ` dotnetfox
2021-12-12 5:33 ` austinrojers
2021-12-12 5:34 ` austinrojers
2021-12-12 5:37 ` austinrojers
2021-12-12 5:47 ` austinrojers
2021-12-12 5:48 ` austinrojers
2021-12-12 5:49 ` austinrojers
2021-12-12 5:50 ` austinrojers
2021-12-12 5:50 ` austinrojers
2021-12-12 6:02 ` austinrojers
2021-12-12 6:04 ` austinrojers
2021-12-12 6:04 ` austinrojers
2021-12-12 6:05 ` austinrojers
2021-12-12 6:09 ` dotnetfox
2021-12-12 6:30 ` austinrojers
2021-12-12 6:35 ` dotnetfox
2021-12-12 8:25 ` austinrojers
2021-12-12 8:58 ` dotnetfox
2021-12-12 8:58 ` dotnetfox
2021-12-12 12:19 ` austinrojers
2021-12-12 12:20 ` austinrojers
2021-12-12 12:35 ` austinrojers
2021-12-12 12:38 ` austinrojers
2021-12-12 12:39 ` austinrojers
2021-12-12 16:55 ` dotnetfox
2021-12-12 16:57 ` dotnetfox
2021-12-12 17:02 ` dotnetfox
2021-12-12 17:03 ` dotnetfox
2021-12-13 3:17 ` austinrojers
2021-12-13 3:18 ` austinrojers
2021-12-13 3:20 ` austinrojers
2021-12-13 3:33 ` austinrojers
2021-12-13 3:33 ` austinrojers
2021-12-13 6:11 ` austinrojers
2021-12-13 6:13 ` austinrojers
2021-12-13 6:13 ` austinrojers
2021-12-13 6:16 ` austinrojers
2021-12-13 9:20 ` austinrojers
2021-12-14 11:07 ` dotnetfox
2021-12-14 11:21 ` dotnetfox
2021-12-14 11:56 ` ahesford [this message]
2021-12-14 13:00 ` austinrojers
2021-12-14 13:01 ` austinrojers
2021-12-14 13:20 ` ahesford
2021-12-14 13:50 ` austinrojers
2021-12-14 13:51 ` austinrojers
2021-12-14 13:51 ` austinrojers
2021-12-14 14:17 ` ahesford
2021-12-14 14:41 ` dotnetfox
2021-12-14 14:49 ` austinrojers
2021-12-14 15:11 ` ahesford
2021-12-14 15:18 ` austinrojers
2021-12-14 15:30 ` austinrojers
2021-12-14 15:31 ` dotnetfox
2021-12-14 15:31 ` austinrojers
2021-12-14 15:35 ` austinrojers
2021-12-14 15:52 ` austinrojers
2021-12-14 15:53 ` austinrojers
2021-12-14 15:53 ` austinrojers
2021-12-14 16:03 ` dotnetfox
2021-12-14 16:29 ` austinrojers
2021-12-14 16:43 ` dotnetfox
2021-12-14 16:54 ` austinrojers
2021-12-14 16:55 ` austinrojers
2021-12-14 17:31 ` dotnetfox
2021-12-14 18:00 ` austinrojers
2021-12-15 7:22 ` austinrojers
2021-12-15 7:22 ` austinrojers
2021-12-15 11:52 ` ahesford
2021-12-15 12:52 ` austinrojers
2021-12-15 12:58 ` austinrojers
2021-12-20 17:20 ` austinrojers
2021-12-21 1:19 ` dotnetfox
2021-12-21 1:28 ` dotnetfox
2021-12-21 4:15 ` austinrojers
2021-12-21 4:25 ` austinrojers
2021-12-21 4:25 ` austinrojers
2021-12-21 4:26 ` austinrojers
2021-12-21 9:26 ` dotnetfox
2021-12-23 4:50 ` austinrojers
2022-06-18 2:13 ` github-actions
2022-07-03 2:13 ` [ISSUE] [CLOSED] " github-actions
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211214115638.aIv_bivRfsTFVy9TLKJ1-rSlDJpoCWZ9dJ-sqthkOo8@z \
--to=ahesford@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).