24 12:58:52 -0700 (PDT)
From: David Lang via rsyslog
To: Attila Lakatos via rsyslog
Cc: David Lang
Subject: Re: [rsyslog] Capturing shutdown logs
The jousnal is storing them somewhere anyway (in ram if nothing else), that's
a
'feature' of journald.
you can set how much s
The jousnal is storing them somewhere anyway (in ram if nothing else), that's a
'feature' of journald.
you can set how much space you allocate to journald for it's fixed storage and
so can set it small enough to not be an issue.
David Lang
On Wed, 20 Mar 2024, Attila Lakatos via rsyslog wrot
Implied is not to store locally via rsyslog but use rsyslog to send off-host.
On Wed, Mar 20, 2024 at 4:16 AM Attila Lakatos wrote:
>
> Hello Peter,
>
> I think that would be the best solution from rsyslog point of view.
> However, this would mean that logs would be stored in both
> /var/log/{me
Hello Atilla!
You can limit the persistent journald storage in size with SystemMaxUse
option. Just find a value which is good enough for you to save all the
messages while rsyslog is down. I guess 1Gb should be more than enough.
On Wed, 20 Mar 2024 at 12:17, Attila Lakatos via rsyslog <
rsyslog@l
Hello Peter,
I think that would be the best solution from rsyslog point of view.
However, this would mean that logs would be stored in both
/var/log/{messages|secure|...} and the journal.
Ideally, it would be better to have them only in one place.
Thanks,
Attila
On Tue, Mar 19, 2024 at 4:03 PM P
Attila, any reason you can't just use persistent journald? That is
what we did to solve the lost shutdown and crash logs. -Peter
On Fri, Mar 15, 2024 at 12:31 PM David Lang via rsyslog
wrote:
>
> imjournal uses the journal api to fetch the logs (fetching them in
> near-real-time), journald keep
imjournal uses the journal api to fetch the logs (fetching them in
near-real-time), journald keeps files internally to support it.
David Lang
On Fri, 15 Mar 2024, Attila Lakatos via rsyslog wrote:
The solution is clean to me, however I think this could be a bottleneck for
busy systems. Also,
rsyslog wrote:
>
> > Date: Wed, 13 Mar 2024 13:49:19 +0100
> > From: Attila Lakatos via rsyslog
> > To: rsyslog-users
> > Cc: Attila Lakatos
> > Subject: [rsyslog] Capturing shutdown logs
> >
> > Recently I came across an observation where we are not
The solution is clean to me, however I think this could be a bottleneck for
busy systems.
Also, this would mean that I need to maintain a copy of journal logs in one
or more files.
On Wed, Mar 13, 2024 at 2:53 PM John Chivian wrote:
> You could split rsyslog into two separate service instances.
Cc: Attila Lakatos
Subject: [rsyslog] Capturing shutdown logs
Recently I came across an observation where we are not able to capture
normal reboot/shutdown logs on Fedora/RHEL distributions. In these
environments, systemd is responsible for starting the rsyslog service. A
service can have multiple
Anyway, you still have the part where the system as such (kernel,
systemd) is still running and rsyslog is not running anymore. You can't
help it. You can minimize the "hole" a bit, but can't force a process to
run when it had already been shut down.
If you really have such high availability n
You could split rsyslog into two separate service instances.
Service 1 would do only one thing, read imjournal and write to file(s). This
service would not have the network.target dependency.
Service 2 would do everything else, including reading the file(s) output from
above (which survive t
Recently I came across an observation where we are not able to capture
normal reboot/shutdown logs on Fedora/RHEL distributions. In these
environments, systemd is responsible for starting the rsyslog service. A
service can have multiple dependencies, which influence how early or how
late rsyslog is
13 matches
Mail list logo
