/proc/locks is host-wide and the kernel serves it over several read() calls,
resuming by record index. When other processes add or drop locks between
those reads the table shifts and entries are skipped, so a lock that is
still held can read as gone.
- tests: the live-DB preview and header-probe lock tests read their own
process's locks from /proc/locks and flaked on busy CI hosts (1 in 12 on
a quiet box; 9 in 12 with six processes churning locks). A shared
tests/posix_lock_probe.own_posix_locks() reads /proc/self/fdinfo instead,
which lists this process's locks per open file in one read.
- hermes_state_lockowners: state_db_write_lock_holders() names the writer
in the "state.db write lock unavailable" warning. One pass could skip the
holder and log "no write-class lock held at the deadline". It now unions
three passes; a skip rarely repeats.
35272ce28b