Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 3 subscribers
  • Views 1212 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[5.200]mdw_daemon.pl at 100% CPU

drees
For some time now, we've been seeing the mdw_daemon.pl spike to 100% CPU utilization on one of our Astaro firewalls.  We haven't been able to figure out why.  We did find one clue in the mdw.log, this error message coincides with the spike to 100% CPU utilization:

Code:
2005:03:10-10:54:09 (none) middleware[611]: modules::networks::getNetwork() => Not enough arguments!
2005:03:10-10:54:09 (none) middleware[611]: modules::smtp at /PerlApp/modules/smtp.pm line 133.
2005:03:10-10:54:09 (none) middleware[611]:
2005:03:10-10:54:09 (none) middleware[611]: modules::Error::Error
2005:03:10-10:54:09 (none) middleware[611]: modules::networks::getNetwork
2005:03:10-10:54:09 (none) middleware[611]: modules::smtp::load
2005:03:10-10:54:09 (none) middleware[611]: modules::Config::load
2005:03:10-10:54:09 (none) middleware[611]:
2005:03:10-10:54:09 (none) middleware[611]: =========================================================================

However, this error message doesn't always seem to cause the problem, so it could be coincidental.

We also see this error in the log file as well:

Code:
2005:03:10-10:14:37 (none) middleware[611]: =========================================================================
2005:03:10-10:14:37 (none) middleware[611]: modules::Config::getConfig() => Unexpected reference type: /etc/wfe/conf/arm.conf ''
2005:03:10-10:14:37 (none) middleware[611]: modules::Ressource at /PerlApp/modules/Ressource.pm line 134.
2005:03:10-10:14:37 (none) middleware[611]:
2005:03:10-10:14:37 (none) middleware[611]: modules::Error::Error
2005:03:10-10:14:37 (none) middleware[611]: modules::Config::getConfig
2005:03:10-10:14:37 (none) middleware[611]: modules::Ressource::getConfig
2005:03:10-10:14:37 (none) middleware[611]: modules::arm::load
2005:03:10-10:14:37 (none) middleware[611]: modules::Config::load

Any ideas?


This thread was automatically locked due to age.
  • 0
    Hi, 

    I ve got the same here, i ve try to reboot  but there is no change.

    Idea ?
  • 0
    hardware specs?  I often see cpu spikes up to 100% during confd or mdw or sarge.  The system keeps chugging without issue though.
  • 0 in reply to William Warren
    The machine is a P-IV 2.4 GHz, with 1GB memory, so it's pretty decent hardware wise.  It's not moving a lot of traffic, it's connected to a 512Kbps internet line and to a LAN.

    Right now the system has been up for 17 days, and the mdw_daemon.pl has sucked up over 7700 minutes of CPU time, or 5 days worth.  Looking at the CPU utilization charts you can see that it's pegged about 1/3 of the time.

    The firewall works normally except for one thing: Any changes to the firewall rules do seem to take a long time to take effect.  This could be related to the amount of CPU that the mdw_daemon uses...

    The only thing I could think of is that our ruleset does include a couple of rules (2 or 3) where there is a network group for the inbound IP, a service group for the services and a network group for the destination IP.  Logging onto the console and running `iptables -n -L | wc` gives me almost 43,000 lines where my other firewall gives me about 700.

    The source network group has about 30 networks (single IPs) in it, the service group has about 20 services in it, and the destination network group has about 20 networks (also single IPs)  in it.  This multiples into a very large number of individual rules when looking at the iptables output.  If the mdw_daemon could have a loop in there which doesn't handle large numbers of rules efficiently (has some a O^N function) that would explain the large amount of CPU utilization by it.

    Anyone using a rule like this without having the mdw_daemon use a lot of CPU?
  • 0
    Good possible something with your interface definitions is broken and thus not working correctly.

    A little trick to solve the problem might be:

    Copy the content of /opt/tmpfs/running_itf.conf to /etc/wfe/conf/itf.conf.new

    Paste the section [global] of /etc/wfe/conf/itf.conf to this new itf.conf.new

    Change the rights of the new itf.conf.new according to the ones of the original itf.conf with:

    chmod 644 itf.conf.new
    chown wwwrun.nogroup itf.conf.new

    Make a backup of your itf.conf with:

    cp /etc/wfe/conf/itf.conf /etc/wfe/conf/itf.conf.bak

    Finally copy your new itf.conf.new to itf.conf like above so you can still go back if something went wrong using your .bak

    Thats it!
  • 0 in reply to DrMabuse
    I am running 5.2 on the gw 320 and have a simliar problem, support tracked it to the pop proxy. Are you running that? Turn it off and see if it corrects to problem. They are working on a fix for it now.
  • 0 in reply to ernman
    wow..the big cpu hog here is confd.  Just goes to show different HW setups can show different issues..[:)]
  • 0 in reply to William Warren
    Hi all,
    we had a similar thing here on some systems. All affected systems were P4 with HT. So we take one box turned off the HT in the bios and reinstalled the system with the standard kernel. and since this time it never happens again. After this we do the same on the other HT boxes and everything looks god till now.

    firebear
  • 0 in reply to DrMabuse
    Well, I managed to remove the offending rules which expand to 20k+ iptables rules each, so the firewall is down to a couple hundred firewall rules now.

    CPU utilization is down to normal now.  No more mdw_daemon.pl sitting at 100% CPU for extended periods of time.

    Stay away from rules with groups in the source / service / destination where if you multiple the number of items in each group gets big!