John - think that’s the badger!! the logrotate.d file has been in use for about a decade AIUI but only now has it failed to work properly - which either suggests rsyslog wasn’t really that choosy before ubuntu20/latest rsyslog version but now is... or "we" got lucky somehow.
Anyway ive updated the rotate config on the client to postrotate stop rsyslog remove imfile blat the logs recreate the logs restart rsyslog and it seems to be doing what it is supposed to do now. Ill keep a beady eye on it over the next few days. Cheers! -----Original Message----- From: John Chivian <jchiv...@chivian.com> Sent: Monday, April 22, 2024 11:02 PM To: rsyslog-users <rsyslog@lists.adiscon.com> Cc: Ian Diddams <ian.didd...@celebrus.com> Subject: Re: [rsyslog] [EXTERNAL] Re: imfile rsyslog config sporadic since upgrade to ubuntu20 If a file is rotated without rsyslog’s knowledge the state file becomes out of date. The state file is just a high-water mark for the file and is not guaranteed to be updated in all cases. State files are created in the statefile.directory and are convieniently named imfile-state* where the rest of the file name is a unique identifier that is specific to the input file. If a log file is truncated, and the state file does not update, rsyslog won’t process new file content until the file reaches the previous high water size. You can see this in the state file itself as they are simply JSON objects containing offset values. Our solution (for these file based instances) was to stop rsyslog, then rotate/delete the log file, then delete the state file, then restart rsyslog. Regards, > On Apr 22, 2024, at 16:22, Ian Diddams via rsyslog > <rsyslog@lists.adiscon.com> wrote: > >> Having experienced something similar a few years ago (imfile not seeing new >> messages added to a certain log file), I'll throw this idea: in my case, it >> was because >the statefile associated with this log file got corrupted or >> something. Granted, I was messing around with the log file that imfile was >> watching. >> Deleting the statefile and restarting rsyslog unlocked the situation. If you >> do so, keep in mind that the whole log file will be processed as if it was a >> new file. > > For clarity, in my examples. Do you mean by statefile > >>> statefile.directory = "/var/log/node" > or >>> file = "/var/log/node/Tlog.log" > > Cheers > > ian > > On 2024-04-22 10:42, Ian Diddams via rsyslog wrote : >>>> specifically look for 127.0.0.1 or localhost >> see previous message . Nothing. >> >> >> OK, Ive just set this up >> >> >> local4.* /tmp/Tlocal.log >> >> I created that log and chmod 777 for it to remove any silly potential >> issues >> >> and restarted rsyslog on the central server >> >> No change. Client logs have new entries. Server /var/log/Tlocal.log >> doesn’t at all. >> >> So it's either the server not accepting what is sent on local4 - but >> "logger -p local4.info <string>" on the client DOES get centrally >> logged so that’s unlikely OR the client config isn’t capturing the >> additions to that local log for sending i.e. >> >> module( >> load = "imfile" >> pollingInterval = "1" >> statefile.directory = "/var/log/node" >> ) >> >> input( >> type = "imfile" >> tag = "tserv-stdout" >> facility = "local4" >> severity = "info" >> file = "/var/log/node/Tlog.log" >> ) >> >> cheers >> >> ian >> -----Original Message----- >> From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf Of David >> Lang via rsyslog >> Sent: Friday, April 19, 2024 12:44 PM >> To: David Lang via rsyslog <rsyslog@lists.adiscon.com> >> Cc: David Lang <da...@lang.hm> >> Subject: Re: [rsyslog] [EXTERNAL] Re: imfile rsyslog config sporadic >> since upgrade to ubuntu20 >> >> specifically look for 127.0.0.1 or localhost >> >> If you can log anything that's local4 on the server to a single file >> (ideally using the template RSYSLOG_DebugFormat so we can see all the >> variables that are parsed from it) it may be easier to find the log >> than your current dynafile approach that puts them in different >> directories based on the hostname. >> >> David Lang >> Confidentiality notice: This email (and any attachment) is intended >> for the >> addressee(s) named above. It may contain information of a >> confidential or legally privileged nature. Unauthorised disclosure or >> use of this email (or any attachment) is prohibited and may be >> unlawful. If you are not the intended recipient, please delete the >> email from your systems, destroy any copies and inform the sender >> immediately. Privacy >> notice: To find information on how we collect, process and store >> data, please see our privacy statement on our website >> https://www.celebrus.com/privacy-statement >> Disclaimer: All attachments have been scanned for viruses. However, >> Celebrus Technologies Plc cannot accept liability for any loss or >> damage you may incur as a result of virus infection. >> _______________________________________________ >> 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. > Confidentiality notice: This email (and any attachment) is intended for the > addressee(s) named above. It may contain information of a confidential or > legally privileged nature. Unauthorised disclosure or use of this email (or > any attachment) is prohibited and may be unlawful. If you are not the > intended recipient, please delete the email from your systems, destroy any > copies and inform the sender immediately. Privacy notice: To find information > on how we collect, process and store data, please see our privacy statement > on our website https://www.celebrus.com/privacy-statement Disclaimer: All > attachments have been scanned for viruses. However, Celebrus Technologies Plc > cannot accept liability for any loss or damage you may incur as a result of > virus infection. > _______________________________________________ > 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. Confidentiality notice: This email (and any attachment) is intended for the addressee(s) named above. It may contain information of a confidential or legally privileged nature. Unauthorised disclosure or use of this email (or any attachment) is prohibited and may be unlawful. If you are not the intended recipient, please delete the email from your systems, destroy any copies and inform the sender immediately. Privacy notice: To find information on how we collect, process and store data, please see our privacy statement on our website https://www.celebrus.com/privacy-statement Disclaimer: All attachments have been scanned for viruses. However, Celebrus Technologies Plc cannot accept liability for any loss or damage you may incur as a result of virus infection. _______________________________________________ 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.
