Swap goes over the top possibly bad Up-2-Date

Small update - it seems only versions 7.201 and above are affected. Gateways running 7.104 have no problem so far (at least those I have access to)

Lost one firewall this morning already.

Primary firewall now on 99%, and I am trying to get a period to shut it down, as this has gone in less than 8 hours since 03:00 BST this morning, we need a fix urgently.

Backup is a ASG220 and has little free memory at the best of times.

If this shuts the business down it will cost a lot of money, and I will be looking for new firewalls tomorrow.

Get it sorted now please.

Dave P

Hi,
 
you don't have to shutdown the firewall. Connect via SSH to the console.
Go to /etc/mdw/scripts and then "./ctasd restart".
 
This should resolve your problem.

Thanks,

at most boxes this frees the swap and memory however, at some boxes the degenerative status of the issue led the gateway to another type of problem which relates to the reporting/logging and SQL.

The syslog now gets filled by the following message at tremendous rate:

2008:07:31-13:04:01 (none) ulogd[6654]: sql1: transaction: cannot rollback - no transaction is active

Regards,
Zdenek

The problem on one of my firewalls was I could not even logon, the console was timing out. I had to hit the big switch.

I have managed to get on one of the other firewalls and issued the command, but I have been monitoring the memory and it's being used up, at this rate it will be full again in about 6-8 hours.

I have tried to call support - nobody free, left voicemail on support line, but still waiting for anyone to contact me.

Dave

Add me to the crowd, I came here to post to see what ctasd did.  Glad to see I am not alone.  Mine started spiralling out of control at 2pm EST and by 7PM EST it died.  I'll be watching this thread religously for the solution since support is just about worthless.

Just FYI: we are aware of the issue and are working with our vendor (Commtouch) on a solution. I'll post here again when we have more information.

yep, restarting ctasd has an immediate impact on swap usage. However, the correct path is /var/mdw/scripts

It appears that the issue is fixed... the memory usage at 2 customer sites that were having a problem has stayed below 10% for the past 20 minutes or so... it was growing to almost 50% within an hour just a little while ago.

Yes, the offending servers are now offline.  You should see memory level off, if you restart ctasd now the memory use should be normal (and stay there).

If you are still experiencing problems, please restart ctasd as mentioned previously- the issue has been resolved and should not return.

Here is an excerpt from the vendor's statement on the issue from yesterday:

--------------------------------------------------------------------
As of 12:30 PM Pacific time Commtouch Detection Centers are back to
their full capacity.

Initial investigation of the issue, showed that the problem started at
4:30 AM Pacific time. It was a result of a fault in the Proactive
Pattern system that caused excessive downloads/updates, by some of the
clients. This caused additional load on the Data Centers. In turn some
of the clients experienced intermittency while communicating with the
Commtouch Data Centers.

The fault in the Proactive Pattern update system was fixed.

During the upcoming week we will look into adding additional measures in
order to prevent such issues in the future.
We are sorry for any inconvenience,
-----------------------------------------------------

If you are still experiencing problems, please restart ctasd as mentioned previously- the issue has been resolved and should not return.

Here is an excerpt from the vendor's statement on the issue from yesterday:

--------------------------------------------------------------------
As of 12:30 PM Pacific time Commtouch Detection Centers are back to
their full capacity.

Initial investigation of the issue, showed that the problem started at
4:30 AM Pacific time. It was a result of a fault in the Proactive
Pattern system that caused excessive downloads/updates, by some of the
clients. This caused additional load on the Data Centers. In turn some
of the clients experienced intermittency while communicating with the
Commtouch Data Centers.

The fault in the Proactive Pattern update system was fixed.

During the upcoming week we will look into adding additional measures in
order to prevent such issues in the future.
We are sorry for any inconvenience,
-----------------------------------------------------

Well it seems there is still some problem with the ctasd or Comtouch servers because the memory allocation on my box is slowly going up and over the top to swap again...

Maybe it would be better to let the middleware to restart the ctasd daemon on a regular basis in order to prevent excessive memory/swap use... ?

I just restarted the daemon in question manually from the shell and it freed some 300M of memory.

Zdenek

The same symptoms here. I also had to restart the smtp and pop proxys to fix this issue with ctasd temporary.

My situation is the same. [:@]

Same here again. Swap is getting chewed up. Restart the ctasd and swap goes down. Seems like a vary bad design when a 3rd party vender can in effect cause outages accross all the deployed ASG's out there.

We have had reports of this problem resurfacing, the appropriate folks are working on it.  Until there is a resolution, please check ctasd's memory use in top and restart as needed:
/var/mdw/scripts/ctasd restart

another way to work around this is to turn off the http proxy and point your dns forwarders to opendns and use it for content filtering..an account is free and it's pretty effective.

This issue doesn't involve the HTTP proxy at all, this is with one of the anti-spam components of the SMTP/POP3 proxy.

We haven't heard of problems this afternoon, if anyone is still having issues with ctasd memory use, please let me know.

then turn off the affected proxies for now.  The fact that a third party can send an update out to your product and screw it up is a bad design flaw IMO.

then turn off the affected proxies for now.  The fact that a third party can send an update out to your product and screw it up is a bad design flaw IMO.

That's not an option... Having to monitor the box for memory use is bad, bud turning off the proxy and have no spam/virus/... protection at all is even worse especially for boxes handling a lot of traffic - that would hit the users behind the box hard and the reputation of Astaro even harder... [:(]

You do not need to turn off the proxies, there is no problem with the spam update system.  A small number of customers reported increased RAM utilization due to ctasd earlier this week, but no cases reported to US support were a repeat of the previous issue.  Updates may cause temporary increases in RAM use and it is possible that some users experienced a repeat- but we haven't been able to reproduce it.

Optimizations have been made to avoid the problem in the future.

If you are still experiencing issues with ctasd, please restart the daemon and monitor memory use with the top command.  If a problem with ctad returns, please let me know and I will investigate.