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

[Lukasz Stelmach]

On 20.11.2014 14:17, Lennart Poettering wrote:
> On Tue, 18.11.14 18:37, Łukasz Stelmach (stlman at poczta.fm) wrote:
> 
>> 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.

I talked to the kernel guys at my office and they told me that it is
quite usual (at least for USB devices, and my wlan and bt are USB)
that devices are stopped and unregistered in the kernel before
a system is suspended end reported as completely new ones
with increased numbers after machine resumes.
 
>> 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 "-"...

The above system-rfkill at rfkill9 failed because I tried to stop it
manually. Before I did it it was like all the others "loaded active
exited".

> 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...

As I wrote above, this isn't necessary a "kernel bug" but it may be
... "underdesigned" feature. I mean removing devices (at least USB)
before entering STR/S3 seems reasonable. I don't find (from the
kernel perspective) anything wrong with registering them with ever
increasing numbers after resume either. However, maybe, the way it
works together with user-land needs more attention.

-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL

REKLAMA: http://ars-fabrica.eu/ sklep z rękodziełem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141120/d9db423e/attachment.sig>