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 needs about your logging,
maybe it's time to think about redirecting your messages to a (virtual)
serial console and capturing them externally?
But that's a bit out of scope of this list I think.
MK
On 13.03.2024 14:47, John Chivian via rsyslog 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.
