Bluetooth won't stay disabled after reboot due to early upstart job

[Kyle Fazzari]

Using a Dell XPS 13 with Ubuntu 12.04.

In order to restore RF interfaces to their previous state between boots, rfkill is run via two Upstart jobs in /etc/init/: rfkill-store.conf (run while shutting down) and rfkill-restore.conf (run when starting up). However, while rfkill-restore.conf starts on the Upstart local-filesystems signal, there is a high probability that the RF kill switches in /sys/class/rfkill/ still won't yet be populated (i.e. every time on the Dell XPS 13). This results in behavior like the following:

1. Disable bluetooth via applet.
2. Reboot.
3. Login.
4. Observe bluetooth is re-enabled!

Bluetooth should have stayed disabled, but since the kill switches weren't present when rfkill-restore was run, the kill switch states were not restored.

[Kyle Fazzari (kyrofa)]

I have attached a new rfkill-restore script that respawns for up to 60 seconds if the kill switches aren't present. If, after a minute, the switches still aren't present, the upstart job fails.

[Kyle Fazzari (kyrofa)]

To clarify: The patch attached in comment 1 is a completely replacement for /etc/init/rfkill-restore.conf.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Kamal Mostafa (kamalmostafa)]

This bug occurs in Ubuntu 12.10 and Ubuntu 12.04 (and probably earlier releases).

I confirm that Kyle's "Respawn..." replacement /etc/init/rfkill-restore.conf fixes it! Thanks Kyle!

[Kamal Mostafa (kamalmostafa)]

Hi Stéphane- I'm assigning this bug to you for review/handling, since it looks like you added the rfkill upstart jobs. Could we get Kyle's replacement rfkill-restore.conf into the rfkill package?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Respawn for up to 60 seconds if the kill switches aren't present." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Kamal Mostafa (kamalmostafa)]

Specifically, this fix is applicable to rfkill in just 12.04, 12.10, and the in-development Raring branch. Previous to 12.04, there weren't any rfkill store/restore upstart jobs at all.

[papukaija (papukaija)]

Is your script bullet proof? In my case, the issue seems to be more complicated (see bug 446657 for more details).

[papukaija (papukaija)]

Just to add that the upstream for gnome-bluetooth is working for a more global fix (not all Linux distros use upstart).

[Kyle Fazzari (kyrofa)]

papukaija, give it a shot and see if it improves things. This script relates to comment 54 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/54) of bug 446657 . Make a backup of /etc/init/rfkill-restore.conf and replace it with the one attached to this bug. Then disable bluetooth via the applet and reboot. Is it still disabled?

[papukaija (papukaija)]

Sorry but I don't currently have access to the laptop with which I have the issue but will try to report here as soon as I have tested it.

[Eugene T. (tarasov-eugene)]

Looks like the problem is caused by "race condition" during startup - by the moment "rfkill-restore" gets executed the driver for bluetooth is not completelly initialized, so the script "does not see" the device, thus cannot switch it on/off. At least it was like this on my Ubuntu 12.04. I "solved" the problem (its rather a workaround than a solution) by adding line "sleep 1" in the beginning of the script (after line "script") in file /etc/init/rfkill-restore.conf

[Eugene T. (tarasov-eugene)]

Ive just noticed the patch. Tried it - works for me. Maybe it still makes sense to add constant 1 sec delay in beginning of the script (and maybe reduce conditional delays to 3 sec to balance timings). I think its important, because for all users, who encounter this problem, the service is going to be respawned at least once with 5 sec delay. Introducing 1 sec constant delay makes the script work for most cases from the first try. Also, the first if-block detects if rfkill stuff is available at all, so there is no point in restarting the service in this case. Kyle's file from the first comment with above changes is attached to this comment.

[Kyle Fazzari (kyrofa)]

@Eugene: Thanks for trying the patch. I feel like the one second delay is rather hacky though; this script doesn't always fail the first time, and if you disagree with the five-second resolution on the retries, changing that rate is probably a better solution than the one-second delay.

