2014-11-20 14:17 GMT+01:00 Lennart Poettering <lenn...@poettering.net>: > On Tue, 18.11.14 18:37, Łukasz Stelmach (stl...@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@rfkill0.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill0 >> systemd-rfkill@rfkill1.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill1 >> systemd-rfkill@rfkill2.service loaded active exited Load/Save RF Kill >> Switch Status of rfkill4 >> systemd-rfkill@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@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@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? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
