in reply to Timed event within a script

To answer your question as stated, I would look first at an event loop, which in my preference would be AnyEvent. You might particularly consider the section in the tutorial headed Timers and other event sources to implement your 30-minute schedule.

The second function is for the script to send an "I'm alive" email every 30 mins or so

That, however is the intriguing part. I cannot think why you would want this - it sounds much more likely that you'd want to be alerted every 30 minutes or so if it wasn't alive - ie. in normal operation it's quiet, but when it is not running you receive an "I'm dead" email.

Either way the trivial solution is not a Perl one but an O/S one: a cron job to run every 30 minutes which checks the process is running and sends your email if it is (or is not, as preferred).

Replies are listed 'Best First'.
Re^2: Timed event within a script
by bajangerry (Sexton) on Mar 08, 2017 at 13:22 UTC

    Thanks, I will have a look at AnyEvent and I agree with your comment about the alert email if the script isn't running but that is not what the user requested.

    I also wish it was a Linux machine so I can use cron but the script will be running in Windows and the request was for a "simple, single program" solution to use their words.<\p>

[reply]
      I also wish it was a Linux machine so I can use cron

      FYI, Windows does have a chron "equivalent". It is called Task Scheduler. It has both a Windows and a command line interface. Something like "run program X every 30 minutes" is possible. I've used Task Scheduler to periodically run a Perl script before without problems.

      Update with a few comments and considerations: I wouldn't necessarily interpret the user request for "one program" as a hard and fast design implementation limitation. It appears that the main point appears to be something reliable. Simple often, but not always yields reliable.

      For the "wait for emergency" function, you could have a simple loop that does blocking I/O on that port while waiting for the "Emergency" message. If you get messages fairly regularly that are not "emergencies", blocking I/O would fine fine.

      For the once per 30 minute "watchdog on the monitor for emergency" function. In applications that I've worked on, more than the "process is running" is often required. The thing to be verified is: "is the thing that is monitoring for an emergency" really doing actual work(processing messages looking for an emergency)? You could have the main monitoring function do something that is observable by the "watchdog" process. Perhaps simply incrementing the name of a zero length file for every message it looks at? If the watchdog function determines that no messages are being processed by the monitoring function, it would conclude that something is amiss in addition to making sure that the monitor process is actually "running", i.e. in the process table.

[reply]

        Thanks for your input. I have been trying to wrap my head around the best way to do this. The problem I have is that even though there has not been a message from the device for hours it doesn't mean there is actually a problem, it is more likely that there is NOT a problem in that case. It would be nice if there was a periodic "keep alive" type message from the device but I am not that lucky.

        Simply put, the device shoots out a message on a IP port whenever there is an error event and only then. It does not care if there is 1 or 100 devices monitoring the port either

[reply]

In Section Seekers of Perl Wisdom