After update I see some strange log entries: Dec 16 14:50:26 localhost systemd-tmpfiles[786]: Cannot set file attributes for '/var/log/journal/fca06f2761aa4c18a37fb3ccf3935876', maybe due to incompatibility in sp> Dec 16 14:50:26 localhost systemd-tmpfiles[786]: Cannot set file attributes for '/var/log/journal', maybe due to incompatibility in specified attributes, previous=0x00> They were visible during update and are present after reboot in system log.
Marc, it looks as if the lines you posted were truncated (ending in middle of word with >). What follows might matter. Can you post them complete? FWIW I see nothing similar in my own journal.
CC: (none) => lewyssmith
Ok on my system. # stat /var/log/journal|head -n 4 File: /var/log/journal Size: 4096 Blocks: 16 IO Block: 4096 directory Device: 8,1 Inode: 837517 Links: 3 Access: (2755/drwxr-sr-x) Uid: ( 0/ root) Gid: ( 190/systemd-journal) What does the stat command show on that system?
CC: (none) => davidwhodgins
sorry, default of journalctl not to break the lines: Dec 17 09:20:00 localhost systemd-tmpfiles[762]: Cannot set file attributes for '/var/log/journal', maybe due to incompatibility in specified attributes, previous=0x00000000, current=0x00000000, expected=0x00800000, ignoring. Dec 17 09:20:00 localhost systemd-tmpfiles[762]: Cannot set file attributes for '/var/log/journal/fca06f2761aa4c18a37fb3ccf3935876', maybe due to incompatibility in specified attributes, previous=0x00000000, current=0x00000000, expected=0x00800000, ignoring. stat /var/log/journal/fca06f2761aa4c18a37fb3ccf3935876 File: /var/log/journal/fca06f2761aa4c18a37fb3ccf3935876 Size: 8192 Blocks: 32 IO Block: 4096 directory Device: 252,0 Inode: 159760 Links: 2 Access: (2755/drwxr-sr-x) Uid: ( 0/ root) Gid: ( 498/systemd-journal) Access: 2016-11-03 16:01:09.190484960 +0100 Modify: 2022-12-17 09:20:14.992997204 +0100 Change: 2022-12-17 09:20:14.992997204 +0100 Birth: -
What type of filesystem is /var/log on?
that is jfs.
@Marc : thanks for the full journal likes. Can we take it that nothing nasty happens because of these messages? @Dave : thanks for your comments. Nothing I can add for the moment.
Definitely weird. I did an install with / on sda1 as ext4, /var on /sdb1 as jfs. # journalctl -b --no-h|grep attributes Dec 17 19:26:56 systemd-tmpfiles[679]: Cannot set file attributes for '/var/log/journal', maybe due to incompatibility in specified attributes, previous=0x00000000, current=0x00000000, expected=0x00800000, ignoring. Dec 17 19:26:56 systemd-tmpfiles[679]: Cannot set file attributes for '/var/log/journal/b369664bd1db4227b02fd6356b139cef', maybe due to incompatibility in specified attributes, previous=0x00000000, current=0x00000000, expected=0x00800000, ignoring. What I find most weird about it is the the journal does not show the file system being mounted. # journalctl -b --no-h|grep -e b06afd4c-84ba-4777-91b8-e987728b0951 -e sdb1 Dec 17 19:26:55 kernel: sdb: sdb1 Dec 17 19:26:56 systemd-fsck[646]: The current device is: /dev/sdb1 The journal does show it being mounted during the installation ... # journalctl --no-h|grep -e b06afd4c-84ba-4777-91b8-e987728b0951 Dec 17 19:13:51 draklive-install[2079]: running: fsck.jfs UUID=b06afd4c-84ba-4777-91b8-e987728b0951 Dec 17 19:13:51 draklive-install[2079]: running: mount -t jfs UUID=b06afd4c-84ba-4777-91b8-e987728b0951 /mnt/install/var -o relatime Dec 17 19:14:02 draklive-install[2079]: running: fsck.jfs UUID=b06afd4c-84ba-4777-91b8-e987728b0951 Dec 17 19:14:02 draklive-install[2079]: running: mount -t jfs UUID=b06afd4c-84ba-4777-91b8-e987728b0951 /mnt/install/var -o relatime I'll redo it with sdb1 as ext4 to see if it's jfs or having /var on a separate file system triggering it.
The systemd-tmpfiles error does not occur if /var is ext4. Dec 17 20:05:38 systemd-fsck[654]: /dev/sdb1: clean, 676/1048576 files, 325036/4192709 blocks Dec 17 20:05:38 kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none. Looks like the success of mounting message comes from the ext4 kernel module, but the jfs kernel module does not generate one. Assigning to the kernel and drivers team. Perhaps they can figure out why jfs is causing the " Cannot set file attributes" message.
Assignee: bugsquad => kernel
Setting the priority to low since it seems to be a cosmetic issue with no impact on the files stored in the jfs file system.
Summary: systemd: strange log entries => Using jfs for /var causes systemd-tmpfiles to report "Cannot set file attributes"Priority: Normal => Low
Digging a bit more it looks like it's triggered by /usr/lib/tmpfiles.d/journal-nocow.conf According to the comments in that file the attribute only applies to btrs file systems. ext4 must be just ignoring the attempt to set it, while jfs generates the error message.
Thank you Dave for all your investigation. JFS !
CC: lewyssmith => (none)
Thanks Dave. Just looked weired, and since this message appears multiple times during install/updated, I wanted to state this not to overlook sth. severe.
You may want to stay away from jfs for other reasons. It's a risky system. Power loss is much more likely to lose data then systems such as ext4 or btrfs. It does have very good performance in some situations, but not all. https://en.wikipedia.org/wiki/JFS_%28file_system%29
I have very good experience with jfs and very bad with ext*. JFS just states to keep the filestructure in a valid state, but not the data itself. On the other hand, no faulty system can be mounted without a filesystem check. But the performance of a filesystem check is ~30 seconds on 2TB. I've already had a filesystem check on a faulty ext4 - it took hours and I was unable to work during the whole check. After any kernel panic, which still can happen sometimes, I make a full filesystem check, because the filesystem is likely not unmounted cleanly.