Hi Martin, My situation is this: Monit is monitoring an app log. We need to do maintenance on the app. Doing so causes events to be written to the app log that monit has been told to respond to. So we tell monit to unmonitor the app temporarily. However, when maintenance is finished, we want monit to skip over all the trigger events that happened during maintenance, and just resume log monitoring from current EOF. Only way we've found to do this is to stop monit altogether, then restart as in the case of a cold boot.
For the app in question, since it's the only one on that server using monit presently, this isn't a real problem. However, we use monit on other servers where multiple apps are monitored, so stopping monit completely in such a case is an undesirable strategy. Best regards, John Tomich, IS Web Infrastructure Direct: 480.337.5854 Page: 602.208.9893 From: [email protected] [mailto:[email protected]] On Behalf Of Martin Pala Sent: Thursday, January 29, 2015 11:09 AM To: This is the general mailing list for monit Subject: Re: monit file tailing behavior during reload Hello John, the read position resets only of the file's inode changed and the file shrunk at least by one byte. As the file content monitoring was designed primarily for logfiles, Monit saves the read position in the state file even across Monit reload/restart to not check the same content again. Exception is the /proc/ filesystem where the files content is always tested (position reset to 0). If you need to reset the state, you'll have to stop monit, remove the statefile and start monit again. The statefile is stored by default stored as ~/.monit.state in the home of the user which is running monit, the location can be set using "set statefile ..." statement. Please can you describe more details about the use case? Maybe we can modify the test to be more flexible in situations where position reset is needed or add some CLI option/command. The mentioned "unmonitor" command currently doesn't reset the position. Regarding the content match nesting - no, it's not supported. Regards, Martin On 22 Jan 2015, at 17:10, Tomich,John <[email protected]<mailto:[email protected]>> wrote: Martin, I meant to add a third question: Can the startup file following behavior be duplicated when resuming file monitoring after previously issuing an unmonitor command? Best regards, John Tomich, IS Web Infrastructure Direct: 480.337.5854 Page: 602.208.9893 If you are not the intended recipient of this message (including attachments), or if you have received this message in error, immediately notify us and delete it and any attachments. If you do not wish to receive any email messages from us, excluding administrative communications, please email this request to [email protected]<mailto:[email protected]> along with the email address you wish to unsubscribe. For important additional information related to this email, visit www.edwardjones.com/US_email_disclosure<http://www.edwardjones.com/US_email_disclosure>. Edward D. Jones & Co., L.P. d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward Jones. All rights reserved. From: Tomich,John Sent: Thursday, January 22, 2015 9:03 AM To: [email protected]<mailto:[email protected]> Subject: monit file tailing behavior during reload Hello Martin, Documentation states that upon monit startup, check file directive causes read to EOF before beginning any actual monitoring/alerting. This doesn't seem to be the case after issuing a reload command. Is there any way to make reload behavior same as startup behavior? Also, can 'if match' tests be nested? E.g., If match "string-1" then if match "string-2" then <action-1> else <action-2> Best regards, John Tomich, IS Web Infrastructure Direct: 480.337.5854 Page: 602.208.9893 -- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
-- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
