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.21037@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.
> 

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 want to do the latter, you can create a file
/etc/systemd/system/service.d/disable-NNP.conf containing
[Service]
NoNewPrivileges=
NoNewPrivileges=no

If you only want to disable this warning for systemd-hostnamed.service, 
move that file to /etc/systemd/system/systemd-hostnamed.service.d/ instead

Be aware, that this weakens the sandbox a little.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20211020/bff85b70/attachment.sig>