[systemd-devel] Out of order events

[Nathaniel McCallum]

On Tue, 2016-03-29 at 23:20 +0000, Mantas Mikulėnas wrote:
> 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...

>From the udev man page:

"Starting daemons or other long-running processes is not appropriate
for udev; the forked processes, detached or not, will be
unconditionally killed after the event handling has finished."

Does this kill just the child processes? Or does it kill grandchild
processes as well?

/etc/crypttab definitely won't work for my case (which, if you want
more information, is https://github.com/latchset/tang).

I could classify my process as "medium-running." It might block, but no
longer than the specified timeout (default 10 seconds). So I'd like to
avoid a whole separate daemon for this.

> 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
> >