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,
Actually, I realized that dependency on the network.target is not the sole
problem why shutdown logs are not persisted.
Upon shutdown, there's a delay in rsyslog fetching new logs from the
journal via the journal API. By the time it can access
the journal, a SIGTERM signal has already been sent to
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.
you could put the remote sender things in a seprate ruleset with a queue on that
ruleset, that would let the rest of the config run without the network
(accumulating early logs and gathering shutdown logs up to the point that
rsyslog gets shut down)
you can configure rsyslog to save the queue
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
12 matches
Mail list logo
