Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action
On Di, 05.02.19 13:08, Martin Wilck (mwi...@suse.de) wrote: > On Mon, 2019-02-04 at 13:19 +0100, Lennart Poettering wrote: > > > > 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. > > Right. Then, maybe, udev should treat & report attempts to refer to > sysfs attributes in rules for "remove" events as errors in the first > place? Checking that is not trivial. After all the language knows GOTO and negative comparisons, and whatnot. Hence it's not trivially determinable whether some rule will run in ACTION=="remove"... But if you can come up with a crisp patch for this, but all means, submit as PR and we can review it. (I do fear that as soon as if we'd turn this on then this will complain about a major chunk of rules files. Hence should be a warning, not an error, and might still be controversial then) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action
On Mon, 2019-02-04 at 13:19 +0100, Lennart Poettering wrote: > > 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. Right. Then, maybe, udev should treat & report attempts to refer to sysfs attributes in rules for "remove" events as errors in the first place? Regards, Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev “PROGRAM/RUN” command not working properly for “REMOVE” action
On 04.02.2019 13:19, Lennart Poettering wrote:
> On Do, 31.01.19 14:46, Ziemowit Podwysocki
> (ziemowit.podwyso...@globallogic.com) 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to speed up detection of emmc partition and mount the filesystem
On Mo, 04.02.19 20:22, Petr (co...@atlas.cz) wrote: > Hello, > > I have custom linux on embedded machine generated with Buildroot > using emmc drive which contains root filesystem on /dev/mmcblk0p2 > and application data on /dev/mmcblk0p4. The root fileystem is > mounted pretty quickly, but the application data are mounted about > 1.7s after systemd starts, the main reason is that the mmcbl0p4 is > found by systemd after 1.4s. As a workaround I created service that systemd will "see" the device as soon as udev reports it to be around, i.e. after it was triggered via "systemd-udev-trigger.service", then reported to userspace, then probed by udev's blkid logic, and finally reported to systemd by udev. There are plenty tools available that help you analyzing what is being done in early boot that delays stuff, for example systemd-bootchar (a separate project from systemd itself). If you want to tune this, you could trigger storage devices first, which also generally means they are announced, probed and so on first. > is executed right after the local-fs-pre.target which execute "mount > /dev/mmcblk0p4 /app" and that works, but I would like to know if > there is correct way how to tell systemd that I want to mount the > root fs and application fs sooner than everything else (I believe > that what I want is to tell systemd to mount /dev/mmcblk0p4 without > waiting for udev to find /dev/mmcblk0p4 as new device and start auto > mount). > > This log appears after 1.4s from systemd starts, but I need that device much > sooner: You can mark any mount as automount in /etc/fstab, by adding x-systemd.automount to the mount options. If so systemd will generate both an .automount unit, and a .mount unit for it, and only the .automount unit is started early. This is an effective parallelization technique and allows you to have any mount you like appear in the file system at a moment where its backing device hasn't shown up yet, its fsck hasn't run yet or its kernel mount not established yet. It works very well for every fs that isn#t needed immediately during early boot, since it basically allows establishing of mounts ahead of time, where direct access will block but not the simple act of mounting. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to speed up detection of emmc partition and mount the filesystem
On 2/4/19 7:22 PM, Petr wrote: Hello, I have custom linux on embedded machine generated with Buildroot using emmc drive which contains root filesystem on /dev/mmcblk0p2 and application data on /dev/mmcblk0p4. The root fileystem is mounted pretty quickly, but the application data are mounted about 1.7s after systemd starts, the main reason is that the mmcbl0p4 is found by systemd after 1.4s. As a workaround I created service that is executed right after the local-fs-pre.target which execute "mount /dev/mmcblk0p4 /app" and that works, but I would like to know if there is correct way how to tell systemd that I want to mount the root fs and application fs sooner than everything else (I believe that what I want is to tell systemd to mount /dev/mmcblk0p4 without waiting for udev to find /dev/mmcblk0p4 as new device and start auto mount). Hmm... your solution could be a simple type mount unit which is ordered before the local-fs-pre.target but maybe not. + there are two type of embedded paths in this world those that are super tiny resource constrained and those that are not. Former you dont use systemd for but instead some linux micro platform usually tied to or associated with internet of terror devices ( IoT ) like Soletta project, the latter you do use systemd for but only after systemd has been put on a diet so you will need to provide proper context here as in what that custom embedded devices does or is trying to do and why you need to shave those 1.4s off, what's the problem you are trying to solve with it? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
