Troubleshooting: SecureAuth/Elastic FileBeat Service Won't Start or Keeps Stopping

Version Affected: 9.2 and up
 
 

Overview

After it has been installed successfully, the SecureAuth/Elastic FileBeat service can fail to start, or can start and then stop again on its own. There are multiple potential causes, distinguished by the exact symptom and by the entry in the FileBeat log:

• See Cause 1 - The service will not start at all, and Services shows Error 1067: The process terminated unexpectedly
• See Cause 2 - The service starts, runs for a period, then stops on its own, repeatedly

These causes are not related, so a fix for one cause will not resolve the other.

 

In this article

• Cause 1: Corrupt Registry File Prevents the Service From Starting
• Cause 2: Oversized UDP Packets Cause the Service to Stop

Cause 1: Corrupt Registry File Prevents the Service From Starting

The SecureAuth/Elastic FileBeat service will not start, and shows Error 1067: The process terminated unexpectedly when started manually from the Services console. The latest FileBeat log, located at C:\ProgramData\SecureAuth Corporation\filebeat\logs, shows an entry similar to:

CRIT Exiting: Could not start registrar: Error loading state: Error decoding states: invalid character '\x00' looking for beginning of value

This happens when the FileBeat service was not shut down cleanly, and its registry state file is left in a state it cannot read back.

Resolution 1:

1. Open the Services console and confirm the SecureAuth/Elastic FileBeat service is stopped.
2. Go to C:\ProgramData\SecureAuth Corporation\filebeat\data and delete the registry and registry.old files.
   
3. Start the SecureAuth/Elastic FileBeat service from the Services console.

Cause 2: Oversized UDP Packets Cause the Service to Stop

The SecureAuth/Elastic FileBeat service stops unexpectedly at random intervals. When restarted, it runs again for an arbitrary period (commonly a few minutes) before stopping again. The FileBeat log, located at C:\ProgramData\SecureAuth Corporation\filebeat, shows an entry similar to:

ERROR [udp] udp/server.go:107 Error reading from the socket read udp 127.0.0.1:6000: wsarecvfrom: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself. {"address": "127.0.0.1:6000"}

FileBeat is receiving UDP packets from an IdP realm that are larger than its default 10KB message-size limit, which causes the service to shut down. These oversized packets are usually caused by log messages containing group membership information expressed as distinguished names — a user who belongs to many groups, or to deeply nested groups, can easily produce a log entry over the 10KB limit.

Resolution 2:

1. Stop the SecureAuth/Elastic FileBeat service from the Services console.
2. Open the FileBeat configuration file at C:\Program Files\SecureAuth Corporation\FileBeat\filebeat.yml.
3. Under the UDP input, increase max_message_size from 10KiB to 64KiB — the maximum size for a UDP packet:
   
   

   - type: udp
     max_message_size: 64KiB
     host: "127.0.0.1:6000"

4. Start the SecureAuth/Elastic FileBeat service.
5. Confirm the error no longer appears in the FileBeat log.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.