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.102 Runaway HTTP proxy

After up2date 5.102 the HTTP proxy still uses up 99,9% CPU. Looking at the new library I noticed a big difference in size, and the ownerships of libweed.so.0.0.0 is now 644, 507, users instead of 755, root, root. Is this correct or is this a little mistake?


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

    please post more details about your config and hardward, a "ps axfuwwwwww"-dump and some more details when the problem with 99% CPU for the HTTP proxy occurs.

    The different file owner of the file is irrelevantly.
Reply
  • Hi jeh,

    please post more details about your config and hardward, a "ps axfuwwwwww"-dump and some more details when the problem with 99% CPU for the HTTP proxy occurs.

    The different file owner of the file is irrelevantly.
Children
  • Hi Markus,

    the hardware we're using is a timeNet  secuRACK E-10/1000 Dual with smp-kernel and 4GB memory.  Config is the bare minimum to have HTTP-access with Surf-Protection in our test-lab. The school I'm working is closed for a week (Carnaval) and since the machine is in a test-environment I can't access it earlier than februari 14. Thanks a lot for your quick response though and I'll get in touch on feb. 14
  • Hi Markus,

    here is the "ps"-dump you asked for. The problem doesn't seem to occur with every website. www.planet.nl is one where the hyperdyper-daemon always runs to 99.9%. Could it be content related?

    "ps axfuwwwwww"-dump attached
  • Hi again,

    in addition to the above:

    I'm pretty sure now, that it's content related. When I add planet.nl to the whitelist domains, everthing seems to work ok. As soon as I remove it, the problem occurs.
  • did you try using a standard (non-SMP) kernel? if not would you be willing to try it out?
  • Hello,

    yes I did try a standard kernel and everything worked fine then. I reinstalled the smp kernel and the problem was back. Our reseller has taken the machine back for further testing (it might be hardware-related). I believe that they (Contec ISC) are in direct contact with you and have given you access for testing purposes.

    I'm very anxious to hear what's wrong.