Actions
Bug #2675
closed/tmp/.rc.prunecaptiveportal.running can be present on boot
Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
-
Start date:
11/08/2012
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0.x
Affected Architecture:
Description
This morning after a crash, a /tmp/.rc.prunecaptiveportal.running is present has not been deleted (I think the crash occured during execution of /etc/rc.prunecaptiveportail).
So, rc.prunecaptiveportal is not executed anymore, captive portail clients are never disconnected.
I propose this patch (for 2.0.x) :
diff --git a/etc/inc/captiveportal.inc b/etc/inc/captiveportal.inc index b48b64c..ebcfd1b 100644 --- a/etc/inc/captiveportal.inc +++ b/etc/inc/captiveportal.inc @@ -348,6 +348,8 @@ EOD; /* Kill any existing prunecaptiveportal processes */ if(file_exists("{$g['varrun_path']}/cp_prunedb.pid")) killbypid("{$g['varrun_path']}/cp_prunedb.pid"); + /* delete lock file */ + @unlink("{$g['tmp_path']}/.rc.prunecaptiveportal.running"); /* start pruning process (interval defaults to 60 seconds) */ mwexec("/usr/local/bin/minicron $croninterval {$g['varrun_path']}/cp_prunedb.pid " .
Updated by Ermal Luçi almost 12 years ago
- Status changed from New to Feedback
Patch has been pushed that corrects this by ignoring alock if it has been created for more than 2 minutes(2 runs of prunning process).
Actions