Bug 744712

Summary:	sys-apps/man-db: high CPU usage in cronjob after upgrading to glibc-2.31 on x86
Product:	Gentoo Linux	Reporter:	Huemi <gentoobugs>
Component:	Current packages	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	RESOLVED FIXED
Severity:	normal	CC:	admorgan, sam
Priority:	Normal
Version:	unspecified
Hardware:	x86
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	761436

Description Huemi 2020-09-25 18:54:01 UTC

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.

Comment 1 Austin Morgan 2020-10-11 05:55:28 UTC

I am also seeing this on my x86 system, but not my x86_64 system.

Comment 2 Sam James archtester

2020-12-23 05:17:42 UTC

I see exactly the same thing on s390.

Comment 3 Sam James archtester

2020-12-23 05:28:26 UTC

(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.

Comment 4 Larry the Git Cow gentoo-dev

2020-12-23 19:15:03 UTC

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(-)