[SOLVED] Can't disable bluetooth devices from being able to wake pc

ididrum · 2025-10-19 21:44:37

So this is a rather weird one and I don't understand what is going on. there is some conflict somewhere but I can't figure it out.

A month or two ago, I successfully created a custom systemd service to automate setting my bluetooth devices to be able to wake up the computer from a sleep state. looking like this

echo enabled > /sys/bus/usb/devices/1-4/power/wakeup

Due to various reasons and potentially safety concerns, I wanted to undo this change. I simply tried undoing it by stopping/disabling the systemd service. But this did not work. It remained "enabled". So I re enabled and restarted the systemd service with the setting as:

echo disabled > /sys/bus/usb/devices/1-4/power/wakeup

but this didn't work either. Weirdly enough, if I try another device (eg. 1-3) it works no problem. Here is my systemd service file just to see what Im doing:

[Unit]
Description=correct suspend
After=multi-user.target

[Service]
User=root
Type=oneshot
RemainAfterExit=yes
ExecStart=echo "disabled" > /sys/bus/usb/devices/1-4/power/wakeup

[Install]
WantedBy=multi-user.target

and from what i can tell from the systemd status output, nothing is indicated that it failed (i think):

Oct 19 22:43:48 Darch systemd[1]: Starting correct suspend...
Oct 19 22:43:48 Darch echo[835]: disabled > /sys/bus/usb/devices/1-4/power/wakeup
Oct 19 22:43:48 Darch systemd[1]: Finished correct suspend.

sidenote, the "disabling code" does work from the terminal but only as root.

but what confuses me is that after disabling the service, I expected it would go back to its default: disabled but it is just somehow stuck on enabled now. Before I set this whole thing up, it seemed that the default was disabled unless I am mistaken.

Last edited by ididrum (2025-10-20 09:06:25)

unixman · 2025-10-20 04:53:50

you use shell redirection (>) in service conf.
echo just echoes whole line:)
And systemd may be cache previous config in fs as permanent.

ididrum · 2025-10-20 07:09:40

Hmmm, maybe I'm dense, i don't quite get it. I noticed that echo typically just echoes the whole line but with the redirection it actually changes the value of certain files and is also the recommended way to do it in bash according to the ArchWiki

"And systemd may be cache previous config in fs as permanent." - yea this is what I suspect, although I'm not sure where to find/diagnose/remedy

unixman · 2025-10-20 07:47:18

unixman wrote:

echo just echoes whole line:)

i means:
echo just echoed whole line instead of your intend. See your posted log. Sory for uncertainity.

that is not shell script! it is systemd config file.
is shell redirection allowed there? it seems dont.

just copy/paste your oneliner into a .sh file then call that file from service conf.

generally caches hold under /var/cache/ for global and ~/.cache/ for users.

Last edited by unixman (2025-10-20 08:24:04)

seth · 2025-10-20 08:12:45

Don't do that itfp, https://wiki.archlinux.org/title/Power_ … _with_udev
You don't know whether the usb node is stable (depending on the hub layout, plugging a usb key could change it)

ididrum · 2025-10-20 08:24:59

Yes, this was certainly a mistake to try at all...Any ideas how to undo this now though? Do you think I should constantly be calling a script from a systemd file to keep it disabled? somehow I borked the default setting I feel

Last edited by ididrum (2025-10-20 08:26:08)

seth · 2025-10-20 08:36:18

Remove the unit and add the proper udev rule (you'll have to adjust vendor and product ID, "lsusb" will tell)

Do you meanwhile understand what's wrong w/ your original unit Exec?

ididrum · 2025-10-20 08:37:21

unixman wrote:

unixman wrote:
echo just echoes whole line:)
i means:
echo just echoed whole line instead of your intend. See your posted log. Sory for uncertainity.
that is not shell script! it is systemd config file.
is shell redirection allowed there? it seems dont.
just copy/paste your oneliner into a .sh file then call that file from service conf.
generally caches hold under /var/cache/ for global and ~/.cache/ for users.

This worked (adding the script elsewhere and calling it), thanks for your patience anyway with my ignorance about shell scripts in a systemd conf file. so I guest I will just mark this as solved. Thank you

ididrum · 2025-10-20 08:41:07

seth wrote:

Remove the unit and add the proper udev rule (you'll have to adjust vendor and product ID, "lsusb" will tell)
Do you meanwhile understand what's wrong w/ your original unit Exec?

Yes, I do. Thanks for verifying. I will look into how to add the proper udev rule. Just to be clear, you recommend NOT running this script as "1-4" could change to be something else at one point?

seth · 2025-10-20 08:48:14

you recommend NOT running this script as "1-4" could change to be something else at one point?

Exactly.

Fwwi, instead of using a helper script, "bash -c 'echo foo > /tmp/bar'" would likewise work.

ididrum · 2025-10-20 09:00:02

Ah I see, I can just use "bash" duh. thanks.

But i still have no idea how the default changed and where the setting lives.

My current udev rules dont indicate any changes to the bluetooth let alone any "wakeup" setting. Do you still suggest this method to reverse the current "default" (enabled)?
It seems extra to create a new rule for what was originally a functional system (before I broke it) So I am struggling to understand the logic behind it...

I guess I am assuming there is some reset somewhere...I guess this is an incorrect assumption

Last edited by ididrum (2025-10-20 09:01:28)

unixman · 2025-10-20 10:47:27

FYI Below is a quick & dirty fix for 1-4 issue. palaceholder is your produckt name.
Nevertheless udev rule approach seems more sane.

dirname $(grep -l PaLaCeHoLdEr `find /sys/devices -type f -name product`)

But since you fix the issue ONCE its dont broke itself w/o you manually enable it again i think.

Last edited by unixman (2025-10-20 10:52:55)

seth · 2025-10-20 14:52:20

My current udev rules dont indicate any changes to the bluetooth let alone any "wakeup" setting.

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Post rule and "lsusb" output but I missed that

A month or two ago, I successfully created a custom systemd service to automate setting

Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Arch Linux

#1 2025-10-19 21:44:37

[SOLVED] Can't disable bluetooth devices from being able to wake pc

#2 2025-10-20 04:53:50

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#3 2025-10-20 07:09:40

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#4 2025-10-20 07:47:18

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#5 2025-10-20 08:12:45

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#6 2025-10-20 08:24:59

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#7 2025-10-20 08:36:18

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#8 2025-10-20 08:37:21

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#9 2025-10-20 08:41:07

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#10 2025-10-20 08:48:14

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#11 2025-10-20 09:00:02

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#12 2025-10-20 10:47:27

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

#13 2025-10-20 14:52:20

Re: [SOLVED] Can't disable bluetooth devices from being able to wake pc

Board footer