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

Lennart Poettering lennart at poettering.net
Thu Nov 20 05:17:10 PST 2014


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

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list