I noticed that the mandb process (cronjob) from sys-apps/man-db-2.8.7 was running xz and used 100% cpu time strace shows that it loops in clock_gettime64(CLOCK_REALTIME, 0xbf935c2c) = -1 EPERM (Operation not permitted) I upgraded to man-db-2.9.3, but currently I'm unable to manually run su man -s strace /bin/sh -c nice mandb as it gives su: Authentication service cannot retrieve authentication info So I can't confirm that it doesn't work, but looking at the sources it seems to miss modified clock_gettime64, ...nanosleep64 patches like those found in the net-misc/openssh seccomp patches for glibc-2.31 compatibility. I didn't find any #define magic in the sources, so I don't think that I can't find anything about glibc-2.31 fixes in the ChangeLog - so I think it still doesn't work with seccomp (or I missed the change). Reproducible: Always Steps to Reproduce: Wait for the cronjob to run Actual Results: mandb from sys-apps/man-db-2.8.7 loops (forever) Expected Results: mandb finishes its work. From the glibc-2.31 changelog: "System call wrappers for time system calls now use the new time64 system calls when available. On 32-bit targets, these wrappers attempt to call the new system calls first and fall back to the older 32-bit time system calls if they are not present. This may cause issues in environments that cannot handle unsupported system calls gracefully by returning -ENOSYS. Seccomp sandboxes are affected by this issue." Maybe a quick&dirty fix would be to fix seccomp to return -ENOSYS in those cases, but probably it is better to adjust the seccomp filters to enable usage of the new functions.
I am also seeing this on my x86 system, but not my x86_64 system.
I see exactly the same thing on s390.
(In reply to Sam James from comment #2) > I see exactly the same thing on s390. Aha: https://lists.nongnu.org/archive/html/man-db-devel/2020-08/msg00000.html. >This is motivated by my arm32 (musl) machine and discussion with Rich >Felker. Without these changes, man invokes xz which calls >clock_gettime64 in a loop, spinning endlessly. clock_gettime64 is surprisingly missing from man-db's seccomp sandbox. We need to add it in, as upstream have (not yet in a release): https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7315a9475d8fa37af49e9e7ed11e1534f23ef70b This is the obvious solution but it's nice to not have to make things up.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de6efe6b3e28eea299401244e7b506a6f9c22d51 commit de6efe6b3e28eea299401244e7b506a6f9c22d51 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-12-23 19:13:51 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-12-23 19:13:51 +0000 sys-apps/man-db: allow clock_gettime64 syscall Closes: https://bugs.gentoo.org/744712 Signed-off-by: Mike Gilbert <floppym@gentoo.org> .../files/man-db-2.9.3-clock_gettime64.patch | 44 ++++++ sys-apps/man-db/man-db-2.9.3-r1.ebuild | 162 +++++++++++++++++++++ sys-apps/man-db/man-db-9999.ebuild | 4 +- 3 files changed, 209 insertions(+), 1 deletion(-)
