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 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/{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 Peter Portante via rsyslog <
rsyslog@lists.adiscon.com> wrote:
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
<rsyslog@lists.adiscon.com> wrote:
>
> 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, 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 <jchiv...@chivian.com>
wrote:
> >
> >> 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 the reboot) and sending the events
within
> >> to a network destination. This service would have the network.target
> >> dependency so as to be able to deliver reliably.
> >>
> >> Regards,
> >>
> >>
> >> On Mar 13, 2024, at 07:49, Attila Lakatos via rsyslog <
> >> rsyslog@lists.adiscon.com> wrote:
> >>
> >> 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 started or stopped. Many years ago, we added
dependency for
> >> the network.target and network-online.target into the service file
[1]. If
> >> rsyslog started before establishing network access, it would be
unable to
> >> transmit messages to remote destinations during that period,
resulting in
> >> the generation of misleading information about the unavailability of
> >> certain remote targets (e.g. not able to resolve hostnames).
> >> However, this approach results in a significant tradeoff. While it
prevents
> >> misleading unavailability messages during network setup and shutdown,
it
> >> also causes rsyslog to *exit* *early* during shutdown, leading to
missed
> >> logs regarding the graceful termination of other programs. This
limitation
> >> extends to system reboots as well. Thus, while addressing one issue,
the
> >> current service configuration introduces another.
> >> By default, we retrieve shutdown events from the journal using the
> >> imjournal module. Journal log data is stored in memory so after
shutdown,
> >> logs are not preserved.
> >>
> >> Has someone faced this problem? Are there any known workarounds?
> >>
> >> [1]
> >>
> >>
https://github.com/deoren/rsyslog-examples/blob/master/etc/systemd/system/rsyslog.service.d/10-wait-on-network.conf
> >> _______________________________________________
> >> rsyslog mailing list
> >> https://lists.adiscon.net/mailman/listinfo/rsyslog
> >> http://www.rsyslog.com/professional-services/
> >> What's up with rsyslog? Follow https://twitter.com/rgerhards
> >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad
> >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> >> DON'T LIKE THAT.
> >>
> >>
> >>
> > _______________________________________________
> > rsyslog mailing list
> > https://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> > What's up with rsyslog? Follow https://twitter.com/rgerhards
> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if
you DON'T LIKE THAT.
> _______________________________________________
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
