Re: udev “PROGRAM/RUN” command not working properly for “REMOVE” action

[Ziemowit Podwysocki <ziemowit.podwysocki@xxxxxxxxxxxxxxx>]

On 04.02.2019 13:19, Lennart Poettering wrote:
> On Do, 31.01.19 14:46, Ziemowit Podwysocki (ziemowit.podwysocki@xxxxxxxxxxxxxxx) wrote:
>
>> Hello,
>>
>> I have multiple exactly same USB devices. Each device enumerates
>> multiply ttyACM ports under /dev directory. Each port has it unique
>> purpose, one is for handling some commands, another is diagnostic, etc.
>> What I want is to alias tty's for particular device by creating symlinks
>> with the ability to distinguish to which device this port belongs.
>>
>> For example:
>>
>> /    DEVICE_UNIQUENUM_PURPOSE/
>>
>> /    /dev/MODULE_0_DIAG
>>     /dev/MODULE_0_CMD
>>     /dev/MODULE_1_DIAG
>>     /dev/MODULE_1_CMD/
>>
>> To achieve this I started working with udev to write rules for my
>> device. I learned that udev is not able to enumerate symlinks for the
>> same device in the sophisticated way I want it. So I decided to write
>> bash script which do all the work. Here are the rules:
>>
>> /    ACTION=="add", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty",
>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063",
>> PROGRAM="/bin/bash /home/user/script.sh %k", SYMLINK+="%c"
>>     ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
>> ATTRS{idVendor}=="1e2d", ATTRS{idProduct}=="0063", PROGRAM="/bin/bash
>> /home/user/script.sh"/
> reading sysfs attrs is problematics from "remove" rules, as the sysfs
> device is likely to have vanished by then, as rules are executed
> asynchronously to the events they are run for.
>
> udev will import the udev db from the last event it has seen on a
> device on "remove", but sysfs attrs are not stored in the udev
> db. hence, consider testing against udev db props here, not sysfs
> attrs.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat

Hello Lennart,

you are correct. I've already managed to found it by myself. sysfs
device indeed is not present during udev remove rules being resolved.
After referring to udev environmental variables everything started
working properly.

BR,

Ziemowit


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel