Afaik, udev only re-emits a uevent once it's done processing all the rules – this part is by design. So in your case, while udev worker 1 is still waiting for the RUN to finish, worker 2 receives a kernel uevent for the cryptsetup device and quickly reemits it. (See the output of "udevadm monitor", for example – compare the kernel events and udev events there.)
So personally I'd classify udev rules with side effects as "broken as expected". Avoid recursion, avoid long-running processes, avoid touching X11, and so on. If you want to automatically unlock volumes, list them in /etc/crypttab with "auto" and let systemd-cryptsetup handle them. (It works by putting service symlinks in *.device.wants/, so as soon as dev-sda1.device appears, the corresponding "unlock" service is started.) If you don't have systemd, well. Maybe tell sh to spawn cryptsetup& "in background" rather than waiting for it... On Wed, Mar 30, 2016, 01:15 Nathaniel McCallum <[email protected]> wrote: > I have a rule like this: > > ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="crypto_LUKS", > ENV{ID_FS_VERSION}="1", RUN+="sh -c 'echo password | cryptsetup open > $devnode luks-$env{ID_FS_UUID_ENC}'" > > Okay, my real rule isn't so security braindead, but the above will > suffice for concept. :) > > What I find interesting is that the udev events happen backwards in > this case. First, two udev events are generated for the new plaintext > block device and then finally I get the add event for the ciphertext > block device. For instance: > > import pyudev > > context = pyudev.Context() > monitor = pyudev.Monitor.from_netlink(context) > monitor.filter_by('block') > > for dev in iter(monitor.poll, None): > print dev > ... > Device(u'/sys/devices/virtual/block/dm-0') > Device(u'/sys/devices/virtual/block/dm-0') > Device(u'/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1- > 1.3:1.0/host52/target52:0:0/52:0:0:0/block/sdc') > > None of the services listening for block events seem to cope well with > this. They all anticipate that sdc will appear first, and then dm-0. > > Is this simply as designed? Is this a bug? Undefined behavior? > > And, most importantly, is there a better way to do what I'm trying to > do? I'd like to avoid running my own daemon if possible. > _______________________________________________ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
