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 <alaka...@redhat.com> 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.
