Bug#996876: Re: Re: Bug#996876: XFS excessive logging on bind mounts

[Michael Biebl]

Am 20.10.21 um 13:51 schrieb 10dmar10:

m 20.10.21 um 12:27 schrieb Michael Biebl:

Am 20.10.21 um 12:08 schrieb 10dmar10:

Ok, thanks!

You're right, the kernel should probably issue warnings only on
mounts, not remounts.

* Any idea why those warnings started to appear only after recent
systemd update?

 From which version did you upgrade?

systemd 247.9-4, i'm always on testing and safe-upgrade almost daily.

Did you upgrade the kernel as well or other parts of the system?

Last kernel upgrade on my machine was on 12.09.2021,
otherwise only 'aptitude safe-upgrade', nothing else.

First warnings appearance in my log files,
probably shortly after I upgraded to current systemd version:

Okt 15 21:28:07 tetranode kernel: xfs filesystem being remounted at
/run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 15 21:28:07 tetranode kernel: xfs filesystem being remounted at
/run/systemd/unit-root/var/tmp supports timestamps until 2038
(0x7fffffff)
Okt 15 21:28:07 tetranode kernel: xfs filesystem being remounted at
/run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 15 21:28:07 tetranode kernel: xfs filesystem being remounted at
/run/systemd/unit-root/var/tmp supports timestamps until 2038
(0x7fffffff)


Before that there was only one single remount in each boot log, like this one:

Okt 14 18:56:02 tetranode kernel: xfs filesystem being remounted at /
supports timestamps until 2038 (0x7fffffff)

Thanks.

I looked into this a bit and I'm pretty sure this is caused by
https://github.com/systemd/systemd/commit/d8e3c31bd8e307c8defc759424298175aa0f7001

which tightened the NoNewPrivileges=yes sandboxing feature a bit more.

This change is part of v249, so would confirm that you didn't see it with v247

* Is masking systemd-hostnamed.service a valid solution to prevent log spam?
At least until the kernel developers do something about those warnings.

I guess someone would need to inform them about this issue.

Seems to be a known issue:

https://lore.kernel.org/lkml/alpine.deb.2.21.99999.375.1912261445200.21...@trent.utfs.org/

Thanks for the ref.
Seems the discussion has unfortunately died down :-/

(I don't think i'll ever need systemd-hostnamed.service, my machine's
host name is very static:
-rw-r--r-- 1 root root 10 31. Jan 2010  /etc/hostname)

I think most software uses the D-Bus interface to query the hostname, not change
it. I can't really say, if masking systemd-hostnamed.service has any undesired
side-effects.
If you mask the service, you will likely get an error in the journal, if other
software can not access the hostnamed service and if your objective is to avoid
log messages, that would be counter productive I guess.
And systemd-hostnamed.service is by far not the only service which uses those
sandboxing features.

Ok, I will wait for kernel update.

If you want to do the latter, you can create a file
/etc/systemd/system/service.d/disable-NNP.conf containing
[Service]
NoNewPrivileges=
NoNewPrivileges=no



Be aware, that this weakens the sandbox a little.

Instead of masking the services which use NoNewPrivileges=yes, you could alternatively disable this sandboxing feature on a case by case basis or globally. If you only want to disable this warning for systemd-hostnamed.service, move that file to /etc/systemd/system/systemd-hostnamed.service.d/ instead

OpenPGP_signature
Description: OpenPGP digital signature