Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections
On Sat 15 Jul 2023, at 17:52, David Mehler <dave.mehler@gmail.com> wrote:
[...]
> Regarding the original issue of the systemd upgrade and the invalid
> attributes [...] here is the output that I've got:
>
[...]
> Cannot set file attributes for '/var/log/journal', maybe due to
> incompatibility in specified attributes, previous=0x00080000,
> current=0x00080000, expected=0x00880000, ignoring.
> Cannot set file attributes for
> '/var/log/journal/390b00d843d3401094a8fd44f1b7de82', maybe due to
> incompatibility in specified attributes, previous=0x00080000,
> current=0x00080000, expected=0x00880000, ignoring.
> Obsolete conffile /etc/systemd/resolved.conf has been modified by you.
> Saving as /etc/systemd/resolved.conf.dpkg-bak ...
User "seth" at
https://bbs.archlinux.org/viewtopic.php?id=272893
suggests "The error itself is harmless; systemd tries to set an attribute on a filesystem that doesn't support it" which seems to go along with it being ignored.
and later:
"0x00800000 is FS_NOCOW_FL - what is not a thing on directories.
Edit except for apparently btrfs - what also seems the only supported FS here. Otherwise you get an error [...]"
User j1simon suggests in
https://bbs.archlinux.org/viewtopic.php?pid=2013787#p2013787
that the errors are present at boot.
(I presume journalctl -b is how that output was obtained)
I use ZFS and can't find any similar errors in boot log
$ sudo journalctl -b|grep incompat
$
so I wonder if ZFS supports it on directories too.
man ioctl_iflags:
"FS_NOCOW_FL 'C' (since Linux 2.6.39)
The *file* will not be subject to copy-on-write updates.
This flag has an effect only on filesystems that support
copy-on-write semantics, such as Btrfs. See chattr(1) and
btrfs(5)."
https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html
The reporter in the first link above is asked if the bug has been reported to systemd developers. In another bug report re the same error (if in a slightly different context) on F2FS, systemd developer Lennart Poettering says "[...] this is a bug in the filesystem - They should not just eat up requests to set flags, but return an error. Please ping the f2fs maintainers."
https://github.com/systemd/systemd/issues/26318
It looks like the same bug/issue on ext4 to me, and I imagine safe to ignore.
Best wishes,
Gareth
Reply to: