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

[Michael Biebl]

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.
Since there is a race, systemd-rfkill failed for that device, leading
to an error message on every boot.
A BindsTo= would probably help here as well.

So while we are at that topic, would be great to have some input on [1].

Michael

[1] https://bugs.freedesktop.org/show_bug.cgi?id=83730
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?