I have a Raspberry Pi with an Amazonbasics 10-port USB hub which has a PPPS (port per port switching) function, basically, it can turn off power to any power via a tool called uhubctl.

When I use uhubctl to turn off power to a device, the RPI doesn't recognize the device being turned off, the devices still appear in lsusb and ifconfig (these are USBB modems) and dmesg stays completely silent.

It caused no troubles this far but I am sure this is not the best practice.

What would be an elegant solution to this? Do I need to unmount the USB devices before cutting the power?

I know how to do this to a USB drive but not modems.

  • 1
    uhubctl author here. This is described in uhubctl FAQ github.com/mvp/…. The only real solution for this is fix Linux kernel USB driver
    – mvp
    Jun 26, 2020 at 6:17
  • 1
    @mvp You should make your comment a qualified answer :-)
    – Ingo
    Jun 26, 2020 at 9:52
  • thanks @Ingo, converted my comment to answer
    – mvp
    Jun 26, 2020 at 20:32
  • 1
    @RoseKlinger Please accept one answer with a click on the tick on its left side. At least one should answer your question. Only accepting an answer will finish the question and it will not pop up again year for year.
    – Ingo
    Jun 29, 2020 at 9:48

2 Answers 2


uhubctl author here - I have described this issue in uhubctl FAQ:

USB devices are not removed after port power down on Linux

After powering down USB port, udev does not get any event, so it keeps the device files around. However, trying to access the device files will lead to an IO error.

This is Linux kernel issue. It may be eventually fixed in kernel, see more discussion here. Basically what happens here is that kernel USB driver knows about power off, but doesn't send notification about it to udev.

You can use this workaround for this issue:

sudo uhubctl -a off -l ${location} -p ${port}
sudo udevadm trigger --action=remove /sys/bus/usb/devices/${location}.${port}/

Device file will be removed by udev, but USB device will be still visible in lsusb. Note that path /sys/bus/usb/devices/${location}.${port} will only exist if device was detected on that port. When you turn power back on, device should re-enumerate properly (no need to call udevadm again).

  • Thank you! I just tested and it works. However, the interface seems to remain, it just loses it's IP. is there any command to fix that too? Jun 29, 2020 at 16:35
  • Raspberry Pi 4B network is not connected via USB, and as such, it should not be affected by uhubctl turning power off to USB. Earlier RPi models (B+, 2B, 3B, 3B+) have ethernet powered via USB. For them, you should avoid turning off USB port that is powering networking. Exact topology is described in README
    – mvp
    Jun 29, 2020 at 20:20
  • Thanks! I was referring to 4G USB modems, with them, the interface seems to remain, it just loses it's IP. do I need to unmount the network device too somehow? Jun 30, 2020 at 20:05
  • Ah, I did not realize you were talking about network interfaces introduced by USB modems. perhaps you can simply disable or remove them? E.g. try sudo ip link delete {DEVICE}, where DEVICE the the name of network interface you need to disable/remove @RoeeKlinger
    – mvp
    Jun 30, 2020 at 22:44
  • Good answer! +1 I've tried uhubctl, and I think it's useful. WRT the udev/Linux kernel issue, Alan Stern's final post on this thread suggests there will be no kernel fix, and further that the kernel may be incapable of fixing the issue. That's my interpretation after reading this very interesting thread. However - it strikes me that as the author of uhubctl, you are in a position to effect positive change :) It also strikes me that RPi might be an ideal platform to work with. The closed-source firmware is an obstacle, but...??
    – Seamus
    Oct 2, 2020 at 17:00

I’ve never known any issues with USB modems being powered when the computer is turned off and I’ve been using them since Windows 95 (that makes me feel really old - arrggghh).

It happens rarely on disks, SSD, HDD because they often have memory allocated to cache data going to / from the computer for performance reasons and that must be written to the slower disk (memory chips or rust) before power is cut.

I’ve not known any issues correctly powering down a Pi with external disks (again SSD or rust) using shutdown or reboot but have killed a couple of SD configs by pulling the power out in error. Cards where fine but data files were corrupt.

Ive only lost one Pi through power issues - Pi and card were physically fine but O/S dead. This was due to a triple brown out in the space of a minute or so (I live in the wilds of Lincolnshire) and it took out my RAID drives in the Synology as well - one of them was totally dead :(

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.