When TLP is installed, Bluetooth always on when power on my laptop regardless of its previous state

[John Clark]

Bluetooth works properly but it's always turned on on startup and I have to turn it off manually

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: bluez 5.48-0ubuntu3.1
ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
Uname: Linux 4.15.0-43-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
CurrentDesktop: Budgie:GNOME
Date: Wed Dec 26 09:16:08 2018
InstallationDate: Installed on 2018-12-07 (18 days ago)
InstallationMedia: Ubuntu-Budgie 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725.1)
InterestingModules: rfcomm bnep btusb bluetooth
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
 Bus 001 Device 002: ID 04f2:b446 Chicony Electronics Co., Ltd
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: TOSHIBA SATELLITE C50-B
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-43-generic root=UUID=656a2282-422f-4307-9893-2ec8c68718dc ro quiet splash vt.handoff=1
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/10/2015
dmi.bios.vendor: TOSHIBA
dmi.bios.version: 5.10
dmi.board.asset.tag: *
dmi.board.name: ZBWAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: *
dmi.modalias: dmi:bvnTOSHIBA:bvr5.10:bd08/10/2015:svnTOSHIBA:pnSATELLITEC50-B:pvrPSCMLE-02N01VIT:rvnTOSHIBA:rnZBWAA:rvr1.00:cvnTOSHIBA:ct10:cvr*:
dmi.product.family: *
dmi.product.name: SATELLITE C50-B
dmi.product.version: PSCMLE-02N01VIT
dmi.sys.vendor: TOSHIBA
hciconfig:

[Daniel van Vugt (vanvugt)]

Sounds related to bug 1518677.

[Sebastien Bacher (seb128)]

The bluetooth status should be store/restored by the bluez init scripts

[Daniel van Vugt (vanvugt)]

I'm not sure what you mean by init scripts. Init scripts have long been replaced by systemd.

[Daniel van Vugt (vanvugt)]

