<div dir="ltr">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.)</div> 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... <div class="gmail_quote"><div dir="ltr">On Wed, Mar 30, 2016, 01:15 Nathaniel McCallum <<a href="mailto:npmccallum@redhat.com">npmccallum@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div>