ACC Agent fails to register on instance, with error 'websocket: close 1008' observed in agent logs due to duplicate agent IDs - Support and Troubleshooting

ACC Agent fails to register on instance, with error 'websocket: close 1008' observed in agent logs due to duplicate agent IDs .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table of Contents Agent fails to register on instance, with error 'websocket: close 1008' observed in agent logs How to validate this is the result of duplicate agent ID How do Agents create their Agent ID and Register on the instance? Why duplicate Agent IDs are problematic How can this be corrected? Agent fails to register on instance, with error 'websocket: close 1008' observed in agent logs Within the Agent logs, when the agent is started, the agent appears to start and connect successfully, however shortly after startup an error like below will be seen indicating some sort of connection failure.

[Connection error: websocket: close 1008 (policy violation): Connection denied because Connection to instance is lost] transport receive error

You may also observe the name and IP address values of agent records flapping, as multiple agents attempt to update the same record instead of registering a new unique agent record.

How to validate this is the result of duplicate agent ID Further review of the MID debug logs at the same time show evidence that the communication session was closed, as a result of the agent being associated with another session.

2025-12-30T02:16:44.082-0800 WARN (MidWebServer-47301) [DefaultGatewayLogger:524] [session=16643500][agent= ][remote= ] deregistration canceled due to association with other session: 2025-12-30T02:16:44.082-0800 INFO (MidWebServer-47301) [DefaultGatewayLogger:521] [session=16643500][agent=agent_id>][remote= ] communication session closed: CloseReason[1011] 2025-12-30T02:16:44.082-0800 DEBUG (MidWebServer-47301) [WebServerLogger:71] (47301) com.service_now.mid.webserver.jetty.WebServer - callApplicationOnClose(CloseInfo[code=1011,reason=session is orphaned]) Proof of this can be seen in logs like the example below, showing websocket session id "46620" Connecting to

2025-12-30T02:16:44.065-0800 DEBUG (MidWebServer-46620) [WebServerLogger:71] (46620) com.service_now.mid.webserver.jetty.WebServer - HttpConnection@7b154768::DecryptedEndPoint@69b007f7{l=/ ,r= ,OPEN,fill=-,flush=-,to=2/30000} onFillable enter HttpChannelState@20b5c99f{s=IDLE rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0} null; 2025-12-30T02:16:44.065-0800 DEBUG (MidWebServer-46620) [WebServerLogger:71] (46620) com.service_now.mid.webserver.jetty.WebServer - HttpConnection@7b154768::DecryptedEndPoint@69b007f7{l=/ ,r= ,OPEN,fill=-,flush=-,to=2/30000} filled 320 HeapByteBuffer@3f9c91c1[p=0,l=320,c=17408,r=320]={&lt;&lt;&lt;GET /api/mid/mon/metadata...cept-Encoding: gzAddress\r\n\r\n&gt;&gt;&gt;9ab8face1...\x00\x00\x00\x00\x00\x00\x00}; 2025-12-30T02:16:44.065-0800 DEBUG (MidWebServer-46620) [WebServerLogger:71] (46620) com.service_now.mid.webserver.jetty.WebServer - HttpConnection@7b154768::DecryptedEndPoint@69b007f7{l=/ ,r= ,OPEN,fill=-,flush=-,to=2/30000} parse HeapByteBuffer@3f9c91c1[p=0,l=320,c=17408,r=320]={&lt;&lt;&lt;GET /api/mid/mon/metadata...cept-Encoding: gzAddress\r\n\r\n&gt;&gt;&gt;9ab8face1...\x00\x00\x00\x00\x00\x00\x00} {}; 2025-12-30T02:16:44.065-0800 DEBUG (MidWebServer-46620) [WebServerLogger:71] (46620) com.service_now.mid.webserver.jetty.WebServer - REQUEST for // /api/mid/mon/metadata on HttpChannelOverHttp@23319c6f{s=HttpChannelState@20b5c99f{s=IDLE rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0},r=1,c=false/false,a=IDLE,uri=// /api/mid/mon/metadata,age=0}; GET // /api/mid/mon/metadata HTTP/1.1; Host: ; Sensu-Agentname: ; Shortly after followed by a similar block of logs showing websocket session id "47736" connecting to

