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

[v8.002][BUG] selfmonng error message (ctasd script restarting)

Hi All

I have noticed "check Failed increment ctasd_mem_usage counter" error on the selfmonitoring log: (attahed is the full log)


2010:09:24-13:58:14 stuffman selfmonng[4260]: W child returned status: exit='0' signal='0'
2010:09:24-13:58:19 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 1 - 10
2010:09:24-13:58:24 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 2 - 10
2010:09:24-13:58:29 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 3 - 10
2010:09:24-13:58:34 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 4 - 10
2010:09:24-13:58:39 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 5 - 10
2010:09:24-13:58:44 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 6 - 10
2010:09:24-13:58:49 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 7 - 10
2010:09:24-13:58:54 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 8 - 10
2010:09:24-13:58:59 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 9 - 10
2010:09:24-13:59:04 stuffman selfmonng[4260]: W check Failed increment ctasd_mem_usage counter 10 - 10
2010:09:24-13:59:04 stuffman selfmonng[4260]: W triggerAction: 'cmd'
2010:09:24-13:59:04 stuffman selfmonng[4260]: W actionCmd(+): '/var/mdw/scripts/ctasd restart'
2010:09:24-13:59:08 stuffman selfmonng[4260]: W child returned status: exit='0' signal='0'
2010:09:24-13:59:13 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 1 - 10
2010:09:24-13:59:18 stuffman selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 2 - 10 



Thanks


This thread was automatically locked due to age.
logfiles_20100924135827.zip
  • from the fallback log:
    2010:10:02-09:36:36 [local0:info] ctasd[19580]: Loading configuration file /etc/ctasd/ctasd.conf
    
    2010:10:02-09:36:39 [local0:err] ctasd[19580]: CFCTcpServer Thread Exception on Create/listen socket: Error (98)
    2010:10:02-09:36:39 [local0:err] ctasd[19580]: Init http server failed
    2010:10:02-09:37:29 [local0:info] ctasd[19615]: Loading configuration file /etc/ctasd/ctasd.conf
    2010:10:02-09:37:30 [local0:err] ctasd[19615]: CFCTcpServer Thread Exception on Create/listen socket: Error (98)
    2010:10:02-09:37:30 [local0:err] ctasd[19615]: Init http server failed
    2010:10:02-09:37:31 [local0:info] ctasd[19619]: Loading configuration file /etc/ctasd/ctasd.conf
    2010:10:02-09:37:33 [local0:err] ctasd[19619]: CFCTcpServer Thread Exception on Create/listen socket: Error (98)
    2010:10:02-09:37:33 [local0:err] ctasd[19619]: Init http server failed


    I had the same issue on version 7.503 as well (https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39558). Issue was reported by utm_kid on version 7.851 but nothing happened as well [:(] (https://community.sophos.com/products/unified-threat-management/astaroorg/f/102/t/68914) and it has been identified as a bug!
  • Hi Wingman,

    the mantis ID #12274 you're referring to as reported in version 7.851 was closed internally as a duplicate. It appears to be very hard to reproduce the issue reliably. But apparently it is no duplicate, so I will re-open it and have another detailed look at it. However, as the ctasd is some piece of closed source software we licensed from Commtouch, this will need some extra time for investigations.

    To temporarily solve the problem, please restart the ctasd deamon by running the following command on a root shell of your ASG:
    /var/mdw/scripts/ctasd restart


    Regards,
    mlenk
  • Hi Wingman,

    the mantis ID #12274 you're referring to as reported in version 7.851 was closed internally as a duplicate. It appears to be very hard to reproduce the issue reliably. But apparently it is no duplicate, so I will re-open it and have another detailed look at it. However, as the ctasd is some piece of closed source software we licensed from Commtouch, this will need some extra time for investigations.

    To temporarily solve the problem, please restart the ctasd deamon by running the following command on a root shell of your ASG:
    /var/mdw/scripts/ctasd restart


    Regards,
    mlenk


    Thanks Mlenkfor re opening the ticket.
     I understand it might take time which is normal. I just wanted to make sure that the problem is known to the team and someone is working to resolve it
  • After running the command to restart the script
    loginuser@******:/home/login > su -
    Password:
    ******:/root # /var/mdw/scripts/ctasd restart
    Shutting down ctasd:
    Starting ctasd:


    2010:10:05-08:25:22 **** selfmonng[4260]: W check Failed increment ctasd_mem_usage counter 10 - 10
    2010:10:05-08:25:22 **** selfmonng[4260]: W triggerAction: 'cmd'
    2010:10:05-08:25:22 **** selfmonng[4260]: W actionCmd(+): '/var/mdw/scripts/ctasd restart'
    2010:10:05-08:25:26 **** selfmonng[4260]: W child returned status: exit='0' signal='0'
    2010:10:05-08:25:31 **** selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 1 - 10
    2010:10:05-08:25:36 **** selfmonng[4260]: I check Failed increment ctasd_mem_usage counter 2 - 10

    Do I have to reboot the device?
  • please run once:
    killall -9 ctasd

    to kill all dangling ctasd processes.

    We are still working on this issue.
  • I am still having the issue. Even after kill -9 the process after a while issue came back
  • The bug isn't solved yet...
  • Correct, the issue isn't fixed yet. But we're working on it. [:)]

    As a work around you can replace the ctasd start script [FONT="Courier New"]/var/mdw/scripts/ctasd[/FONT] by the attached script ([FONT="Courier New"]ctasd.txt[/FONT]), which is the version that was used in ASG version 8.001 and which should still work with ASG 8.002. Please don't forget to make a backup of the old startup script before replacing it.

    BEWARE: As with all changes you are doing as root on the shell: If you do this, you will void your support.

    Please report back if this solves the problem.

    Regards,
    mlenk
  • I am using version ASG 8.002 64bit
    in this post https://community.sophos.com/products/unified-threat-management/astaroorg/f/56/t/49006
    cybermuz says https://community.sophos.com/products/unified-threat-management/astaroorg/f/56/t/49006

    Is it possible that the problem is about 64bit kernel?

    Should all of us replace it with the 32bit kernel and solve the problem this way?