On Mon, 9 Sep 2013 23:45:01 +0200,
Kay Sievers <[email protected]> wrote:
On Mon, Sep 9, 2013 at 11:23 PM, MUNEDA Takahiro
<[email protected]> 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}="[email protected]"
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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
