We’ve been a Automox client since May 2022.
When we started to deploy the Automox Agent to our end user Windows 10 and 11 laptops we ran into a problem after about a month when a not insignificant amount stopped communicating with the Automox console. Without exception, when we investigated we found the Automox Agent wasn't running on the end point. Starting the service or restarting the machine would fix it.
Reviewing amagent.log would present messages about abnormal closure to websocket.
2022/09/25 00:54:07 stompclient.go:399: Error in axstomp readframe: websocket: close 1006 (abnormal closure): unexpected EOF
2022/09/25 00:54:07 stompclient.go:437: Consumer error: websocket: close 1006 (abnormal closure): unexpected EOF
We were told the root cause was because our end users connect to a corp VPN and that the momentary change in connectivity for those devices was causing the Automox agent to to crash. While I understood the logic, I felt the agent should be able to handle a change in connectivity more gracefully than simply dying.
This week I've discovered 100% of five newly deployed Debian Linux based VMs in a datacentre have also stopped communicating with the console. When checked, every one of them have the service stopped (technically it said Active/Exited). They all stopped on different days and times. Two of these machines were behind a content filtering proxy, three of them had direct internet connectivity. None of them were connecting to a VPN.
It feels to me as though the root cause is that the agent doesn't handle interruption to the websocket communication very well, and that instead of handling that situation in the agents code, they've chosen to rely on the the OS's ability to respawn the service.
Anyone experiencing similar issue or it it just me?