[systemd-devel] [PATCH] Remove device and its relatives when action is offlined

MUNEDA Takahiro muneda.takahiro at jp.fujitsu.com
Tue Sep 10 09:51:20 PDT 2013


On Tue, 10 Sep 2013 15:36:26 +0200,
Kay Sievers <kay at 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


More information about the systemd-devel mailing list