httpproxy hangs

It's a known issue with the proxy, the tell-tale sign being the dns_expire messages.  The workaround is to restart the proxy.  We're just waiting for development to finish the fixes for 9.005 to be soft-released.

Thanks!  Glad to know it's not me.  We will just hang in there until the release.

What did you do to solve this finally?

We have the same here and I figured out the following:

HTTPPROXY stops logging during that period of beeing unavailable, too. The first entries when it comes alive after seconds oder minutes are as follows:

2013:09:27-11:38:02 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_update_list"
file="scr_scanner.c" line="717" message="reloading list (1)"
2013:09:27-11:38:03 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_log"
file="scr_scanner.c" line="1126" message="Unable to allocate 397532828
bytes for control list"
2013:09:27-11:38:03 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_update_list"
file="scr_scanner.c" line="719" message="list reload failed, fallback to
disk db"
2013:09:27-11:38:04 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_log"
file="scr_scanner.c" line="1126" message="Unable to allocate 397532828
bytes for control list"
2013:09:27-11:38:04 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_log"
file="scr_scanner.c" line="1126" message="Failed to load list
'/var/pattern/sfcontrol/sfcontrol' return code '10'"
2013:09:27-11:38:04 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_update_list"
file="scr_scanner.c" line="722" message="failed to load list(86), will
fallback to remote lookup"
2013:09:27-11:38:04 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_log"
file="scr_scanner.c" line="1126" message="Attempted to retrieve control
list serial number but no control list is loaded"
2013:09:27-11:38:04 norway httpproxy[26075]: id="0003" severity="info"
sys="SecureWeb" sub="http" request="(nil)" function="sc_update_list"
file="scr_scanner.c" line="730" message="list version: 42147"

OK, it tries to get 400MB RAM to load a new updatelist (we have mem-db running) - isn´t there enough memory?

Not at all:

             total       used       free     shared    buffers     cached
Mem:      16429232   15724312     704920          0    1281680   11842924
-/+ buffers/cache:    2599708   13829524
Swap:      1048568          4    1048564

So maybe not as a block - but there is 11Gig in Kernel Cache - and cache is under normal circumstance to be released to other processes - but I suppose it is NOT freed here and this may be the main reason for httpproxy failing.

I have a Sophos Case open for days now, but they did not even figured out what i did [:@]

Chris, it looks like there's not 400MB of contiguous disk space available.  In any case, http sc_local_db disk/mem is not officially supported, so the quick fix is to set that to none.  I guess you could make a config backup and install from ISO to clean up your hard drive.

Then again, is your hard drive dying?

Cheers - Bob

Chris69's issue is different from the previous thread.

Bob has it mostly right, though it is a memory not harddrive issue.

In the normal use of the UTM memory become fragmented.  The local database requires a block of contiguous memory to load.  If it cannot load then it falls back to disk and if that doesn't work falls back to remote lookups.

There were some fixes that affect this (reducing memory fragmentation and improving fallback) in some of the 9.10x releases.  Please make sure you are using the latest release.

Note: A reboot will temporarily resolve the problem but it may occur again when memory is fragmented again.

update:
it is a bug (27628) in v9.105 with "sc_local_db > mem".
I patched the httpproxy to 9.106.

Unfortunately the Sophos support did not really "supported" me. I have to figure it out by myself. [:(]

sc_local_db is an unsupported feature.  I'm not surprised you didn't get a lot of assistance from Sophos Support - although their first response to any problem should be "install the latest version".  Which is the support I gave you.

To be honest, sc_local_db causes more problems then it solves and I really wish no one would use it.  People like the concept but the reality is that 99% of the time any speed difference is unnoticeable by a human.

Hi Michael,
sorry, I completely disagree:

1. We used the "latest version" at the moment the problem began, the rpm of the httpproxy-module only was released later and installing single rpms is not the main way to keep an UTM up to date.
2. The "sc_local_db" is not "unsupported" rather it was the solution given by official Sophos support during evaluation of a problem just right after initial setup of the UTM:
3. An ugly noticeable delay just before any new http-connect which disappeared immediately after enabling local db in memory.
4. When I figured everything out and decided to patch the httproxy only, the sophos guys confirmed the bug and recommended the single rpm to me, too. No word of sc_local_db beeing an unsupported feature, again.