Hi,

I noticed since upgrade to systemd 249.5-1 on 2021-10-15 following
remount warnings in my log files, usually when some service is started.

While there are no problems caused by this behavior so far (besides spamming into log a lot),
I assume it is unintended and may indicate some underlying problem.


log snippets:

Okt 17 23:54:14 tetranode systemd[1]: Starting Network Name Resolution...
Okt 17 23:54:14 tetranode systemd[1]: Starting Network Time Synchronization...
Okt 17 23:54:14 tetranode systemd[1]: Starting Record System Boot/Shutdown in UTMP...
Okt 17 23:54:14 tetranode systemd[1]: Finished Record System Boot/Shutdown in UTMP.
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/systemd/timesync supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)                              Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/systemd/timesync supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:54:14 tetranode systemd[1]: Started Network Time Synchronization.
Okt 17 23:54:14 tetranode systemd[1]: Reached target System Initialization.


Okt 17 23:57:49 tetranode dbus-daemon[575]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' requested by ':1.27' (uid=1000 pid=2052 comm="/usr/lib/chromium/chromium --show-component-extens")
Okt 17 23:57:50 tetranode systemd[1]: Starting Daemon for power management...
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:50 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 17 23:57:51 tetranode dbus-daemon[575]: [system] Successfully activated service 'org.freedesktop.UPower'
Okt 17 23:57:51 tetranode systemd[1]: Started Daemon for power management.


Okt 18 01:01:44 tetranode dbus-daemon[1282]: [session uid=1000 pid=1280] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor'
Okt 18 01:01:44 tetranode dbus-daemon[575]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.38' (uid=1000 pid=2421 comm="/usr/bin/transmission-gtk")
Okt 18 01:01:44 tetranode systemd[1]: Starting Hostname Service...
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/etc supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/etc supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 01:01:45 tetranode dbus-daemon[575]: [system] Successfully activated service 'org.freedesktop.hostname1'
Okt 18 01:01:45 tetranode systemd[1]: Started Hostname Service.
Okt 18 01:01:49 tetranode dbus-daemon[1282]: [session uid=1000 pid=1280] Activating service name='ca.desrt.dconf' requested by ':1.16' (uid=1000 pid=2421 comm="/usr/bin/transmission-gtk")
Okt 18 01:01:49 tetranode dbus-daemon[1282]: [session uid=1000 pid=1280] Successfully activated service 'ca.desrt.dconf'
Okt 18 01:02:15 tetranode systemd[1]: systemd-hostnamed.service: Deactivated successfully.


Okt 18 06:18:48 tetranode dbus-daemon[575]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.60' (uid=1000 pid=2052 comm="/usr/lib/chromium/chromium --show-component-extens")
Okt 18 06:18:48 tetranode systemd[1]: Starting Hostname Service...
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/etc supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/etc supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode kernel: xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)
Okt 18 06:18:48 tetranode dbus-daemon[575]: [system] Successfully activated service 'org.freedesktop.hostname1'
Okt 18 06:18:48 tetranode systemd[1]: Started Hostname Service.
Okt 18 06:19:18 tetranode systemd[1]: systemd-hostnamed.service: Deactivated successfully.


fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>               <dump>  <pass>
proc        /proc           proc         defaults                   0       0
/dev/sda3   /               xfs          defaults,noatime           0       1
/dev/sda1   /boot           ext2         defaults,noatime           0       2
/dev/sda2   none            swap         sw                         0       0
/dev/sda4   /mnt/hive       xfs          defaults,noatime           0       2

/dev/sr0    /mnt/bdrom      udf,iso9660  user,noauto                0       0

/dev/sdb1   /mnt/data_one    xfs      defaults,noatime          0       2
/dev/sdb2   /mnt/data_two    xfs      defaults,noatime          0       2
/dev/sdb3   /mnt/data_three  xfs      defaults,noatime          0       2

/dev/sdc1   /mnt/windoze_old  ntfs-3g      noauto,noatime,umask=022   0       0

/dev/sdd1   /mnt/sdd1       auto         user,noauto,noatime        0       0
/dev/sde1   /mnt/sde1       auto         user,noauto,noatime        0       0


df:

udev              6097888         0   6097888    0% /dev
tmpfs             1220904       924   1219980    1% /run
/dev/sda3       125775704  77557348  48218356   62% /
tmpfs             6104504     72140   6032364    2% /dev/shm
tmpfs                5120         4      5116    1% /run/lock
/dev/sda1           67714     51269     12832   80% /boot
/dev/sda4       846596444 638277284 208319160   76% /mnt/hive
/dev/sdb2      1073217536 743653164 329564372   70% /mnt/data_two
/dev/sdb1      1073216516 440114116 633102400   42% /mnt/data_one
/dev/sdb3       782399676 736590520  45809156   95% /mnt/data_three
tmpfs             1220900        28   1220872    1% /run/user/1000

Am 20.10.21 um 08:51 schrieb 10dmar10:

See https://github.com/systemd/systemd/issues/21010
or more specifically
https://github.com/systemd/systemd/issues/21010#issuecomment-946453835

In short, that such bind mounts happen is expected. That XFS logs so
excessively about it, probably not.
So one could argue that this is a kernel issue.

Regards,
Michael

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?

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

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

Anyway, feel free to close this bug.

Am 20.10.21 um 12:08 schrieb 10dmar10:

 From which version did you upgrade?
Did you upgrade the kernel as well or other parts of the system?

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

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.

m 20.10.21 um 12:27 schrieb Michael Biebl:
systemd 247.9-4, i'm always on testing and safe-upgrade almost daily.
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)

Seems to be a known issue:

https://lore.kernel.org/lkml/alpine.DEB.2.21.99999.375.1912261445200.21037@trent.utfs.org/

Ok, I will wait for kernel update.

Am 20.10.21 um 13:51 schrieb 10dmar10:

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

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

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.

Am 20.10.21 um 14:30 schrieb Michael Biebl:

Fun, this feature was initially merged in

https://github.com/systemd/systemd/pull/18348

then reverted as it caused issues with selinux

https://github.com/systemd/systemd/pull/19902

then reapplied with an selinux exception before the v249 release

https://github.com/systemd/systemd/pull/20023


The end result is probably, that users on Fedora/Redhat will not see
this issue, as they typically have selinux enabled.

reassign 996876 src:linux
retitle 996876 filesystem being remounted supports timestamps until 2038
thanks

It was concluded that this is a kernel bug.
See also
https://lore.kernel.org/lkml/CAHk-=wim6VGnxQmjfK_tDg6fbHYKL4EFkmnTjVr9QnRqjDBAeA@mail.gmail.com/

and should be addressed in the kernel by only issuing this warning once
per mount, but not on a remount.

Thus reassigning.

Regards,
Michael