save rfkill state only after a device is stable and around for at least 10s

[benzea]

I was doing some work on rfkill and noticed that there are certain conditions where a device is programatically added and removed and the rfkill state is restored to be blocked. This is weird, because the reason for the device to be added in the first place is because another rfkill switch has just been unblocked. The result is that disabling airplane mode in GNOME can result in bluetooth to be still disabled. See https://bugzilla.gnome.org/show_bug.cgi?id=781506 for detailed logs of what is happening in the error case (the error is surprisingly rare).

At this point I am thinking that the best solution here is to never put a device into the blocked state if it is plugged in at runtime (as opposed to boottime). So it is correct to restore the block state for e.g. an external USB bluetooth dongle. But if this dongle is attached after boot then it makes sense to assume the user wants to use the dongle and not block it even if there was a block state saved.

I am open to other suggestions of how to solve this issue.

[poettering]

well, there's no concept of "runtime" vs. "boottime", as hardware can take any time it wants to initialize, in particular when USB is involved.

I am not sure I grok the problem though: why would the disappearing rfkill device be set to "off" anyway? systemd-rfkill only saves/restores the state it last saw, that's all...

wouldn't it make more sense if GNOME would always propagate its own idea of flight mode into all devices appearing? i.e. if GNOME manages airplane state and thinks we are in airplane mode, then everything that is plugged in should be turned off by it, but if it things we are in normal mode, then it should instead turn everything on

[benzea]

The problem here is that GNOME blocks the rfkill for all devices in airplane mode. So the bluetooth dongle is first blocked and then removed within a few ms. systemd restores this blocked state later on after GNOME unblocks all handlers (which causes the rfkill switch to reappear).

GNOME could try to set the block state it is expecting whenever an rfkill is added. But it will then race with systemd doing the same thing unless there is a way to block systemd-rfkill from setting the state …

[benzea]

Really, it is the weird thing of having two rfkill handlers for one device and the second one keeps disappearing while the first one is blocked.

[poettering]

Hmm, maybe an OK way out would be if we'd delay the disk update for a short timeout (let's say 10s). If a device disappears in that time we will cancel the write. That basically means we only save the state that is in effect for at least 10s or so. That should fix the issue at hand, no?

[benzea]

Hmm, yup, that does sound like a sane workaround for the issue at hand. It does not change things for e.g. a usb bluetooth dongle plugged in while in airplane mode, but I am not even sure what the correct behaviour is in that case. So I think it would be fine to go forward with it like that.

[poettering]

Of course, would be delighted to accept a patch for that! ;-)