You are not logged in.
https://bugs.debian.org/cgi-bin/bugrepo … bug=966403
As root, replace the contents of
/lib/udev/rules.d/39-usbmuxd.rules with the following
# usbmuxd ("Apple Mobile Device" muxer listening on /var/run/usbmuxd)
# Forces iDevices to the last USB configuration and runs usbmuxd
ACTION=="add", SUBSYSTEM=="usb", OWNER="usbmux", ATTR{idVendor}=="05ac", ATTR{idProduct}=="12[9a][0-9a-f]", ENV{USBMUX_SUPPORTED}="1", ATTR{bConfigurationValue}!="$attr{bNumConfigurations}", ATTR{bConfigurationValue}="$attr{bNumConfigurations}", OWNER="usbmux", RUN+="/usr/sbin/usbmuxd -u -U usbmux"
# Exit usbmuxd when the last device is removed
ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ENV{INTERFACE}=="255/*", RUN+="/usr/sbin/usbmuxd -x"
Offline
@Vernon . . . for suggesting this most excellent forum topic and being the first thread maker, you have been awarded a virtual golden elephant fridge magnet!!!
(confetti swirls down on Vernon's head as forum members applaud)
Online
The udev manual states that RUN "can only be used for very short-running foreground tasks" and that udev may kill tasks that run too long or try to double-fork.
So this suggestion is not a robust solution.
Offline
The udev manual states that RUN "can only be used for very short-running foreground tasks" and that udev may kill tasks that run too long or try to double-fork.
So this suggestion is not a robust solution.
This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd. Do you have a better solution?
Offline
Tobias is a well-known contrarian who has not contributed his talents to Devuan. So don't hold your breath . . .
Online
This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd.
I guess that was back when udev did not kill processes. There were issues with this as processes tended to accumulate and stuff.
Of course you can not sandbox processes started by udev via RUN, which is trivial using other means I will not name here.
Do you have a better solution?
I can think of several options:
stick with an old version of udev that still allows this
use a udev replacement that does not have this problem
write something that watches udev and starts/stops things for it
Unfortunately all of these require the distribution to put in effort, which makes all of them rather unsuited as a quick work-around.
Offline
Tobias is a well-known contrarian who has not contributed his talents to Devuan.
I do make sure to use my real name in everything I say about Devuan. You know me, you can block me at any time if I annoy you.
So don't hold your breath . . .
Hmm, the hint that this work-around might not be as robust as promised on recent Devuan releases is at least not harmful IMHO.
Offline
Tobias, you are welcome to post here. And thank you for actually providing some possibly useful information.
Online
This solution was considered robust enough for every distribution from Fedora to Debian until they switched to systemd.
I guess that was back when udev did not kill processes. There were issues with this as processes tended to accumulate and stuff.
...
I haven't seen udev kill usbmuxd yet. However, if you are planning to use USB tethering for extended periods of time and are concerned about udev killing usbmuxd, you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init. At one of my small sites without dedicated Internet, I have a small wireless router running OpenWrt where I start usbmuxd in rc.local. When I or someone else connects an IPhone to the wireless router USB port, the whole site gets Internet. When we leave and take our IPhones with us, there is no longer any Internet and only local LAN devices are accessible.
This has worked perfectly for over a year without any intervention.
Offline
...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....
Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?
Thank you
Offline
Vernon wrote:...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....
Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?
Why are you trying to run usbmuxd from rc.local? Did you follow the Iphone Tethering HOWTO here and are experiencing some problems?
Offline
The iPhone tethering HOWTO works for me, with my iPhone 5c and KDE/Plasma.
For the first time in 3 or 4 years I can download my pics and vids with Gwenview without having to email them to myself.
Thank you so much.
pic from 1993, new guitar day.
Offline
aladedragon wrote:Vernon wrote:...you can just delete /lib/udev/rules.d/39-usbmuxd.rules and start usbmuxd from your init....
Hello, can you give me and example of how did you start usbmuxd from your init/rc.local?
Why are you trying to run usbmuxd from rc.local? Did you follow the Iphone Tethering HOWTO here and are experiencing some problems?
To be honest I was stuck in there one year ago, I will have alook onto this link you post. Thanks a lot
Offline
hmm If i can mount it. That means I can jail break it. Great hack.
Offline
The iPhone tethering HOWTO works for me, with my iPhone 5c and KDE/Plasma.
For the first time in 3 or 4 years I can download my pics and vids with Gwenview without having to email them to myself.
Thank you so much.
adding to my last comment, ...
I have not managed to transfer files other than to download pictures and videos taken with the iPhone (2020) SE.
I'm using plasma (KDE5).
I have found a way to upload my tunes to the iPhone with Cloud Music using wifi.
Also the SE iPhone (iOS 14.x) plays flac (only tested in Cloud Music so far)
I hope this helps others.
pic from 1993, new guitar day.
Offline