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.
> 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.
Kay
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
