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

[1.300] 10408 Error on legacy ACC

I keep getting a 10408: Connection Error : timeout encountered waiting for data - please try again.  If I log out and log back in, everything seems fine for until the next error.

What is causing this and is there anything that I can do to resolve the issue?


This thread was automatically locked due to age.
  • That is a very generic error message showing that the ACC backend took a long time communicating with the ACC frontend. The causes may be found in your specific setup.

    http://up2date.astaro.com/2006/05/astaro_command_center_released.html publishes the minimum recommendation for ACC V1 installations:

    Intel Pentium IV IV (2.4 GHz) / AMD Athlon XP 2500, 512 MB RAM (1GB recommended), 40 GB hard disk drive, 1 PCI NIC


    Is your ACC machine below these specs? How many devices are connected to the ACC?
  • I'm running on a P4 2.4 GHz, with 40 GB Drive and 1 GB of RAM.
  • How many devices are connected to the ACC?
  • 91 today.... I have more that I need to add (220 more).  I can't add them because of some bug with 6.303......
  • Hi,

    1) regarding the more pressing issue of the 91 devices:

    Have you installed freshly from an ISO or applied an Up2Date from ACC 1.201 to 1.300? Did you reboot the machine since then on your own?

    Could you please report the following command line output from ACC (before and after a reboot) :

    # netstat -anplt | grep ":44.."

    2) Using more than 100 devices with ACC:

    The minimum hardware requirements are targeted for 100 devices. If you go beyond that, e.g. around 300 devices in your case, you need to find something faster as server platform.

    For 500 devices it is recommended to use a Dual XEON machine with lots of RAM (4 GB) - for comparision an ASG 525 would be suitable. For 300 devices it would be wise to have something in the league of a Dual Core or X2 with 3.8 GHz and 2 GB of RAM and some faster and bigger HDD.

    Thanks alot.

    Cheers,
    Henning
  • I am not planning on running ACC on this platform for the long haul.  I need to proof the ACC is stable enough before we invest in hardware to run it.  So far I have not been able to proof to my management that ACC is stable.
  • Also, the problem with add new devices to my ACC does not appear to be an ACC issue.  It appears to be a ASC 6.303 issue.  When I attempt to add a ASG to ACC, the ASG's WebAdmin locks up.  I either have to reboot the ASG or restart the ASG's WebAdmin.

    I reported this issue.  I was told that this is a known issue with the 6.303.
  • Hi again,

    I understand your need to proof before investing in bigger hardware. With your current system you should definitely be able to accommodate 100 devices and 3-5 concurrent users. 

    Let's look into this matter and back to my previous questions ... 

    I assume now that you installed an Up2Date from ACC 1.201 to ACC 1.300 - is this correct or did you install an ACC 1.300 ISO from scratch?

    Have you rebooted the ACC since detecting the issue and does the problem with the hanging WebAdmin persist if you add device(s) to ACC?

    Could please post the netstat output as I have requested or send it to our support, so we can have a look at it? Additionally, if you could please add the following logfiles after an unsuccessful add device attempt:

    from ASG:

    /var/log/device-agent.log

    from ACC:

    /var/log/database-proxy.log
    /var/log/agent-manager.log
    /var/log/command-server.log

    Your assistance is greatly appreciated.

    Thanks and cheers,
    Henning
  • I'm having the 10408 error every x hours now here.
    Our system is a VM'ed 1.401 on a Dual Core Intel machine, 512MB allocated to this VM, Raid5 Sata-II volume. We have around 40 devices connecting to it from outside.

    The error wasn't there at all until last week I updated (finally succeeded in doing so, I had to do it command-line-wise... but I managed). After upgrade from the original 1.400 VM image to 1.401 this started happening.
    Anyone else seeing this behaviour too in 1.401 or in VMWare?
  • Hi,

    have you changed anything regarding the bandwidth available for the 40 devices? We really did not change much in the 1.401, as far as I remember only refreshed the license, and tweaked something at the Up2Date Cache - which is a different component than the stuff used for device monitoring.

    Could you provide or post the selfmon.log from the ACC. I suspect some foul play and maybe the agent-manager somehow crashes.

    Thanks for your assistance.
    Cheers