On 05/02/18 13:40, Axel Beckert wrote:
Control: merge 889608 -1
Hi Ben,
thanks for the bug report.
Ben Caradoc-Davies wrote:
under man-db 2.8.0-1 amd64 all man pages fail to display with:
$ man man
man: command exited with status 4: /usr/lib/man-db/zsoelim | /usr/lib/man-
db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl |
nroff -mandoc -rLL=184n -rLT=184n -Tutf8
Ben Caradoc-Davies wrote:
With 2.8.0-1, I see AppArmor messages in the systemd journal for "man man":
This sounds like https://bugs.debian.org/889608 reported only shortly
before your bug report. Hence merging.
Thanks, Axel. I just read the MAN_DISABLE_SECCOMP=1 discussion in
#889608 and I concur that they are likely the same apparmor problem.
Ben Caradoc-Davies wrote:
And what I would like to know is how the fscking apparmor module got
loaded in the first place, given that I have the apparmor service
masked:
# ls -al /etc/systemd/system/apparmor.service
lrwxrwxrwx 1 root root 9 Dec 8 11:24
/etc/systemd/system/apparmor.service -> /dev/null
Yet:
# aa-status
apparmor module is loaded.
You've masked a systemd service. But "module" probably refers to some
kernel module here, which is enabled by default since a while in
Debian Unstable.
Yes, I think you are right. I am guessing that the man-db package
install phase dh_apparmor command loads or enables the kernel apparmor
module and the man apparmor profile. Masking apparmor.service only
prevents profile loading at boot time, but this is why rebooting with
apparmor.service masked restore man functionality.
Kind regards,
--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand
