Comment 4 for bug 1733321

This is the stack trace of the systemd-rfkill process before it gets killed by systemd after the timeout:

---------
(gdb) bt
#0 0x00007b3666783524 in __GI_ppoll (fds=0x7ffff9e8da40, nfds=1, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
#1 0x00007b36664cf140 in ppoll () at /usr/include/powerpc64le-linux-gnu/bits/poll2.h:77
#2 fd_wait_for_event (fd=<optimized out>, event=<optimized out>, t=<optimized out>) at ../src/basic/io-util.c:199
#3 0x000000aaa7712b50 in wait_for_initialized (ret=<synthetic pointer>, device=0x100241d0bc0, udev=<optimized out>) at ../src/rfkill/rfkill.c:141
#4 determine_state_file (udev=<optimized out>, event=0x7ffff9e8dbb8, d=0x100241d0bc0, ret=0x7ffff9e8dba8) at ../src/rfkill/rfkill.c:173
#5 0x000000aaa77120a8 in load_state (event=0x7ffff9e8dbb8, udev=<optimized out>, rfkill_fd=<optimized out>) at ../src/rfkill/rfkill.c:220
#6 main (argc=<optimized out>, argv=<optimized out>) at ../src/rfkill/rfkill.c:404
---------

The function wait_for_initialized() uses the udev monitor to listen for events from the rfkill subsystem and stay forever on the call to fd_wait_for_event() when the fake-rfkill module is loaded. I used udevadm to monitor the udev events and the add event is generated:

---------
$ udevadm monitor -s rfkill
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1741.847404] add /devices/virtual/rfkill/rfkill3 (rfkill)
UDEV [1741.855315] add /devices/virtual/rfkill/rfkill3 (rfkill)
---------

If the fake-rfkill module is removed and re-inserted before the 30s timeout, the processes receives and processes the remove and the subsequent add events.

So I suspected that, at least with fake-rfkill, systemd-rfkill is not activated fast enough to process the udev event when the rfkill device is added.