It has been 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 you 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 you restart 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. The following logs errors are seen:
Errors seen in the logs include:
Error type: Network errorError 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)-----------------------------------------------------------------------------------------------------
ITMS 8.x
Known issue. The cause has been identified as 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.
After a code review, changes have been added to avoid the deadlocks between threads.
This was fixed in ITMS 8.6 RU3 and fixes for earlier version are found in:
8.6 RU2: A point fix is currently available. See KB article CUMULATIVE POST ITMS 8.6 RU2 POINT FIXES
8.6 RU1: A point fix is currently available. See KB article CUMULATIVE POST ITMS 8.6 RU1 POINT FIXES
8.5 RU4: A point fix is currently available. See KB article CUMULATIVE POST ITMS 8.5 RU4 POINT FIXES