This is an automated change & the command used is:
find -name '*.signatures.json' -exec sh -c '[ -n "$(tail -c1 {})" ] && echo >> {}' \;
Reference: https://stackoverflow.com/a/729795
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Regression identified when using flock disk locking with 5.10 kernel and
systemd-239. During unlock_disk_and_settle(), udevadm settle will not
complete and eventually timeout after 2 minutes. When looking at the
systemd-udevd logs, the daemon crashes and produces the following stack
trace:
Stack trace of thread 1531:
#0 0x00007fd73d9be405 recvmsg (libpthread.so.0)
#1 0x00007fd73dab33b8 udev_monitor_receive_device (libsystemd-shared-239.so)
#2 0x0000600347316201 on_uevent (systemd-udevd)
#3 0x0000600347316667 on_inotify (systemd-udevd)
#4 0x00007fd73dbad6d7 source_dispatch (libsystemd-shared-239.so)
#5 0x00007fd73dbaf4e5 sd_event_dispatch (libsystemd-shared-239.so)
#6 0x00007fd73dbaf678 sd_event_run (libsystemd-shared-239.so)
#7 0x00007fd73dbaf89f sd_event_loop (libsystemd-shared-239.so)
#8 0x00006003473132df run (systemd-udevd)
#9 0x00007fd73d80e133 __libc_start_main (libc.so.6)
#10 0x0000600347313efe _start (systemd-udevd)
The failing behavior appears to be directly linked to the "exec FD"
actions. A quick way to replicate this issue in the repro environment:
exec 9<>$disk
exec 9>&-
udevadm settle
This patch comments out the initial lock_disk() call, which makes
unlock_disk_and_settle() return early because ${FLOCK_DISK_FD} is not
set to a valid FD, avoiding the file descriptor actions that lead to
the failing behavior.
Note that this change does re-introduce the possibility of udev race
conditions during the disk operations, effectively reverting this
behavior to pre-0.32 behavior.
Signed-off-by: Chris Co <chrco@microsoft.com>
Minghe Ren
Muhammad Falak R Wani
jslobodzian
Chris Co
Henry Beberman