PFTPX failing to restart after filter reload : snapshot 03-15-2007
-
I've had several cases recently where errors in filters caused them to not reload correctly. I go fix the filter issues, then find that pftpx isn't running anymore.. It stopped to reload the filter, then was never restarted.
Aside from fixing that issue, it sounds like pftpx needs to be on some sort of "monitored process" list to make sure it stays running.
Anyway, here's the log snippets (gotta love oldest first)
Mar 25 21:52:07 php: : There were error(s) loading the rules: /tmp/rules.debug:159: port only applies to tcp/udp /tmp/rules.debug:159: skipping rule due to errors /tmp/rules.debug:159: rule expands to no valid combination /tmp/rules.debug:160: port only applies to tcp/udp /tmp/rules.debug:160: skipping rule due to errors /tmp/rules.debug:160: rule expands to no valid combination /tmp/rules.debug:161: port only applies to tcp/udp /tmp/rules.debug:161: skipping rule due to errors /tmp/rules.debug:161: rule expands to
Mar 25 21:52:07 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:159: port only applies to tcp/udp /tmp/rules.debug:159: skipping rule due to errors /tmp/rules.debug:159: rule expands to no valid combination /tmp/rules.debug:160: port only applies to tcp/udp /tmp/rules.debug:160: skipping rule due to errors /tmp/rules.debug:160: rule expands to no valid combination /tmp/rules.debug:161: port only applies to tcp/udp /tmp/rules.debug:161: skipping rule due to errors /tmp/rules.debug:161:
Mar 25 21:52:05 check_reload_status: reloading filter
Mar 25 21:50:55 php: : There were error(s) loading the rules: /tmp/rules.debug:159: port only applies to tcp/udp /tmp/rules.debug:159: skipping rule due to errors /tmp/rules.debug:159: rule expands to no valid combination /tmp/rules.debug:160: port only applies to tcp/udp /tmp/rules.debug:160: skipping rule due to errors /tmp/rules.debug:160: rule expands to no valid combination /tmp/rules.debug:161: port only applies to tcp/udp /tmp/rules.debug:161: skipping rule due to errors /tmp/rules.debug:161: rule expands to
Mar 25 21:50:55 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:159: port only applies to tcp/udp /tmp/rules.debug:159: skipping rule due to errors /tmp/rules.debug:159: rule expands to no valid combination /tmp/rules.debug:160: port only applies to tcp/udp /tmp/rules.debug:160: skipping rule due to errors /tmp/rules.debug:160: rule expands to no valid combination /tmp/rules.debug:161: port only applies to tcp/udp /tmp/rules.debug:161: skipping rule due to errors /tmp/rules.debug:161:
Mar 25 21:50:53 check_reload_status: reloading filter
Mar 25 21:50:43 pftpx[649]: pftpx exiting on signal 15
Mar 25 21:50:43 pftpx[649]: pftpx exiting on signal 15For what it's worth, the "errors" were caused by the wizard creating a rule that wasn't set explicitly for TCP or UDP, but it needed to be. (I think it was for bittorrent in this case). I went in and changed the rule to TCP, the created a second for UDP, and the filter errors went away.
-
PFTPX is checked on every filter run.
Open /tmp/rules.debug and show us what line 159, 160 and 161 look like.
-
Unforunately those 3 lines are not currently broken, but I can tell you what they were.
Bittorrent, up and download, which the wizard created without a protocol set, IE any.. yet there was port-ranges specified config, which is why it was complaining…
port only applies to tcp/udp /tmp/rules.debug
Now that I changed the rules to TCP, then added UDP rules, here's what those lines look like (obviously not broken now)
pass in on $wan proto udp from any to 192.168.10.0/24 port 6881:6999 keep state tagged unshaped tag qP2PUp
pass out on $lan proto udp from any to 192.168.10.0/24 port 6881:6999 keep state tagged qP2PUp tag qP2PDown
pass in on $wan proto tcp from any to 192.168.10.0/24 port 6881:6999 keep state tagged unshaped tag qP2PUp
pass out on $lan proto tcp from any to 192.168.10.0/24 port 6881:6999 keep state tagged qP2PUp tag qP2PDown -
The wizard was creating rules for tcp, not any.
Are you sure you did not modify the wizards defaults?
-
The wizard was creating rules for tcp, not any.
Are you sure you did not modify the wizards defaults?
I'm not sure I'd know how to modify the wizards defaults if I wanted to… :)
If this helps, it wasn't a "clean" install, but I've upgrade from "1.01" through several of the "snapshots".
If there's a way to restore the wizard to default, I'd like to, because right now after each time I upgrade, I re-run the wizard to be safe, then to repair the rules.
-
Rerunning the wizard should always get you the latest version. Maybe remove the trafficshaper ruleset first and rerun the wizard again next time.
-
Rerunning the wizard should always get you the latest version. Maybe remove the trafficshaper ruleset first and rerun the wizard again next time.
I'll try that tonight. Thanks for the feedback so far.