Transport.publish_address was printed as [ip:port] instead of [hostname/ip:port] (7.5.1)

Hi
I am aware of other similar posts regarding the same issue as I describe here. I have tried to follow the posts at use the suggested solutions, but I have not had any success implementing the solution. Therefore I try a new topic.

Problem:
After upgrading to 7.5.1 we see this log-entry in the elasticsearch-cluster_deprecation.log every 3 seconds:
[2020-03-23T12:35:28,656][WARN ][o.e.d.t.TransportInfo ] [<SERVER>] transport.publish_address was printed as [ip:port] instead of [hostname/ip:port]. This format is deprecated and will change to [hostname/ip:port] in a future version. Use -Des.transport.cname_in_publish_address=true to enforce non-deprecated formatting.

System:
OS: Windows
Elastic: 7.5.1
OpenJDK: 13.0.1
Nodes: 1
Running: As Elastic Service

Already tried:

  1. Adding the following to jvm.options:
    -Des.transport.cname_in_publish_address=true

  2. Adding the following to elasticsearch.bat
    -Des.transport.cname_in_publish_address=true
    (in the line for: %JAVA% %ES_JAVA_OPTS%)

  3. Adding the following to elasticsearch-service.bat
    -Des.transport.cname_in_publish_address=true
    (in the line for: set ES_PARAMS=)

In all the above tries the same logs are still present in the elasticsearch-cluster_deprecation.log

elasticsearch.yml is:

    bootstrap.memory_lock: false
    cluster.name: <CLUSTER-NAME>
    discovery.seed_hosts:
     - <SERVER>
    cluster.initial_master_nodes:
      - <SERVER>
    http.port: 9200
    network.host: <SERVER>
    node.data: true
    node.ingest: true
    node.master: true
    node.name: <SERVER>
    path.data: C:\ProgramData\Elastic\Elasticsearch\data
    path.logs: C:\ProgramData\Elastic\Elasticsearch\logs
    xpack.license.self_generated.type: basic
    xpack.security.enabled: false
    logger.org.transport.level: warn

The elasticsearch-cluster.log writes this under startup, which I think actually indicates that it is OK:
[2020-03-23T11:56:21,473][INFO ][o.e.t.TransportService ] [<SERVER>] publish_address {<SERVER>/<IP>:9300}, bound_addresses {[<IPV6>]:9300}, {<IP>:9300}

Checkup:
When performing the following in the API I get the following:
GET /_nodes
#! Deprecation: transport.publish_address was printed as [ip:port] instead of [hostname/ip:port]. This format is deprecated and will change to [hostname/ip:port] in a future version. Use -Des.transport.cname_in_publish_address=true to enforce non-deprecated formatting.

And the transport_address is:
"transport_address" : "<IP>:9300",

In the JVM input_arguments the:
-Des.transport.cname_in_publish_address
is not present?

It could might as well be that I am missing something in the setup.

If you have some input for the above, then please share it with me.

Best Regards,
Martin

Hello Martin,

I just fixed the same problem for me.

You have to add the line -Des.transport.cname_in_publish_address=true in the jvm.options file that you'll find at the root of your elasticsearch folder and then restart your node.

Regards,

Hi @stack

Thank you for your fast response.
I already tried to add the line to jvm.options and restarting the Elasticsearch service as described in (1.) in my post.
However - does it perhaps require a restart of the whole server as well? Because even if I add the line to jvm.options the import of the jvm change does not apply when restarting the Elasticsearch service.

Best Regards,
Martin

Hello,

I already tried to add the line to jvm.options and restarting the Elasticsearch service as described in (1.)

Sorry i missed that point.

Restarting the elasticsearch service should be all you have to do. I have 3 nodes on CentOS8 where i applied this change.

1 month ago i used to have my 3 nodes on windows server 2019 but i switched because i couldn't install the elasticsearch service propely on windows and i also realised i had no benefits on windows.

When i was on windows, restarting elasticsearch meant killing the cmd launched by the bat file. Is it how you restart elasticsearch too or do you use the services manager ? In any case, it wouldn't hurt to try restarting the windows server, unless you have other important services running on it.

Hi @stack

It's quite OK. Sometimes one just need to discuss a problem to "see the light" :wink:
I solved the problem now in Windows by:

  1. Stopping the current Elasticsearch service
  2. Adding the "-Des.transport.cname_in_publish_address=true" line to jvm.options
  3. Removing the existing Elasticsearch service: bin\elasticsearch-service.bat remove
  4. Installing the Elasticsearch service again: bin\elasticsearch-service.bat install (to "reload" the modified jvm.options file)
  5. Setting the Elasticsearch service to be run "Automatic"
  6. Starting the Elasticsearch service again and verifying:
    6.1) Elasticsearch is started including the "-Des.transport.cname_in_publish_address=true" (elasticsearch-cluster.log)
    6.2) The deprecated log entry is not appearing again (elasticsearch-cluster_deprecation.log)
    6.3) The nodes does not show the deprecation information anymore and the "-Des.transport.cname_in_publish_address=true" is loaded (Elasticsearch API: GET /_nodes)

Thank you for your input. I will mark my own answer as the solution.

Best Regards,
Martin

2 Likes

Hi Martin,

Glad you figured out.

  1. Installing the Elasticsearch service again: bin\elasticsearch-service.bat install (to "reload" the modified jvm.options file)

I believe the elasticsearch service take infos from the jvm.options file when installed and then pass theses infos as parameter for the launch of the service, which would be why it finally worked when you reinstalled the service.

Bye !