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

[Andrei Borzenkov]

В Fri, 21 Nov 2014 01:26:36 +0100
Lennart Poettering <lennart at poettering.net> пишет:

> On Thu, 20.11.14 19:56, Lukasz Stelmach (stlman at poczta.fm) wrote:
> 
> > 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.
> 
> So, I have now added some code that adds BindsTo= for the device unit
> to the service.

It does not seem to work.

bor at opensuse:~> systemctl status systemd-rfkill at rfkill0.service
systemd-rfkill at rfkill0.service - Load/Save RF Kill Switch Status of rfkill0
   Loaded: loaded (/usr/lib/systemd/system/systemd-rfkill at .service; static)
  Drop-In: /etc/systemd/system/systemd-rfkill at .service.d
           └─bind.conf
   Active: active (exited) since Пт 2014-11-21 06:52:40 MSK; 15h ago
     Docs: man:systemd-rfkill at .service(8)
  Process: 636 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, status=0/SUCCESS)
 Main PID: 636 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/system-systemd\x2drfkill.slice/systemd-rfkill at rfkill0.service

bor at opensuse:~> systemctl --no-pager show -p BindsTo systemd-rfkill at rfkill0.service
BindsTo=sys-subsystem-rfkill-devices-rfkill0.device
bor at opensuse:~> systemctl status sys-subsystem-rfkill-devices-rfkill0.device
sys-subsystem-rfkill-devices-rfkill0.device
   Loaded: loaded
   Active: inactive (dead)

bor at opensuse:~> systemctl status sys-subsystem-rfkill-devices-rfkill1.device
sys-subsystem-rfkill-devices-rfkill1.device
   Loaded: loaded
   Active: inactive (dead)

bor at opensuse:~> systemctl status sys-subsystem-rfkill-devices-rfkill2.device
sys-subsystem-rfkill-devices-rfkill2.device
   Loaded: loaded
   Active: inactive (dead)

bor at opensuse:~> systemctl --full | grep rfkill
sys-devices-pci0000:00-0000:00:1a.0-usb3-3\x2d2-3\x2d2.1-3\x2d2.1:1.0-bluetooth-hci0-rfkill2.device loaded active plugged   /sys/devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2
sys-devices-pci0000:00-0000:00:1c.1-0000:0c:00.0-ieee80211-phy0-rfkill1.device                      loaded active plugged   /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/ieee80211/phy0/rfkill1
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 rfkill2
system-systemd\x2drfkill.slice                                                                      loaded active active    system-systemd\x2drfkill.slice
bor at opensuse:~> LC_ALL=C ll /sys/class/rfkill/
total 0
lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill1 -> ../../devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/ieee80211/phy0/rfkill1
lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill2 -> ../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2


>                 This won't fix much though, as the service is likely
> to fail in ExecStop= because it cannot find the device anymore.
> 

Should not it be garbage collected at some point (assuming it is
properly stopped that is)?

> For cases like this the tool is entirely useless I figure, since it
> can only save the rfkill state at shutdown now, but not on
> unplug. This means each time the device appears as hotplug we restore
> the state that was set during boot, but not the state from right
> before we went to suspend.
> 
> I figure the only proper fix for this is to make some daemon take
> responsibility, listen to events and store things to disk each time
> the setting changes... Not too enthusiastic about adding that
> though...
> 
> Lennart
>