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

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

>> * 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/

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