tests: (lslcoks) insert a sleep between taking a lock and running lslocks#2633
Conversation
…ocks Close util-linux#2624. It appears that there is a time lag between locking and its visibility in /proc/locks. See the unstbale results of errors I observed in util-linux#2629. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
|
It is nothing unusual that userspace is faster than the kernel. Frankly, I do not see any elegant way to resolve it. |
|
Isn't the problem that the Some synchronization should help. |
mkfds works as you wrote. mkfds prints its PID after taking the lock as specified in its cmdline. Test cases use 'read' built-in to get the PID from the coproc. |
|
I'll inspect more in the future. |
|
Yes, coproc was also my first thing to blame, but from mkfds' code it seems it locks the file, and later it prints the PID, which the script is waiting for. I guess the |
My bad. I should have read the code before speculating. |
I verified various possibilities in 7c958c6 . I guess there is a time lag between locking and its visibility in /proc/locks (or locks field of /proc/$pid/fdinfo/$fd), though I cannot believe it. I need a much smaller program that just (1) takes a lock, then (2) prints the information about the lock extracted from /proc. If my guess is correct, the smaller program can reproduce it. |
|
In the first log of #2629 (comment) Very weird. |
…g a /proc/[0-9]* fails If a process ($pid) taking a lock is gone while running lslocks, gathering per process information for the process may fail in opening /proc/$pid. Though lslocks should work with incomplete information, the original code stopped gathering per process information. As a result of the original behavior, tests/ts/lslocks/lslocks failed rarely in the environment where multiple test cases simultaneously. Close util-linux#2624 again. See also util-linux#2633. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…g a /proc/[0-9]* fails If a process ($pid) taking a lock is gone while running lslocks, gathering per-process information for the process may fail in opening /proc/$pid. Though lslocks should work with incomplete information, the original code stopped gathering per-process information for the other processes. As a result of the original behavior, tests/ts/lslocks/lslocks really failed in the environment where multiple test cases simultaneously. Close util-linux#2624 again. See also util-linux#2633. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…g a /proc/[0-9]* fails If a process ($pid) taking a lock is gone while running lslocks, gathering per-process information for the process may fail in opening /proc/$pid. Though lslocks should work with incomplete information, the original code stopped gathering per-process information for the other processes. As a result of the original behavior, tests/ts/lslocks/lslocks really failed in an environment where multiple test cases ran simultaneously. Close util-linux#2624 again. See also util-linux#2633. Signed-off-by: Masatake YAMATO <yamato@redhat.com>
…g a /proc/[0-9]* fails If a process ($pid) taking a lock is gone while running lslocks, gathering per-process information for the process may fail in opening /proc/$pid. Though lslocks should work with incomplete information, the original code stopped gathering per-process information for the other processes. As a result of the original behavior, tests/ts/lslocks/lslocks really failed in an environment where multiple test cases ran simultaneously. Close util-linux#2624 again. See also util-linux#2633. Signed-off-by: Masatake YAMATO <yamato@redhat.com> (cherry picked from commit 20df923)
Close #2624.
It appears that there is a time lag between locking and its visibility in /proc/locks. See the unstbale results of errors I observed in #2629.