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.
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=noIf 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.
OpenPGP_signature
Description: OpenPGP digital signature