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.
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:
#!/bin/sh
for i in /sys/bus/usb/devices/*/power/autosuspend;
do echo -1 > $i;
done
for j in /sys/bus/usb/devices/*/power/level;
do echo on > $j;
done
for k in /sys/bus/usb/devices/usb*/power/control;
do echo on > $k;
done
for l in /sys/bus/usb/devices/*/power/wakeup;
do echo enabled > $l;
done
(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 .usb_disable_ass.sh 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âŚ
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â
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.
