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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
