How to disable USB + Bluetooth autosuspend


Sometimes (almost randomly) my non-used usb ports suspend themselves and prevent me from using usb devices unless I restart the pc. Same with bluetooth.

Powertop shows that USB devices + bluetooth gets autosuspended.

I read up on the topic and found different ways to approach the subject.

#1 is to make a shell script that manually disables the autosuspend option for USB devices

#2 changes the value of
/sys/module/usbcore/parameters/autosuspend to -1 trough the GRUB

Other methods mentioned achieving the same result trough udev rules.

What’s the best way to do this ?

Edit: I’m running F36 on Kernel: 6.1.5-100

udev rules sound like the best way to me. I’ve seen other systems use those for that sort of thing. e.g.:

$ cat /usr/lib/udev/rules.d/99-vmware-scsi-udev.rules
# Copyright (C) 2016,2019 VMware, Inc.  All rights reserved.
# This file is part of open-vm-tools

ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*", ATTRS{model}=="Virtual disk*", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo 180 >/sys$env{DEVPATH}/device/timeout'"
ACTION=="add", SUBSYSTEMS=="scsi", ATTRS{vendor}=="VMware*", ATTRS{model}=="VMware Virtual S", ENV{DEVTYPE}=="disk", RUN+="/bin/sh -c 'echo 180 >/sys$env{DEVPATH}/device/timeout'"

Your personal rules should be placed under /etc/udev/rules.d.

1 Like

Uhm, are udev rules distro specific ?

I don’t think so. But I don’t really do distro hopping. So I couldn’t say for sure.

The OpenSUSE answer provided in the following link appears to be what you are looking for.

1 Like

Wellp, so far it seems to work, but I still have my doubts as this problem arises almost randomly … Maybe it stems from udisks, since the device shows up on lsusb but on no file explorer…

sudo vim /etc/udev/rules.d/50-usb-power-always-on.rules
ACTION==“add”, SUBSYSTEM==“usb”, TEST==“power/control”, ATTR{power/control}=“on”
ACTION==“add”, SUBSYSTEM==“usb”, TEST==“power/autosuspend” ATTR{power/autosuspend}=“0”
ACTION==“add”, SUBSYSTEM==“usb”, TEST==“power/autosuspend_delay_ms” >ATTR{power/autosuspend_delay_ms}=“0”
udevadm control --reload
systemctl daemon-reload

The udev rules did not work as powertop still returned that autosuspend was enabled.
I mashed up kirsle’s solution with rafasanto’s and this is the script I ended up with:

for i in /sys/bus/usb/devices/*/power/autosuspend;
do echo -1 > $i;

for j in /sys/bus/usb/devices/*/power/level;
do echo on > $j;

for k in /sys/bus/usb/devices/usb*/power/control;
do echo on > $k;

for l in /sys/bus/usb/devices/*/power/wakeup;
do echo enabled > $l;

(note the line “for k in /sys/bus/usb/devices/usb*/power/control;” I added because that is what powertop toggles !)

I saved it as in my home folder, added the execute permissions to it and created a systemd service so it runs as root on ever startup.
(note: adding sh in frong of the path is necessary, else it will return file not found and permission error… wtf?)

Now powertop says that my usb devices are BAD and I’m happy. I hope it solved my problem…

1 Like

If you did not put the shebang line (#!/usr/bin/sh) as the first line in that script then you needed to tell the service to execute it as a sh script. This is probably why it required the sh at the beginning of that line.

A script with normal permissions such as 644 can be executed as a sh script with “sh scriptname”. The same script with execute permissions such as 755 that does not have the shebang line inside the script can be executed under a user shell (normally bash in fedora) by simply calling the script on the command line, but the system cannot execute it without knowing how to execute it. The system is told how to execute it with “sh /path/to/scriptname” or if it has the shebang line with “/path/to/scriptname”

Ah well that’s the weird part, the shebang line was present in the script and despite that it didn’t get executed !

The only difference is that my shebang line was #!/bin/sh and not /usr/bin/sh as you typed.

The permissions are 755.

Another possibility is SELinux which may (and probably does) interfere with a service executing a script from the users home directory (for system security reasons). You should be able to see entries in the logs if that were the case.

Think of the possible reasons… !
If a user were able to have a script in his home directory executed by a service then that user may create all kinds of nefarious havoc with the system should he change the content of that script.

Using the sh yourcommand structure ensures it runs with the system service environment and not the user specific environment as it may with yourcommand. The shebang line could point to any number of environments, some potentially harmful to the system.

I may have been wrong when I suggested the leading ‘sh’ was not always required.

1 Like

Well, I came across the systemd service to run a script as root without having to type my sudo password on every restart.

Where are scripts like this supposed to be stored if not in the home folder ?

In the meanwhile I bypassed security concerns by simply prepending “sh” in front of the path… I wonder if that is intended to work like that !