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

MUNEDA Takahiro muneda.takahiro at jp.fujitsu.com
Tue Sep 10 06:14:03 PDT 2013


On Mon, 9 Sep 2013 23:45:01 +0200,
Kay Sievers <kay at vrfy.org> wrote:

> On Mon, Sep 9, 2013 at 11:23 PM, MUNEDA Takahiro
> <muneda.takahiro at jp.fujitsu.com> wrote:
>
>> Ok, I found out another problem.
>> Even if I have a following udev rules and 'remove' event happens, no
>> systemd service will be called.
>>
>>    ACTION=="add|remove", TAG+="systemd", ENV{SYSTEMD_WANTS}="muneda at .service"
>>
>> My final goal is to invoke my systemd service which calls programs
>> that needs a bit long time when I do add/online or remove/offline my
>> device.  udev provided this feature before it's merged into systemd.
>
> 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.  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.

>> My previous patch let 'offline' event to remove device information
>> from systemd (probably, remove from udev database?), but systemd does
>> not call service as I expected.
>
> Systemd provides service *activation*, services and jobs can lazily
> get started when a device appears. It's usually the responsibility of
> the service itself to handle more events than the first one that
> activated it.
>
> Systemd is not really meant to be generic a job engine for device events.
>
> Things that run for an unpredictable amount of time should probably be
> handled by a proper running service on its own, activated by systemd
> and listening to udev events, and not just plugged into udev events,
> or run as a one-shot systemd service.

Thank you for the advise.
I wanted to use pre-existing tools as much as possible, but it seems
it doesn't exist.  So I'll check other way.

Thanks,
Takahiro


More information about the systemd-devel mailing list