On Wed, Apr 04, 2018 at 06:35:12PM +0000, Thorsten Glaser wrote: > Hi Colin, > >tglase@tglase:~ $ man ls > >man: nroff: Bad system call > > Manual page ls(1) line ?/? (END) (press h for help or q to quit) > > any progress on this? Can I disable the seccomp stuff locally, > using a configuration file or something? It’s kinda annoying > after a while, on my $dayjob desktop which uses x32.
Hmm. So I just dug out the VM that I'd been using to look into this, brought it up to date, and found that man works fine for me: this is a sid x32 chroot on a stretch amd64 base system running a 4.9.0-4-amd64 kernel. So that means I'm sort of stalled on this for now: perhaps it's worth seeing if any of the other fixes in 2.8.3 happen to cover this? The strace shows nroff being killed by SIGSYS immediately after the execve, with no indication of what system call it attempted that failed, but if it's the clock_gettime thing I speculated on earlier then https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=770cd67aaf711b2cded9cbc2f9e503ca0f5e73ba should fix it. In the meantime, you can add MAN_DISABLE_SECCOMP=1 to your environment as a workaround (but please remember to remove that again once I release 2.8.3 so that we can tell whether it fixes the problems). > Also, this might be related: I see this at the tail of a failed > buildd log, for sh4, on a buildd which uses qemu: > > dh_installman -a -O--buildsystem=cmake > man: ../../../src/man.c:2334: display: Assertion `man_file' failed. This is unrelated. I just went through the code and I can't see any possible path that would cause this assertion to fail, but perhaps you could file a separate bug for this? > qemu: uncaught target signal 6 (Aborted) - core dumped > dh_installman: man -l --recode UTF-8 > ./debian/musescore/usr/share/man/man1/mscore.1.gz > > debian/musescore/usr/share/man/man1/mscore.1.gz.dh-new died with signal 6 > dh_installman: Aborting due to earlier error > make: *** [debian/rules:10: binary-arch] Error 2 > > Perhaps seccomp is confusing qemu here, too? I doubt it - that's just qemu getting SIGABRT due to a failed assert, which seems normal. -- Colin Watson [cjwat...@debian.org]
