PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001117PacketFenceperformancepublic2010-11-16 10:482015-02-13 15:24
Reporterrbalzard 
Assigned Toobilodeau 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
Summary0001117: Violations are loaded way too often when monitoring PacketFence status (pfcmd service pf command)
DescriptionBy looking at PF logs, I noticed we call read_violations_conf() too often.

In pfcmd we see:


  print "service|command\n";
  if ($command !~ /^stop$/){
    print "config files|$command\n";
    require pf::os;
    pf::os::read_dhcp_fingerprints_conf();
    read_violations_conf();
    if (! ($Config{'network'}{'mode'} =~ /vlan/i)) {
      print "iptables|$command\n";
      require pf::iptables;
      pf::iptables::iptables_generate();
    }
  }

Does it mean that we reload violations for every command that is not 'stop' ?
if yes, we reload violations on status, watch, stop, restart.
I guess we should only load violations on start, no ?

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-11-16 10:48rbalzardNew Issue
2010-11-16 10:48rbalzardStatusnew => assigned
2010-11-16 10:48rbalzardAssigned To => obilodeau
2010-11-17 09:19rbalzardNote Added: 0001763
2011-01-18 11:41obilodeauTarget Version => 2.1.0
2011-03-03 15:15obilodeauTarget Version2.1.0 => +1
2011-03-03 15:18obilodeauTarget Version+1 => +2
2015-02-13 15:24lmunroNote Added: 0003667
2015-02-13 15:24lmunroStatusassigned => closed

Notes
(0001763)
rbalzard   
2010-11-17 09:19   
Here are the logs for one client for which we have the following cronjob:
45 * * * * /usr/local/pf/bin/pfcmd service pf watch > /dev/null 2>&1

Nov 16 16:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 17:45:04 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 18:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 19:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 20:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 21:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 22:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 16 23:45:04 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 00:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 01:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 02:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 03:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 04:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 05:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 06:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 07:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)
Nov 17 08:45:03 pfcmd(0) INFO: All triggers deleted (pf::trigger::trigger_delete_all)


So when executing 'service pf watch', PF reloads the violations.
(0003667)
lmunro   
2015-02-13 15:24   
These issues are too old to still be relevant.

Let's start anew.