On Mon, Mar 14, 2022 at 05:13:28PM +0100, Michael Biebl wrote:
> upstream has closed bug report I created at
>
> https://github.com/systemd/systemd/issues/22729
>
> They argue that everything is working as expected and if aide trips up over
> that masked out x-bit it should be aide that needs to
Am 14.03.22 um 12:32 schrieb Marc Haber:
On Mon, Mar 14, 2022 at 11:38:01AM +0100, Michael Biebl wrote:
Nowadays I have a persistent journal enabled basically everywhere, which
somewhat mitigates this issue as /var/log/journal/ will persist
across reboots and new files will always inherit the sa
On Mon, Mar 14, 2022 at 11:38:01AM +0100, Michael Biebl wrote:
> Nowadays I have a persistent journal enabled basically everywhere, which
> somewhat mitigates this issue as /var/log/journal/ will persist
> across reboots and new files will always inherit the same ACLs settings.
That might apply to
On Fri, 25 Feb 2022 19:31:21 +0100 Marc Haber
wrote:
Hi Michael,
thanks to some insights from Bastian Blank explaining ACLs, I have the
following hypothesis:
- System boots up
- journald starts
- journald creates directories in /run/log without caring much
- journald begins logging, creatin
Hi Michael,
thanks to some insights from Bastian Blank explaining ACLs, I have the
following hypothesis:
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
On Mon, Feb 03, 2020 at 09:44:19AM +0100, Michael Biebl wrote:
> Am 03.02.20 um 09:30 schrieb Marc Haber:
> > group::r-x #effective:r--
> > group:adm:r-x #effective:r--
>
> Just to be clear: you mean this x bit set for group/group:adm which is
> not in effect
Am 03.02.20 um 09:44 schrieb Michael Biebl:
> Am 03.02.20 um 09:30 schrieb Marc Haber:
>
>> group::r-x #effective:r--
>> group:adm:r-x #effective:r--
>
> Just to be clear: you mean this x bit set for group/group:adm which is
> not in effect (in effect is r--
Am 03.02.20 um 09:30 schrieb Marc Haber:
> group::r-x #effective:r--
> group:adm:r-x #effective:r--
Just to be clear: you mean this x bit set for group/group:adm which is
not in effect (in effect is r-- due to the mask)
So is there actually a problem?
Afaic
On Mon, Feb 03, 2020 at 09:04:36AM +0100, Michael Biebl wrote:
> You should be able to trigger an explicit rotation by sending the
> journald process SIGUSR2
> $ systemctl kill --signal=USR2 systemd-journald.service
>
> This should make it easier for you to check your theory.
Funny, my testsystem
Am 03.02.20 um 08:50 schrieb Marc Haber:
> 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?
The rotation is done by journald itself [1] iirc
As for the umask:
$ systemctl show systemd-journald.service -p UMask
UMask
On Sat, Feb 01, 2020 at 12:50:55PM +0100, Michael Biebl wrote:
> On Sat, 10 Aug 2019 12:37:04 +0200 Marc Haber
> 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 mult
On Sat, 10 Aug 2019 12:37:04 +0200 Marc Haber
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
On Sun, Jan 26, 2020 at 01:49:18AM +0100, Michael Biebl wrote:
> On Mon, 9 Sep 2019 09:10:39 +0200 Marc Haber
> wrote:
> > On Sat, Aug 10, 2019 at 12:37:04PM +0200, Marc Haber wrote:
> > > Of course not, but no components that I have installed willingly. I'll
> > > roll out
> > > a monitoring job
On Mon, 9 Sep 2019 09:10:39 +0200 Marc Haber
wrote:
> On Sat, Aug 10, 2019 at 12:37:04PM +0200, Marc Haber wrote:
> > Of course not, but no components that I have installed willingly. I'll roll
> > out
> > a monitoring job that runs more often than once daily so that the change
> > gets
> > time
On Sat, Aug 10, 2019 at 12:37:04PM +0200, Marc Haber wrote:
> Of course not, but no components that I have installed willingly. I'll roll
> out
> a monitoring job that runs more often than once daily so that the change gets
> timed more exactly. Unless I report back, don't bother with more researc
On Sat, Aug 10, 2019 at 01:05:50PM +0200, Michael Biebl wrote:
> grep "/run/log" /etc/tmpfiles.d/* /usr/lib/tmpfiles.d/*
[3/1641]mh@oversway:~ $ sudo grep "/run/log" /etc/tmpfiles.d/*
/usr/lib/tmpfiles.d/*
grep: /etc/tmpfiles.d/*: No such file or directory
/usr/lib/tmpfiles.d/systemd.conf:d /run/
Am 10.08.19 um 12:37 schrieb Marc Haber:
> 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.
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
Am 09.08.19 um 16:16 schrieb Michael Biebl:
> Control: tags -1 + moreinfo unreproducible
>
> Am 09.08.19 um 08:15 schrieb Marc Haber:
>>
>> I have not fully understood what happens here. I am monitoring my
>> filesystems with aide, and sometimes get the following report:
>>
>>
Control: tags -1 + moreinfo unreproducible
Am 09.08.19 um 08:15 schrieb Marc Haber:
>
> I have not fully understood what happens here. I am monitoring my
> filesystems with aide, and sometimes get the following report:
>
> ---
> Changed entries:
>
20 matches
Mail list logo
