On Tue, 10 Sep 2013 15:36:26 +0200,
Kay Sievers <k...@vrfy.org> wrote:
Udev still does all what did before systemd. It was never really able
to run or start long-running tasks. Udev can only reliably handle
synchronously started and very short-living programs, and that was
always the case.
Ahh, you are correct.
But, we used to use a 'trick' to call long-running task by adding '&'
to kill the relationship between udev and task.
Ah, you mean you wrapped it in /bin/sh and added & there?
Yeah, that's the easiest way to detect the uevent and call my own
programs for the event.
Udev never supported any sort of detaching. It's really fragile to do
that, because unlike systemd, udev will fork the same thing over and
over with every event, which can easily cause problems.
Understand. My device is a bit uncommon so it has a specific sysfs
path. Then I can make a strict rule jsut for device not to detect
events for other devices.
However, current
implementation does not allow to do that, because even if we call a
such task by adding '&', all processes are under same cgroup and all
process will be killed.
So, my understanding is that we don't have such tricks anymore.
If you need to do that, which we really do not recommend to ever do,
you need to move out of udev's own cgroup, otherwise udev will
rightfully "clean up the mess" you left behind. :)
I would like to choose more generic way.
My first idea was to invoke my own service from udev rules and escape
from the udev's cgroup, but it's not a good way. I'm thinking to have
my own daemon to listen uevent directly or get a notification from
udev rules which finishes shortly.
Thanks,
Takahiro
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
