SSL portal does not restart



  • The SSL captive portal doesn't appear to restart properly, neither by restarting it from the [Status -> Services] page nor by saving the portal configuration on the [Services -> Captive Portal] page.

    This syslog is generated when you try to restart the Captive Portal service:

    php[33518]: /status_services.php: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-CaptivePortal-SSL.conf' returned exit code '255', the output was '2011-07-21 16:43:23: (network.c.364) can't bind to port: 8001 Address already in use'

    In fact, the /var/run/light-CaptivePortal-ssl.pid file is empty.  The problem seems to be in /etc/inc/captiveportal.inc:

    This line:
    killbypid("{$g['varrun_path']}/lighty-CaptivePortal-SSL.pid");
    should read:
    killbypid("{$g['varrun_path']}/lighty-CaptivePortal-ssl.pid");

    (note that SSL was inadvertently capitalized)

    And /usr/local/www/status_services.php also needs to be changed as follows:

    if($_GET['mode'] == "restartservice" and !empty($_GET['service'])) {
    switch($_GET['service']) {
    case 'captiveportal':
    killbypid("{$g['varrun_path']}/lighty-CaptivePortal.pid");

    add this line to also kill the ssl portal:

    killbypid("{$g['varrun_path']}/lighty-CaptivePortal-ssl.pid");
    captiveportal_init_webgui();
    break;

    and again in this section:

    /* stop service */
    if($_GET['mode'] == "stopservice" && !empty($_GET['service'])) {
    switch($_GET['service']) {
    case 'captiveportal':
    killbypid("{$g['varrun_path']}/lighty-CaptivePortal.pid");

    add this line to also kill the ssl portal:

    killbypid("{$g['varrun_path']}/lighty-CaptivePortal-ssl.pid");
    break;

    thanks,
    Mike



  • Try latest snapshot  since i put some fixes.



  • partially resolved, but I don't think /usr/local/www/status_services.php was modified (see the second part of my post).
    thanks
    Mike



  • Try again a later snapshot since the .pid file has been capitalized consistently all-over.



  • Yep, the 7/24/2011 snapshot fixed this problem – thanks!
    Mike


Log in to reply