I believe restarting is the only way possible to achieve this. Certificates are connection based and therefore you must force the client to re-establish the connection to pickup the new certificate.
The client messages are therefore expected and should not be considered an error. Regards, > On Dec 30, 2023, at 07:42, Andy Smith via rsyslog <rsyslog@lists.adiscon.com> > wrote: > > Hi, > > I'm using rsyslog as packaged by Debian 12 (bookworm). I'm logging > to central servers: > > $DefaultNetstreamDriver gtls > […] > *.* @@server.example.com:10514 > > I'm using client TLS certificates that expire after 3 months. I have > automation to put the updated certificate files in place, but if I > do not restart rsyslog then it does not pick up the new certificates > and eventually the client rsyslog is rejected and cannot re-connect. > > I can easily restart rsyslog when new certificate files are put in > place, but then I get logs like this from every client host (many): > > 2023-12-30T02:32:01.521137+00:00 client1.example.com rsyslogd: omfwd: remote > server at server.example.com:10514 seems to have closed connection. This > often happens when the remote peer (or an interim system like a load balancer > or firewall) shuts down or aborts a connection. Rsyslog will re-open the > connection if configured to do so (we saw a generic IO Error, which usually > goes along with that behaviour). [v8.2302.0 try > https://www.rsyslog.com/e/2027 ] > 2023-12-30T02:32:01.531001+00:00 client1.example.com rsyslogd: action > 'action-19-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There > should be messages before this one giving the reason for suspension. > [v8.2302.0 try https://www.rsyslog.com/e/2007 ] > 2023-12-30T02:32:02.327418+00:00 client1.example.com rsyslogd: action > 'action-19-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2302.0 try > https://www.rsyslog.com/e/2359 ] > > So my simple question is, if I instead send a HUP signal to rsyslog, > will it rel;oad its updated TLS certificate files? > > Or, is there another graceful way to do that? > > The above log lines seem harmless but they trip my monitoring and I > would rather not programmatically ignore them as I may end up > ignoring a real problem later on. > > Thanks, > Andy > _______________________________________________ > 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.
