Relayd issues after restoring configuration to new arch



  • I recently moved pfsense from an amd64 platform (2.0-BETA4) to an i386 platform (2.0-BETA5 (i386) built on Thu Feb 10 22:00:00 EST 2011).  I downloaded the full config file from the old box and restored it to the new box.  Everything seems to be working (had to fix RRD due to platform change, but no prob there) except that relayd is unhappy.

    I tried deleting the Virtual Server and Pools configuration, saved, then re-created the entries.  No luck.

    Virtual Server status shows:  Unknown - relayd not running?

    relayd.conf and the syslog after re-creating the Virtual Server:

    Feb 11 11:32:20 php: /load_balancer_monitor.php: The command '/usr/local/sbin/relayd -f /var/etc/relayd.conf' returned exit code '1', the output was '/var/etc/relayd.conf:5: reached end of file while parsing quoted string /var/etc/relayd.conf:5: syntax error no redirections, nothing to do'
    Feb 11 11:32:20 check_reload_status: reloading filter
    Feb 11 11:32:18 check_reload_status: syncing firewall
    Feb 11 11:32:10 relayd[50056]: terminating
    Feb 11 11:32:10 relayd[50056]: check_child: lost child: host check engine exited
    Feb 11 11:32:10 relayd[50056]: check_child: lost child: host check engine exited
    Feb 11 11:32:10 relayd[50056]: check_child: lost child: pf update engine exited
    Feb 11 11:32:10 relayd[50056]: check_child: lost child: pf update engine exited
    Feb 11 11:32:10 relayd[50329]: host check engine exiting
    Feb 11 11:32:10 relayd[50165]: fatal: cannot add rule: Operation not supported by device
    Feb 11 11:32:10 relayd[50165]: fatal: cannot add rule: Operation not supported by device
    Feb 11 11:32:10 relayd[50165]: table CSE_VIP: 1 added, 0 deleted, 0 changed, 0 killed
    Feb 11 11:32:00 relayd[50329]: host 10.10.0.2, check icmp (0ms), state unknown -> up, availability 100.00%
    Feb 11 11:32:00 relayd[50056]: startup

    log updates
    table <cse>{ 10.10.0.2 retry 10 }
    redirect "CSE_VIP" {
      listen on val.id.ip.adr port 80
      forward to <cse>port 80 check http ''  code 200 timeout 1000
    }

    Suggestions?

    Cheers.</cse></cse>


  • Rebel Alliance Developer Netgate

    Why do you have a \ in the http check? It's causing the ' to be escaped, so it never sees the string terminate, which makes it fail to parse the config.


  • Rebel Alliance Developer Netgate

    FYI that can be changed under Services > Load Balancer on the Monitors tab. Edit the HTTP check and look at the Path field.



  • Thanks for your response.  I was running an HTTP monitor, and wanted the calls to go to the server root.  The dialogue doesn't allow a blank path field, so I used \  .  From your comment, I realized that I used the incorrect slash (palm-smacks-head).  I'm amazed it worked at all on the original box.

    I changed to an ICMP monitor to sidestep the HTTP path issue.  Below is the updated relayd.conf.

    log updates
    table <cse>{ 10.10.0.2 retry 10 }
    redirect "CSE_VIP" {
     listen on <valid ip="">port 80
     forward to <cse>port 80 check icmp timeout 1000
    }

    It doesn't appear to address the issue.

    Feb 11 13:53:31 relayd[14071]: terminating
    Feb 11 13:53:31 relayd[14071]: check_child: lost child: host check engine exited
    Feb 11 13:53:31 relayd[14071]: check_child: lost child: pf update engine exited
    Feb 11 13:53:31 relayd[14620]: host check engine exiting
    Feb 11 13:53:31 relayd[14307]: fatal: cannot add rule: Operation not supported by device
    Feb 11 13:53:31 relayd[14307]: table CSE_VIP: 1 added, 0 deleted, 0 changed, 0 killed
    Feb 11 13:53:21 relayd[14620]: host 10.10.0.2, check icmp (0ms), state unknown -> up, availability 100.00%
    Feb 11 13:53:21 relayd[14071]: startup</cse></valid></cse>



  • Packages need rebuild so you have to wait for a new snapshot today.



  • Upgrading to 2.0-RC1 (i386) built on Mon Feb 14 02:12:45 EST 2011 seems to have addressed the issue.  Thanks!

    As an aside (mostly just to make me feel better), the issue of \ vs / in the monitor likely popped up when I deleted and re-created all of the load balancer entries after moving to the i386 platform.  There's no real debugging value in this information other than to say that my brain fade happened after the migration, and that the original config was probably valid (and that's why it worked).

    Cheers.


Log in to reply