[systemd-devel] Out of order events

[Mantas Mikulėnas]

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 <npmccallum at redhat.com>
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
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160329/4c8833b4/attachment.html>