It appears the state is stored by rfkill, in:

  /var/lib/systemd/rfkill/*

Maybe Budgie isn't setting it (indirectly) properly...

John, can you please run this command and send us the output (after disabling Bluetooth)?

  grep . /var/lib/systemd/rfkill/*

Also, what is the name of the tool you are using in Budgie to disable Bluetooth?

[Daniel van Vugt (vanvugt)]

Also, disabling bluetooth seems to be done entirely at the rfkill/systemd/kernel level. BlueZ is not involved, and bluetoothd stays active regardless. bluetoothd just loses access to the hardware when it's disabled.

[fossfreedom (fossfreedom)]

Budgie is using the gnome-settings-daemon dbus org.gnome.SettingsDaemon.Rfkill to toggle bluetooth on and off/send files etc.

https://github.com/solus-project/budgie-desktop/blob/master/src/applets/status/BluetoothIndicator.vala

[John Clark (jcandgxd)]

grep: / var / lib / systemd / rfkill / *: File or directory does not exist
Can't find "rfkill" directory under systemd.
These are all the other directories under systemd:
backlight coredump deb-systemd-helper-masked timers
catalog deb-systemd-helper-enabled random-seed timesync

[John Clark (jcandgxd)]

These are all rfkill directories I found:

./snap/core/6130/usr/share/doc/rfkill
./snap/core/6130/var/lib/systemd/rfkill
./snap/core/5897/usr/share/doc/rfkill
./snap/core/5897/var/lib/systemd/rfkill
./snap/core/6034/usr/share/doc/rfkill
./snap/core/6034/var/lib/systemd/rfkill
./lib/modules/4.15.0-43-generic/kernel/net/rfkill
./lib/modules/4.15.0-42-generic/kernel/net/rfkill
./usr/share/doc/rfkill
./usr/src/linux-headers-4.15.0-42-generic/include/config/rfkill
./usr/src/linux-headers-4.15.0-43/net/rfkill
./usr/src/linux-headers-4.15.0-43-generic/include/config/rfkill
./usr/src/linux-headers-4.15.0-42/net/rfkill
find: ‘./proc/3031/task/3031/net’: Argomento non valido
find: ‘./proc/3031/net’: Argomento non valido
./sys/kernel/debug/tracing/events/cfg80211/rdev_rfkill_poll
./sys/class/rfkill
./sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/ieee80211/phy0/rfkill1
./sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/ieee80211/phy0/rfkill1/power
./sys/devices/virtual/misc/rfkill
./sys/devices/virtual/misc/rfkill/power
./sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS6205:00/rfkill
./sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS6205:00/rfkill/rfkill0
./sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS6205:00/rfkill/rfkill0/power
./sys/bus/platform/drivers/rfkill_gpio
./sys/module/rfkill_gpio
./sys/module/rfkill_gpio/notes
./sys/module/rfkill_gpio/holders
./sys/module/rfkill_gpio/drivers
./sys/module/rfkill_gpio/sections
./sys/module/rfkill
./sys/module/rfkill/parameters
find: ‘./run/user/1000/gvfs’: Permission denied

[Daniel van Vugt (vanvugt)]

Thanks. If the directory /var/lib/systemd/rfkill does not exist then that would be why Bluetooth is always on when you reboot. Because the flag which is used to indicate that it should be off (soft blocked) is missing.

Next we need to find out what component should be telling rfkill to save the blocked (off) setting. I don't know much about Budgie so will start with a guess..

[fossfreedom (fossfreedom)]

Daniel

gnome-settings-daemon I would suggest looking at the code.

Budgie Desktop itself wouldn't create that that systemd rfkill folder. If Gsd isn't creating that folder is there another gnome package that does? Maybe UB is missing a 0ackage that we can add to our seeds

[fossfreedom (fossfreedom)]

John

  what is the output of

    sudo systemctl status systemd-rfkill

?

When I run

    sudo systemctl start systemd-rfkill

I see the folder /var/lib/systemd/rfkill created

After a reboot is that folder still there?

If you rerun

    sudo systemctl status systemd-rfkill

Does it say after that reboot that the service actually running?

If yes - does the bluetooth stuff on/off remembered now between reboots?

[fossfreedom (fossfreedom)]

Note also - a quick Google brought this up

 https://major.io/2015/07/19/restoring-wireless-and-bluetooth-state-after-reboot-in-fedora-22/

Just wondering if this is a TLP default config issue as per that article

[John Clark (jcandgxd)]

This is the output of "sudo systemctl status systemd-rfkill":

● systemd-rfkill.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

As you can imagine the /var/lib/systemd/rfkill folder hasn't been created after running the command

[fossfreedom (fossfreedom)]

Thanks - from my questions above ...

 sudo systemctl start systemd-rfkill

Is the folder then created? Retained after reboot?

If you purge the tlp package and check the status/start the systemd-rfkill service and reboot what happens?

[John Clark (jcandgxd)]

sudo systemctl start systemd-rfkill:

Failed to start systemd-rfkill.service: Unit systemd-rfkill.service is masked.

No folder has been created.

[John Clark (jcandgxd)]

"If you purge the tlp package and check the status/start the systemd-rfkill service and reboot what happens?"
I don't understand what you mean. I'm not an experienced user, I'm sorry.

[Daniel van Vugt (vanvugt)]

John, please run:

  dpkg -l > allpackages.txt

and then send us the resulting file 'allpackages.txt'.

[John Clark (jcandgxd)]

Here it is

[Daniel van Vugt (vanvugt)]

Thanks John. That confirms you do indeed have TLP installed. So now the steps to answer comment #15 are something like:

  sudo apt purge tlp tlp-rdw

and then after it's been uninstalled, reboot and run:

  sudo systemctl status systemd-rfkill

[John Clark (jcandgxd)]

I've read on some websites like ArchLinux Wiki and TecMint that the tlp package is not crucial but it's important for power management. I'm using Budgie on a laptop so battery life is meaningful for me. So do you advise me to remove tlp anyway?

[Daniel van Vugt (vanvugt)]

At least briefly for testing, yes.

[John Clark (jcandgxd)]

sudo systemctl status systemd-rfkill :

● systemd-rfkill.service - Load/Save RF Kill Switch Status
   Loaded: loaded (/lib/systemd/system/systemd-rfkill.service; static; vendor preset: enabled)
   Active: inactive (dead) since Sun 2019-01-13 08:55:19 CET; 1min 20s ago
     Docs: man:systemd-rfkill.service(8)
  Process: 476 ExecStart=/lib/systemd/systemd-rfkill (code=exited, status=0/SUCCESS)
 Main PID: 476 (code=exited, status=0/SUCCESS)

gen 13 08:55:13 Sir-SATELLITE systemd[1]: Starting Load/Save RF Kill Switch Status...
gen 13 08:55:14 Sir-SATELLITE systemd[1]: Started Load/Save RF Kill Switch Status.

Well, it worked. Everything works properly now. I wonder if the battery life will get worse now or stay as before, I'll see.
Anyway, thanks a lot to all of you!

[Daniel van Vugt (vanvugt)]

Thanks for your patience.

Sounds like confirmation that tlp is the "problem". (Un)fortunately tlp is not a standard part of Ubuntu (yet). From what I remember, the reasons are because it does cause bugs like this one.

[Raphaël Halimi (raph)]

Doesn't setting RESTORE_DEVICE_STATE_ON_STARTUP to 1 in /etc/default/tlp achieves what you expect ?

[John Clark (jcandgxd)]

Yes, I achieved what I wanted setting RESTORE_DEVICE_STATE_ON_STARTUP to 1. Well it's not a bug then. Thanks for the tip Raphaël Halimi.

[Daniel van Vugt (vanvugt)]

I would still call that a bug.

Users expect the device state to be restored by default. If it's not then we'll keep getting bug reports like this one.

[Daniel van Vugt (vanvugt)]

In fact that behaviour with TLP would make power usage worse. I'm not sure why that would be the default to force devices on that you want off.

[Raphaël Halimi (raph)]

TLP doesn't force anything on. It's the desktop's Bluetooth app that turns on the Bluetooth device on startup. Also, TLP's package masks the rfkill service files because that would break the RESTORE_DEVICE_STATE_ON_STARTUP option (among other ones).

This is written in the FAQ (https://linrunner.de/en/tlp/docs/tlp-faq.html#radios).

Please read the documentation before making false assumptions.

If you think that the default setting of RESTORE_DEVICE_STATE_ON_STARTUP should be reversed, please open a new bug for that, and/or ask upstream why this choice was made.

[Daniel van Vugt (vanvugt)]

I don't use tlp myself so don't have much interest in pushing the point.

However if tlp is ever to become a standard part of Ubuntu then issues like this would need to be fixed. Not closed without a fix.

I disagree with your suggestion of logging a bug that describes a solution. A bug report should describe a problem, and not prescribe its solution. So in that way this bug report would be a better way to track the problem, regardless of what the eventual solution is.

[Daniel van Vugt (vanvugt)]

Actually bug 1574311 is the original bug here so let's point to that.