On Tue, 18.11.14 18:37, Łukasz Stelmach ([email protected]) 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--- > [email protected] loaded active exited Load/Save RF Kill > Switch Status of rfkill0 > [email protected] loaded active exited Load/Save RF Kill > Switch Status of rfkill1 > [email protected] loaded active exited Load/Save RF Kill > Switch Status of rfkill4 > [email protected] 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]: [email protected]: 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 [email protected] 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
