Why deployment server sees Linux UX univeral forwarder as the GUID even with a set ServerName?

[t9445]

Hello, we have what appears to be an incredibly weird scenario going on:

We commonly override the serverName for deployment purposes in the server.conf

(Please note: We have/are ongoing successfully been doing this for some time with Linux and Windows UFs)

However for a specific subset of Linux UX forwarders (v6.1.3 Build 220630) the serverName (as seen by the deployment server) is the GUID as configured in the instance.cfg file

Note: deployment-server is Linux, same version (Build 220630)
I have checked, and yes the serverName is set as desired in $SPLUNK_HOME/etc/system/local/server.conf and NO – there are no other server.conf files with a serverName entry

When (as an experiment) I removed the instance.cfg file and restarted the UF, a new instance.cfg file is generated and with a new GUID as expected – the UF then appears to the deployment-server as the new-GUID (e.g there is nothing "stuck" in any config files with the serverName set as the OLD-GUID)

The serverName consistently is coming through as seen at the deployment server as the GUID ?

Is this a 6.1.3 (Linux) Universal forwarder bug ? (we have other instances running 6.1.2 and earlier etc successfully ) or have others run into this and what is the fix please? (Note: I have tried setting the environment HOSTNAME per some others, no success)

Appreciate any insights – next step will be to migrate the 6.1.3 UFs to 6.1.4 , however not an easy task since we will have to re-deploy a number of images in the cloud if we take this approach, so would like to be certain it is a bug or if there is any workarounds for this scenario?

[t9445 · Accepted solution]

(Follwoing up) -- the reason for this issue was (yup...) human error - in this specific scenario we are automatically deploying instances to the cloud - as part of the "spin-up" we update the local deploymentclient.conf to the desired hostname for splunk-software-distribution to-pick-up within the cloud, long story short - the code was incorrectly updated (by an overzealous programmer 🙂 -- to use hostname instead of clientName (DOH!).