[systemd-devel] [PATCH] Remove device and its relatives when action is offlined
MUNEDA Takahiro
muneda.takahiro at jp.fujitsu.com
Tue Sep 10 06:23:11 PDT 2013
On Tue, 10 Sep 2013 02:25:19 +0200,
Lennart Poettering <lennart at poettering.net> wrote:
> On Mon, 09.09.13 17:23, 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.
>> 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 only cares for add and remove events, nothing else, and will do
> so only for devices tagged with the "systemd" udev tag. It will
> activate devices when "add" is sent, and deactivate them when "remove"
> is sent. You can pull in arbitrary services via SYSTEMD_WANTS (which
> causes a "Wants" type dependency from the device unit be created to the
> specified service unit. And you can bind units back to the device unit
> via "BindsTo=" in the service unit.
Yeah, this is an answer what I wanted to know. I mis-understood what
'SYSTEMD_WANTS' means.
> The udev rule above will not work, as you are can only add dependencies
> to to instantiated unit names. Try
> ENV{SYSTEMD_WANTS}="muneda@%k.service" or suchlike, instead. Also,
My bad. I made a mistake while copy and paste.
> ACTION="remove" doesn't make much sense for this...
Yes, it makes sense to me with your explanation.
Thanks,
Takahiro
More information about the systemd-devel
mailing list