[systemd-devel] Out of order events

Lennart Poettering lennart at poettering.net
Fri Apr 1 09:48:10 UTC 2016


On Tue, 29.03.16 20:09, Nathaniel McCallum (npmccallum at redhat.com) wrote:

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

Everything. Also, note that the execution environment of the commands
is limited, for example, they run in their own mount namespace, so
that mounts done by them have no effect on the system itself.

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

You may pull in systemd services from udev rules, and for anything
that takes longer than a few instants, that's the recommended way to
go. See the bit about SYSTEMD_WANTS in systemd.device(5) for details.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list