collect-subtrees creates a lock file per subtree-set, as it runs. This can be a problem if a system reboots whilst the collection is in progress and it does not clear the lock file at reboot (eg. any system that does not wipe /tmp/ upon a reboot.)
A check between last run of collect-subtrees and the actual
date (taking into account the polling interval set - and
check the local zone time to see if it has changed, ie. MET
to GMT or sth.) could be used to remove the lock if the
time difference is too high or to send an email to warn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ignoring the larger issue of improving the
locking/contention code.... Does anyone actually understand
how the lockfile creation actually works? If someone can
explain it to me then I'll write up something for the
documentation for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=485847
A check between last run of collect-subtrees and the actual
date (taking into account the polling interval set - and
check the local zone time to see if it has changed, ie. MET
to GMT or sth.) could be used to remove the lock if the
time difference is too high or to send an email to warn
Logged In: NO
Actually I found the lockfile mechanism to be very unreliable.
Modified as follows to use the Proc::PID::File module:
[cricket@beaver cricket]$ cvs diff -r 1.1 -r 1.3 collect-
subtrees
Index: collect-subtrees
==============================================
=====================
RCS file: /home/cvs/support/applications/cricket/cricket-
1.0.3/collect-subtrees,v
retrieving revision 1.1
retrieving revision 1.3
diff -r1.1 -r1.3
1c1
< #!/usr/local/bin/perl -w
---
> #!/usr/bin/perl -w
45a46
> use Proc::PID::File qw(pid_file_set pid_file_alive);
128c129,130
< if (-f $lockfile) {
---
> pid_file_set( dir => "/tmp", name => $lockfile );
> if (pid_file_alive()) {
132c134
< push @mHist, "use \&quot;rm $lockfile\&quot; to unlock
it.\n";
---
> push @mHist, "use \&quot;rm /tmp/${lockfile}.pid\&quot; to
unlock it.\n";
136c138
< print STDERR "use \&quot;rm $lockfile\&quot; to unlock
it.\n";
---
> print STDERR "use \&quot;rm /tmp/${lockfile}.pid\&quot; to
unlock it.\n";
141,142d142
< # lock it
< system("touch $lockfile");
159,160d158
< # unlock it
< unlink($lockfile) if (!isWin32());
[cricket@beaver cricket]$
Logged In: NO
alastairyoung@metatv.com
Actually I found the lockfile mechanism to be very unreliable.
Modified as follows to use the Proc::PID::File module:
[cricket@beaver cricket]$ cvs diff -r 1.1 -r 1.3 collect-
subtrees
Index: collect-subtrees
==============================================
=====================
RCS file: /home/cvs/support/applications/cricket/cricket-
1.0.3/collect-subtrees,v
retrieving revision 1.1
retrieving revision 1.3
diff -r1.1 -r1.3
1c1
< #!/usr/local/bin/perl -w
---
> #!/usr/bin/perl -w
45a46
> use Proc::PID::File qw(pid_file_set pid_file_alive);
128c129,130
< if (-f $lockfile) {
---
> pid_file_set( dir => "/tmp", name => $lockfile );
> if (pid_file_alive()) {
132c134
< push @mHist, "use \&quot;rm $lockfile\&quot; to unlock
it.\n";
---
> push @mHist, "use \&quot;rm /tmp/${lockfile}.pid\&quot; to
unlock it.\n";
136c138
< print STDERR "use \&quot;rm $lockfile\&quot; to unlock
it.\n";
---
> print STDERR "use \&quot;rm /tmp/${lockfile}.pid\&quot; to
unlock it.\n";
141,142d142
< # lock it
< system("touch $lockfile");
159,160d158
< # unlock it
< unlink($lockfile) if (!isWin32());
[cricket@beaver cricket]$
Logged In: YES
user_id=8470
Ignoring the larger issue of improving the
locking/contention code.... Does anyone actually understand
how the lockfile creation actually works? If someone can
explain it to me then I'll write up something for the
documentation for this.