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

Sophos UTM-9.405-5 data disk filling up multiple times a week

Hi

I have 3 UTM-9.405  appliances. The 2 of them are filling the data disk up to almost 100% multiple times a week. 

It's all crashdumps in the core folder. I'm deleting them in the start and end of every week for almost a month now. 

Both of the appliances got 36,4GB Log disk & 27,7 GB Data disk, with 2 GB of swap space. 
One of the appliances got 2GB ram and the other got 4GB ram. Both of them are utilizing maximum RAM & Processor power almost every day.
I can't see a pattern for this hardware utilization. It looks like it's random and lasting for probably 0,5-1 hour every time before turning back to normal. 
All of my appliances runs on top of ESXi 6.0 hosts.

I've tried contacting support multiple times without any answers. I really hope some of you have any suggestions. 



This thread was automatically locked due to age.
Parents Reply Children
  • Hi Bob

    Last friday i got some cssd.**** with a size from 3,2-4G

    Today I've got cssd.22163 (3,3G), cssd.30480 (3,8G) and a mailsec-reporte.23283 on 9.8M

  • Hi Christian,

    We're facing the same issue here. Since we have platinum support, I contacted Sophos support and got and answer... Well, if you can call that an answer: first got it in German then, when I requested an answer in English, I got this google translate... Sophos support quality is hitting an all-time low.

    Anyway: here is the reply from support:

     Hello Mr. XXX, the problem is known to us and is not a UTM-whammy but a LABs Issue. 
     Colleagues SophosLabs are to fix the problem. 
     According to 3rd level support an IDE file should already have been published, which resolves the problem. 
     However, I have just picked out the Jira for the problem: CPISSUE-3649 JS emulation fail on customer sample 
     (memory consumption spike, hurting SEA) Here the bug is still unresolved status. 
     Current workaround looks that cssd core dump files should be deleted from the directory / var / storage / cores, 
    if the disc should be fully running. (What I've just done)

     

    In other words: they know about it, it's a bug lost somewhere in between different Sophos department and the "solution" is to delete the core dumps by hand until they manage to solve it.

  • Excellent work - thanks, Stéphane!

    If you feel comfortable  adding a cron job, add the following line to /etc/crontab-static

    50 23 * * * root rm /var/cores/cssd.*

    After that go into WebAdmin and force the regeneration of /etc/crontab by toggling the setting for 'Firmware Download Interval' to a diiferent period and then back.

    Once someone announces that the problem is fixed, just delete the line from /etc/crontab-static and again force the regeneration of /etc/crontab.

    Cheers - Bob

  • Thanks Bob, that's an excellent suggestion.

     

    Stéphane

  • Hi all,

    CSSD is ringing alarm bells from when talking to Support the other day that there are crash dumps being caused by the Sophos AV engine due to a problematic library load.

    Set your AVs in their respective places to single scan and set the system settings to use the primary AV engine as Avira. Also take note (thanks Balfson) that setting the primary scanning engine to Avira and using Single Scan mode will disable Sandstorm protection as it requires the Sophos AV engine to operate.

    You should see the issues go away until they resolve the bad library load.

    Emile

  • Good point, Emile. If it's just a problem with savi patterns, they should be able to fix it quickly.

    Those using Sandstorm need to know that it only works when the Sophos AV is active.

    Cheers - Bob

  • Hi Bob,

    Quite right on the Sandstorm! Added to my comment :)

    Emile

  • Thank you all for the answers. 

    And yes support is lacking a bit so it's nice we can figure things out together.