[Eugene T. (tarasov-eugene)]

@Kyle Ya, I agree, there are better solutions, 1 sec delay solution was just a compromise

[Eugene T. (tarasov-eugene)]

Ive prepared the new implementation of the service. It has at least two advantages (compared to previous solutions) - it's adaptive (longer it takes to initialize devices - longer it waits between attempts, and these delays can be easily configured), and it does not reset already set devices. Because it doesn't use respawn feature, it doesn't litter logs with 'scary' messages.

[Stéphane Graber (stgraber)]

That seems overly complex, for what it's worth, I already have the design on how to fix this properly but haven't got around to implement it yet.

The changes will simply be to have the job trigger on bluetooth-device-added and network-device-added and store running state of the job so that we don't reset something we already set earlier at boot time.
This should be a pretty minimal code change but will require a fair bit of testing to make sure we don't change the boot dependency tree in a way we don't want.

[Kyle Fazzari (kyrofa)]

@Stéphane, yeah that solution sounds a bit more slick. I don't see those signals in there already-- are there already upstart scripts that run when a bluetooth or network device is added? I can play with this if you like.

[Stéphane Graber (stgraber)]

Those events come from the udev bridge, the two you're interested in are:
 - net-device-added
 - bluetooth-device-added

My idea was roughly to change /etc/init/rfkill-restore.conf with:
 - start on local-filesystems or (local-filesystems and net-device-added) or (local-filesystems and bluetooth-device-added)
 - Add a line after the echo, doing "touch /run/rfkill.$1.done"
 - Change the if statement not to trigger if /run/rfkill.$1.done exists

This should make the job trigger once at boot time and again every time a device appears on the system, the entry in /run will be there to avoid restoring the original state of all devices every time a new device shows up. /run being on tmpfs, it won't be persistent across reboots.

[papukaija (papukaija)]

I upgraded to Raring and the bluetooth status is restored between reboots. Could someone confirrm this?

[Marius B. Kotsbak (mariusko)]

Still reproduce this problem in Raring.

[zeus (zeus-tunalkan)]

This bug is rather old, yet not solved. For the moment I'm using the script in this thread.
I'm on Ubuntu 14.04 (the issue persists also in Mint 14.04), Atheros bluetooth hardware (Toshiba Portégé Z830).

[papukaija (papukaija)]

This bug should be fixed in Ubuntu 15.04, as it currently has systemd 215. The fix is in systemd 209, source: https://bugzilla.gnome.org/show_bug.cgi?id=638117#c50

[Colan Schwartz (colan)]

Quite sure I'm still getting this on 15.04.

[Aapo Rantalainen (aapo-rantalainen)]

Happens with 16.04.
Goal: start ubuntu without bluetooth

a)
 /etc/bluetooth/main.conf
+InitiallyPowered = false
Didn't work.

b)
rfkill-restore.conf from this ticket
Didn't work.

c)
/etc/rc.local
+rfkill block bluetooth
Didn't work.

Finally disabled bluetooth from BIOS.

[spike speigel (frail-knight)]

@aapo-rantalainen

This might be the solution. Worked for me:

https://github.com/blueman-project/blueman/issues/682

[Alexey (alexey-muranov)]

Unchecking "Auto power-on" in Blueman PowerManager plugin configuration solved this issue for me.

Additionally (or alternatively) consider unchecking "Blueman Applet" in "Startup Applications Preferences".

[Colan Schwartz (colan)]

It wasn't in my startup applications, but installing "blueman" and disabling "Auto power-on" in there did the trick. I now have 2 icons for Bluetooth on my panel instead of 1, but that's fine.

[tom (tombuntus)]

I'm experiencing this in 19.10

[Michel-Ekimia (michel.ekimia)]

Several clients told us this problem as Well in 18.04

[Wazhai (wazhai)]

Still affects 20.04+. My laptop has Bluetooth and it always turns itself on after a restart.

[DiagonalArg (diagonalarg)]

Are you kidding me? Still in 20.04??