[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