-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
udevadm: introduce 'wait' command #22872
Conversation
TODO:
|
done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, the concept is great, but i am very sure we shouldn#t use inotify for this, but use proper sd-event apis, i.e. the device monitor.
i.e. more along the lines of device_wait_for_devlink().
i.e. it is crucial for this tool to be useful that the complete udev ruleset ran for the device, i.e. we should only report ready once the udev db exists.
@poettering Thank you for the review. All comments are addressed. PTAL. |
@poettering Thank you for the review. Hopefully, all comments are addressed. PTAL. |
The CI failures are by the tests for homed or dissect, should not be related. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks really good
helper_check_device_symlinks "/dev/disk" | ||
# Reconnect the iSCSI devices and check if everything get detected correctly | ||
iscsiadm --mode discoverydb --type sendtargets --portal "$target_ip" --discover | ||
iscsiadm --mode node --targetname "$target_name" --portal "$target_ip:$target_port" --login | ||
udevadm settle | ||
udevadm wait --settle --timeout=30 "${expected_symlinks[@]}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really need --settle
on these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Not only 'add' but 'change' event may be already queued for the devices.
Another candidate for sd_device_open() is src/gpt-auto-generator/gpt-auto-generator.c's open_parent_block_device()... |
50a6c37
to
148fb2f
Compare
@poettering Thank you for the review. Most comments are addressed. PTAL.
Let's update it in later PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
and sd_device_new_from_path() which takes devname or syspath.
Prompted by systemd#22717 (comment). The new command 'udevadm wait' waits for device or device symlink being created. This may be useful to wait for a device is processed by udevd after e.g. formatting or partitioning the device.
As it is defined at linux/fs.h.
And move it from loop-util.[ch] -> fd-util.[ch]
We usually open() device node obtained by sd_device_get_devname(). However, the device node corresponds to the sd-device object may be already removed, and another device node with the same path may be created, hence an unexpected device may be opened. The sd_device_open() opens device node, and checks the devnum and diskseq of opened devnum, to avoid the above possibility. Prompted by systemd#22906 (comment).
@poettering Thank you. The above two comments are addressed. Upgrading the green label. |
Prompted by #22717 (comment).