On Sat, Feb 01, 2020 at 12:50:55PM +0100, Michael Biebl wrote: > On Sat, 10 Aug 2019 12:37:04 +0200 Marc Haber > <mh+debian-b...@zugschlus.de> wrote: > > Hi Michael, > > > > thanks for your answer. > > > > On Fri, Aug 09, 2019 at 04:16:06PM +0200, Michael Biebl wrote: > > > I have never seen this behaviour myself on the multitude of systems I > > > run (laptop, servers, VM, containers) so I don't really have any idea. > > > > How closely are you watching the ACLs on the journal files? > > > > Forgot to answer here: I simply checked all systems I have acces to. > This was a one-time check and includes a couple of PIs, a few VMs, > containers, a laptop and a server. For some of them, /tmp is on the > root, ext4 file system. Most of them have tmpfs for /tmp (like in your > case).
I usually have tmpfs for /tmp, and /run is a tmpfs as well. > I guess once the x-bit has been set, it sticks? Or did it vanish (and > reappear again) after some time, which would mean I'd need to > continuously monitor the file system? The system is booted, no x bit, then at some time, the x bit appears and sticks until the machine is rebooted again. > Btw, does this only affect system.journal or also the files that are > rotated away? E.g. on one of my PIs this look like this > > > root@raspberrypi:~# ls -l > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system* > > -rw-r-----+ 1 root systemd-journal 2834432 Jan 24 03:17 > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-0000000000000001-00059cbeac13de5a.journal > > -rw-r-----+ 1 root systemd-journal 2834432 Jan 27 06:17 > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-000000000000063b-00059cd95a64682e.journal > > -rw-r-----+ 1 root systemd-journal 2834432 Jan 30 07:22 > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-0000000000000e28-00059d1837ab38f0.journal > > -rw-r-----+ 1 root systemd-journal 2834432 Feb 1 05:39 > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system@ee9cfeba24044e90a191a267c13840a2-0000000000001675-00059d557cd266fa.journal > > -rw-r-----+ 1 root systemd-journal 2834432 Feb 1 12:43 > > /run/log/journal/d3670ff77a0bb988a953e7f053a3f4e7/system.journal Rotation is a very good point. I have one machine that got rebooted on February 2 around 15:00, and my check script reported the x bit on run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal to be reset after that. Then, at 22:20, the report came in that the x bit on run/log/journal/8f018d505adf4ecaad2720811a888b04/system.journal was set. 1 [1/2158]mh@oversway:~ $ ls -al /run/log/journal/8f018d505adf4ecaad2720811a888b04/ total 5,0M drwxr-s---+ 2 root systemd-journal 80 Feb 2 22:17 ./ drwxr-sr-x 3 root systemd-journal 60 Feb 2 15:17 ../ -rw-r-----+ 1 root systemd-journal 2,5M Feb 2 22:17 system\@caad1846ab564a1c8d59d656f050776e-0000000000000001-00059d98777909b1.journal -rw-r-----+ 1 root systemd-journal 2,5M Feb 3 08:41 system.journal [2/2159]mh@oversway:~ $ This is consistent with the behavior I have seen on a different box. I will take a closer look at those times now that we have some evidence. So I now suspect that the x bit gets set during the log rotation. What umask is the process doing the log rotation running with? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421