Client Machines get disconnected from task server registration. If we restart Task services or reboot, the client gets registered.

Products

• IT Management Suite

Issue/Introduction

The customer has noticed that client machines get disconnected from task service registration frequently. Client machines appear as if they are not connected to a task server. If they just restart the "Altiris Client Task Dataloader" and "Altiris Object Host" services on the Task Server(s), then things start to work again. However, sometimes the Task services on the Task server will not restart and memory usage seems to be going higher over time. If the customer restarts the Task Server machine, then it gets registered and memory goes down to normal again. The Task Server will be working just fine for 1 or 2 days and then it gets to the same state where no client can't register to it, even it cannot register to itself. 

Error type: Network error
Error code: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond (10060)
Error note: SocketIOStrategySyncSelect::Receive error
-----------------------------------------------------------------------------------------------------

Task Server Connection: Failed to request 'https://<TaskServer01>.example.com:443/Altiris/ClientTaskServer/Register.aspx?lastResort=true&resTypeGuid={493435F7-3B17-4C4C-B07F-C23E7AB7781F}&sysType=Win64&version=8.6.2184&resourceGuid=4654a8ec-4806-407b-9f64-b457350c9c8a&crc=0008000600000888', error: An operation was attempted on something that is not a socket (0x80072736)
-----------------------------------------------------------------------------------------------------

 

Environment

ITMS 8.5 RU4, 8.6 RU1, 8.6 RU2

Cause

Known issue. Our Dev team has identified that the Altiris Object Host (AtrsHost.exe) service had a large number (usually thousands) of identical threads opened causing the service to be overwhelmed and stuck waiting on some native events. For example, with more than 30,000 threads running, there were no limits on thread pool usage in WebSocket functionality.

Our Dev team reviewed the code and added changes to avoid the deadlocks between threads. 

Resolution

This issue has been reported to our Broadcom Dev team. A fix is targeted for ITMS 8.6 RU3. 

8.6 RU2: A point fix is currently available. See KB 235538 "CUMULATIVE POST ITMS 8.6 RU2 POINT FIXES"
8.6 RU1: A point fix is currently available. See KB 221269  "CUMULATIVE POST ITMS 8.6 RU1 POINT FIXES"
8.5 RU4: A point fix is currently available. See KB 198337 "CUMULATIVE POST ITMS 8.5 RU4 POINT FIXES"