Detecting Timeout of piped data

sriordan has asked for the wisdom of the Perl Monks concerning the following question:

I have script I am trying to use to monitor the output of another script that is being piped to it by:

perl script2.pl | script1.pl

Script1.pl outputs Good CRC/Bad CRC at 1-5 hz or so. It uses Device:SerialPort to read telemetry and feed it to MySQL data but occasionally hangs and needs to reset the tied file handle to the serial port and the connection to the Db. This works fine though the control interface, but I really need to monitor it and restart it anytime telemetry stops for more than 15-20 seconds without relying on user input to reset it.

The monitoring script is along the lines of:

#!/usr/bin/perl

use strict;
my ($timeout, $lastGoodTime);

$timeout = 20; # Timeout in seconds

while(-f pid.txt) {
  my $inLine = <>;
  if ($inLine ne '') {
    print "$inLine\n";
    if ($inLine =~ /^Done/) {
      print "Exiting\n";
      $lastGoodTime = time;
      exit;
  } elsif (( $inLine eq '' ) && ( time > ( $lastGoodTime + $timeout ))
+) {
      &requestRestart();
  }

}
[download]

To my mind the above code snippet ought to work but there appears to be something I am missing and/or not understanding about how the <> works. Any help/advice would be greatly appreciated. -Sean

Comment on Detecting Timeout of piped data Download Code

Replies are listed 'Best First'.
Re: Detecting Timeout of piped data by sierpinski (Chaplain) on Jul 31, 2011 at 03:17 UTC
I don't really want to comment on your telemetry problem, because I've never piped one script to another like that (and don't want to give you any wrong info), but I can tell you that the <> basically is STDIN. Any time you are assigning it to a variable, you are reading from STDIN up until a carriage return. Obviously if you have it in a loop like while(my $data = <>) then it'll keep reading until some condition breaks the loop. Hope that helps, if even a bit!	[reply]
Re^2: Detecting Timeout of piped data by Anonymous Monk on Jul 31, 2011 at 04:56 UTC
Just to expand on your point, `$inLine eq ''` will never be true because `"\n" != ''`	[reply] [d/l] [select]
Re^3: Detecting Timeout of piped data by sriordan (Acolyte) on Jul 31, 2011 at 21:09 UTC
Shouldn't the chomp between the read and the check remove the \n thereby making $inLine eq ''? What I believe ( and certainly could be wrong ) is that the script is just sitting and waiting at $inLine = <>; without ever recieving anything, and so never gets to any of the code that follows except when there is input. I think what I am looking for is something like the <> but with a configurable timeout period.	[reply]
Re^4: Detecting Timeout of piped data by Anonymous Monk on Aug 01, 2011 at 05:55 UTC
Re^5: Detecting Timeout of piped data by Anonymous Monk on Aug 01, 2011 at 05:57 UTC
Re^4: Detecting Timeout of piped data by Anonymous Monk on Aug 01, 2011 at 06:04 UTC
Re: Detecting Timeout of piped data by zentara (Cardinal) on Jul 31, 2011 at 13:31 UTC
You might find a good use for alarm in Threads or no Threads I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re: Detecting Timeout of piped data by Marshall (Canon) on Aug 01, 2011 at 11:47 UTC
Yes, the problem is that the <> is a blocking read, which means the program is hung-up waiting for some data to arrive. The usual way to handle this is easier than the thread mentioned by Zentara. There is an alarm that can interrupt program's execution when it counts down to zero seconds. See below for typical code. alrm_handler() is a subroutine that gets called when the alarm expires. Note loop construction. I like to do it this way because I can see all 3 things that can cause the loop to stop all at once right there in the in the while() statement: (1) alarm, (2) no data (EOF), (3) or line text matches "DONE". The alarm() is separated by a comma (yes, there is a comma operator). The "truth or falseness" of the of a comma joined statement is simply the last statement. This comma joined statement has the advantage that (1) no extra alarm() statement is needed before the while() statement and (2) if for some reason there are "next's" or various ways the loop can restart, I won't fail to restart the alarm (could happen if the alarm restart has to be embedded within the loop). Oh, and first thing to do within the body of the loop is to deactivate the alarm! Well unless of course the total time that you are trying to measure includes the processing time of the loop, but usually this is not the case. `$SIG{ALRM}=\&alrm_handler; sub alrm_handler { do...something here... sounds like die and cause shell command to be re-executed... } my $inLine; while (alarm(20), $inLine = <> and $inLine !~ /^Done/) { alarm(0); # deactivate the alarm!! normal loop here... } print "Exiting\n"; exit;` [download]	[reply] [d/l]
Re^2: Detecting Timeout of piped data by sriordan (Acolyte) on Aug 01, 2011 at 20:34 UTC
That appears to be exactly what I was looking for. I will go give that a shot. Thank you very much.	[reply]
Re^2: Detecting Timeout of piped data by Anonymous Monk on Aug 02, 2011 at 02:36 UTC
Does alarm actually interupt a blocking read on your systems? If so, could you post the versions of os and perl where this is so.	[reply]
Re^3: Detecting Timeout of piped data by Marshall (Canon) on Aug 02, 2011 at 06:57 UTC
Sure. Tested using the below using Active State binary build 1204 (v5.12.3) built for x86_64-linux-thread-multi. This is a Fedora machine. For some reason, on my Windows XP, Active State v 5.10.1 build 1007 MSWin32-x86-multi-thread, the same code hangs. The alarm() appears to just disappear. Odd. There is often something special about windows. Don't know why this is happening or rather not happening at the moment, but Linux is fine. Update: I've seen this work on Windows before. Since both machines are running binary Active State builds, I'll retest when I get the Windows machine up to 5.12 along with the latest versions of the modules that I currently have installed. This upgrade is some months in the future... `#!/usr/bin/perl use warnings; use strict; $SIG{ALRM} = sub { die "timeout!!! alarm\n" }; alarm(5); #start the timer print "waiting for alarm..hit any key..."; <STDIN>; print "waiting for another input line"; <STDIN>; print "past the IO stuff, normal exit\n"; __END__ should see this if no key at all is hit waiting for alarm..hit any key...timeout!!! alarm` [download]	[reply] [d/l]