It is very unusual for Perl to "die" without issuing some kind of notification.

Looking back at your original post, I notice that you have use strict twice but no use warnings or -w. If that is still the case, enable warnings. -w or even -W on the shebang line might be a good idea. It just might cause something to get logged.

If that doesn't help, my next suggestion is to use Devel::Trace. ie. prefix the run command with

perl -d:Trace yourscript ... >> lease.log 2>&1 &
[download]

Your code will run much more slowly, and your log file will become huge. But, assuming it fails, the log will tell you what was happening when it dies.

This is my modified Trace.pm that adds thread numbers to the trace output and performs locking on STDERR. The latter requires you created a shared semaphore variable in main: our $semSTDERR :shared:

# -*- perl -*-

package Devel::Trace;
use threads;
use threads::shared;
use Data::Dump qw[ pp ];
$VERSION = '0.10';
$TRACE = 1;
$VARS = 0;



# This is the important part.  The rest is just fluff.
sub DB::DB {
  local $\;
  return unless $TRACE;
  my ($p, $f, $l) = caller;
  my $code = \@{"::_<$f"};
  lock( $::semSTDERR ) if defined $::semSTDERR;
  printf STDERR ">> [%d] %-30s:%5d: %s",
    ( threads->self->tid || 'n/a' ), ( $f || 'n/a' ), ( $l || -1 ), ( 
+$code->[$l] || "???\n" );
  return unless $VARS;
  $code->[$l] =~ s/ ( [\$@%] [#]? \w* ) (?: ( (?:->)? (?: [\[{] [^\]}]
++ [\]}] )+ ) )? /
    no warnings 'uninitialized';
    my $var = (defined $2 ? "$1$2" : $1 );
    eval qq[ printf "\$var := %s\n", do{ package $p; $var }; ];
    $1 . ( $2 || '' )
  /gex;
}


sub import {
  my $package = shift;
  foreach (@_) {
    if ($_ eq 'trace') {
      my $caller = caller;
      *{$caller . '::trace'} = \&{$package . '::trace'};
    } else {
      use Carp;
      croak "Package $package does not export `$_'; aborting";
    }
  }
}

my %tracearg = ('on' => 1, 'off' => 0);
sub trace {
  my $arg = shift;
  $arg = $tracearg{$arg} while exists $tracearg{$arg};
  $TRACE = $arg;
}

1;
[download]

The chances are that if this isn't environmental--process limits or the like--then it is probably a bug long since fixed. I can only emphasis again how much better it would be if you would upgrade your Perl. Not doing so leaves you vulnerable to 6 years of bugs already fixed with no where to go.

Hi. Was out of action for a few days owing to sickness. Thanks for the tips. I smacked by forehead for not setting up warnings. ( I thought I had ) I do not know what happened after that. I was so fed up of the daemon dying that I just decided to look into the most tricky part. Consider this code which is part of one of the spawned threads

    iprint " MAC: $mac : Contacting  API......\n" if $debug > 1;
    # Wrap call to API with eval
    eval {
          local $SIG{ALRM} = sub { iprint "Network Delay) 
          alarm ( $maxNetworkDelay) ; 
          $ua = LWP::UserAgent->new( timeout => $maxNetworkDelay);
          $response = $ua->request( HTTP::Request->new(GET => $AuthURL
+forMAC.$mac));
          $respcon = $response->content;
          alarm(0);
    };
    iprint " MAC: $mac $@" if $@;
[download]

( I know you had mentioned earlier that LWP::Simple would do the job but then I needed to look specifically into the RC codes in the response which LWP::Simple does not support.) 2 threads use the above code for 2 different URLS and the response is looked into for further course of action

I initially thought that the ALRM signal would be trapped in the eval block and the local signal handler would do the job. Apparently, the $maxNetworkDelay was being triggered when network delays occurs and that actually sends a signal to all threads. This was causing the death of the daemon.

By simply adding a $SIG{ALRM} = sub { return;) at the very top of the daemon before any thread definition I was able to recover. So when the ALRM is triggered all threads receieve them and return back to the state they were in earlier. MOdified code below with $SIG{ALRM} handler defined as common for all threads and local handler removed.

    iprint " MAC: $mac : Contacting  API......\n" if $debug > 1;
    # Wrap call to API with eval
    eval {

          $ua = LWP::UserAgent->new( timeout => $maxNetworkDelay);
          $response = $ua->request( HTTP::Request->new(GET => $AuthURL
+forMAC.$mac));
          $respcon = $response->content;

    };
    iprint " MAC: $mac $@" if $@;
[download]

For the first time the daemon has run for 2 days without a problem. Did I know why I wrote the handler at the top? Partly yes, because I knew all threads were getting the signals in 5.8.4.

Do I know what is happening precisely? Definately not. Would appreciate your views on this

Apparently, the $maxNetworkDelay was being triggered when network delays occurs and that actually sends a signal to all threads. This was causing the death of the daemon.

This makes no sense to me at all. I've (briefly) scoured the LWP::UserAgent code, and can see nowhere that it raises a signal. Not as a result of a timeout, nor anything else.

Did I know why I wrote the handler at the top? Partly yes, because I knew all threads were getting the signals in 5.8.4.

Do I know what is happening precisely? Definately not. Would appreciate your views on this

I've recently learned that this (frankly weird) behaviour of signals and threads is different on (at least one variant of) *nix, than it is on Windows. Even with recent versions of both Perl & threads.

As such, whilst I hope my contributions so far have helped you to reaching a solution, I do not feel qualified to comment further on this. Sorry.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy