Project

General

Profile

Actions

Bug #2675

closed

/tmp/.rc.prunecaptiveportal.running can be present on boot

Added by Thomas NOEL about 12 years ago. Updated over 9 years ago.

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 " .
Actions #1

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 #2

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Resolved

fixed

Actions

Also available in: Atom PDF