2025-12-30T02:16:44.066-0800 DEBUG (MidWebServer-47336) [WebServerLogger:71] (47336) com.service_now.mid.webserver.jetty.WebServer - HttpConnection@75371a4e::DecryptedEndPoint@3c9ceb9b{l=/ ,r=/ ,OPEN,fill=-,flush=-,to=4/30000} parse HeapByteBuffer@38679996[p=0,l=399,c=17408,r=399]={&lt;&lt;&lt;GET /ws/events HTTP/1.1\r\n...\nUpgrade: websocket\r\n\r\n&gt;&gt;&gt;M\x10\x0e}\x84\xB8\xC8\x112...\x00\x00\x00\x00\x00\x00\x00} {}; 2025-12-30T02:16:44.066-0800 DEBUG (MidWebServer-47336) [WebServerLogger:71] (47336) com.service_now.mid.webserver.jetty.WebServer - upgrade HttpChannelOverHttp@35f5f689{s=HttpChannelState@757be9fa{s=IDLE rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0},r=0,c=false/false,a=IDLE,uri=null,age=0} Upgrade: websocket; 2025-12-30T02:16:44.066-0800 DEBUG (MidWebServer-47336) [WebServerLogger:71] (47336) com.service_now.mid.webserver.jetty.WebServer - No factory for Upgrade: websocket in ServerConnector@3d500258{SSL, (ssl, http/1.1)}{0.0.0.0:8443}; 2025-12-30T02:16:44.066-0800 DEBUG (MidWebServer-47336) [WebServerLogger:71] (47336) com.service_now.mid.webserver.jetty.WebServer - REQUEST for // /ws/events on HttpChannelOverHttp@35f5f689{s=HttpChannelState@757be9fa{s=IDLE rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0},r=1,c=false/false,a=IDLE,uri=// /ws/events,age=0}; GET // /ws/events HTTP/1.1; Host: ; Sensu-Agentname: ; Importantly, for both of these websocket sessions, we see them both using the same Sensu-Agentname value.

At the same time, we see that session 46620 closes.

2025-12-30T02:16:44.066-0800 DEBUG (MidWebServer-46620) [WebServerLogger:71] (46620) com.service_now.mid.webserver.jetty.WebServer - onWriteComplete(true,null) s=CLOSING,api=BLOCKED,sc=false,e=null-&gt;s=CLOSED,api=BLOCKING,sc=false,e=null c=null cb=null w=false; How do Agents create their Agent ID and Register on the instance? When an agent starts for the first time, it looks for the agent_now_id file in the cache folder. If the file is not present, the agent will generate a new ID and create this file. If the file is present, the agent_id within it is used.

This then means when the agent then connects (to either a MID or mid-less architecture) for, it is added to the Client State Map and sends keep-alives every 60 seconds with some basic details, including agent_id .

Then, every 60 seconds the MID packages the currently connected agents from its client state map and sends it to the instance onto the "updateClientTimestamp" API.

This API is responsible for maintaining "last refreshed" timestamp for all Agents - and is also responsible for registering agents into the [ sn_agent_cmdb_ci_agent ] table. It achieves this by first looking up the agent_id onto this table and if present it simply updates the last_refreshed and MID field on the associated Extended Info record for this agent - and if the agent_id is not found then it will register a new agent record on the instance.

Why duplicate Agent IDs are problematic If a deployment package for ACC is created without removing the agent_now_id file, the agents will all use the same agent ID when connecting. This can result in many separate agents colliding onto a single agent record in the instance. If they connect to the same MID, the MID will attempt to drop the existing connection in favour of the new connection for what it believes is the same agent.

When multiple agents return the same agent_id , the API will conflict these agents into the same [ sn_agent_cmdb_ci_agent ] record, instead of individual agents registering their own agent record.

How can this be corrected? Note: From version 5.0.0 of ACC-Framework we have an inbuilt method to detect and resolve this issue.

When a duplicate Agent ID is detected, an ACC-4004 error is logged - in response to this error agents will re-generate their own agent IDs.

If it is the intent of your deployment process to retain hostname, serial number and primary interface MAC address across systems, which could result in this deterministic agent_id being the same across multuple systems, you can set the agent to use a random agent ID rather than a deterministic agent ID - this can be achieved in the acc.yml file by adding "use-random-agent-key-id: true" property.

This Article contains more information on how ACC Agent IDs are created, and how to prevent duplicate Agent IDs

KB2245818 How ACC Agent ID is created, and how to prevent duplicate Agent IDs