[systemd-devel] [BUG] too many rfkill services

[Dan Williams]

On Thu, 2014-11-20 at 14:56 +0100, Michael Biebl wrote:
> 2014-11-20 14:17 GMT+01:00 Lennart Poettering <lennart at poettering.net>:
> > On Tue, 18.11.14 18:37, Łukasz Stelmach (stlman at poczta.fm) wrote:
> >
> >> Hi.
> >>
> >> Recently, after I had found an update for my BIOS, my desktop started to
> >> resume properly (before I could only suspend it). Kernel and systemd do
> >> their jobs fine. But they seem to have problem cooperating.
> >>
> >> For the record I use systemd 215, which means that the issue I describe
> >> here may have been fixed already.
> >>
> >> After several suspend/resumes systemctl shows more than three dozens of
> >> rfkill devices even though I've got only one BT and one WLAN.
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> systemd-rfkill at rfkill0.service   loaded active exited    Load/Save RF Kill Switch Status of rfkill0
> >> systemd-rfkill at rfkill1.service   loaded active exited    Load/Save RF Kill Switch Status of rfkill1
> >> systemd-rfkill at rfkill2.service  loaded active exited    Load/Save RF Kill Switch Status of rfkill4
> >> systemd-rfkill at rfkill3.service  loaded active exited    Load/Save RF Kill Switch Status of rfkill4
> >>
> >> [...]
> >
> > This really smells like a kernel bug. systemd gets the device names
> > via udev from the kernel, hence it's probably some driver bug that
> > creates these devices incorrectly.
> >
> >> Nov 18 18:24:02 kotik systemd[1]: Stopping Load/Save RF Kill Switch Status of rfkill9...
> >> Nov 18 18:24:02 kotik systemd[1]: systemd-rfkill at rfkill9.service: control process exited, code=exited status=1
> >> Nov 18 18:24:02 kotik systemd[1]: Stopped Load/Save RF Kill Switch Status of rfkill9.
> >> Nov 18 18:24:02 kotik systemd[1]: Unit systemd-rfkill at rfkill9.service entered failed state.
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> The actual issue as I see it is that systemd does not stop and remove
> >> rfkill services that refer to nonexistent devices.
> >
> > Yes, we do not flush out information about failed services by default
> > so that the admin can have a look and figure out what's going on. If
> > this is not desired, then the binary path in ExecStart= should be
> > prefixed with "-"...
> >
> > I think in this case (and by default) we should keep track of errors
> > though, even if it is annoying. But systemd is really not the place to
> > work around all possible kernel bugs...
> 
> I had some rather "interesting" experience with the rfkill service as well.
> See [1]. Basically, running rfkill on one device, made the other device go away.

That's normal behavior in the case of a platform rfkill device and a
device-specific rfkill device.  The platform rfkill functionality can
sometimes (often?) cut power to the device through BIOS and GPIOs, and
it will drop off the USB or PCI bus.  But the device itself can also
expose rfkill functionality through it's own drivers, that doesn't cause
it to drop off the bus.  This is your case with the USB-based Bluetooth
device and the BIOS-based platform killswitch.

Since the routing of all these rfkills is highly model specific, there
is no way to know that the platform rfkill has an affect on any other
device in a generic way.  That would have to be hardcoded into the
kernel and would be pretty awful to maintain.

Dan