Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 12740 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

High Load / High Disk Activity i/o causing http proxy (thus web access) to fail

sneader

I am using UTM9 on a home network, using a low-end Dell desktop with 3GB RAM, Core2 Duo CPU. It has been working fine for many months, to protect our family's network.

Last night, I installed some overdue UTM9 updates and ever since, I've been having significant problems.

Update History: I had been on 9.407003 for several months. Last night, I applied the following updates:
9.409009
9.411003
9.412002
9.413004

After those updates, randomly (at least hourly) I have been getting the dreaded "[INFO-141] Http proxy not running - restarted" email.  At this point, we can't pull up web pages.

This morning, I was offered another update, to 9.500009, so I went ahead and applied that, hoping it might help, but it did not.  Throughout the day, today, at seemingly random times, we are not able to get to web pages, and I get the "[INFO-141] Http proxy not running - restarted" email.

Through some troubleshooting, I have found that the UTM9 is going into a high load situation, caused by excessive Disk i/o.  Using atop, sorted by disk usage, I found:

PID  TID  RDDSK  WRDSK  WCANCL  DSK  CMD
1002  -  174.4M     0K      0K 100%  httpproxy
3778  -      0K   432K      0K   0%  postgres
3782  -      0K   176K      0K   0%  postgres
3785  -      0K   112K      0K   0%  postgres
2327  -      0K    28K      0K   0%  jbd2/sda6-8
(snip)

As you can see, httpproxy is using 100% of disk... all "reads".  Why?  I have no idea.  But, at this point, it all goes to heck and we lost the ability to browse the web, until it stops, and things start to recover.

I did a "smartctl -H /dev/sda" to check smart status on my hard drive, and it is clean.  I am in the middle of doing a read-only bad block test (badblocks -sv /dev/sda) but doubt it is going to find anything.

I have turn off all logging, to see if that would help, but it did not (saw that idea in another thread).

Any other ideas out there?  What other information can I provide?

- Scott



This thread was automatically locked due to age.
  • 0

    Sophos posted a note in this forum that 9.4-113 has problems with that service crashing.   Rollback or wait for 9.114

  • 0 in reply to DouglasFoster

    Thanks for that info, Douglas.  I mentioned in the above post that I updated to 9.5 that same day, but the problem persists... maybe the fix wasn't in there.  

    I found that if I disable Web Filtering, the problem goes away.  Not a very ideal solution. :-(

    - Scott

  • 0 in reply to sneader

    Scott, sometimes the Up2Date process scrambles part of the configuration.  One thing you can try is restoring from the configuration backup made just prior to the application of the 9.409009 Up2Date.  Any luck with that?

    Cheers - Bob

  • 0 in reply to BAlfson

    Hi Bob.  Thanks for the assist.  I have my config backup from when I was on 9.407003 a couple days ago.  As a reminder, in one fell swoop, I applied 9.409009, 9.411003, 9.412002, 9.413004 and then a few hours later, 9.500009.

    I'd definitely take your help on this... with the config file in hand from when I was stable on 9.407003, what should I do next?  Do I need to download 9.407003 as an iso and format and start over, then apply the config file?  Or? 

    Thanks!!

    - Scott

  • 0 in reply to sneader

    Scott, it's possible that just restoring the 9.407 backup to your 9.500 UTM will solve the problem.  If not, then some ISO before 9.413 would be your best bet.  If it's older than 9.407, you will want to do a temporary install and Up2Date to 9.407 before restoring the config backup.

    Cheers - Bob