9

Attempting to use ${HOSTNAME} in a config file does not work! According to the documentation, config files should resolve environment variables as mentioned in the docs:

substitutions fall back to environment variables if they don't resolve in the config itself, so ${HOME} would work as you expect. Also, most configs have system properties merged in so you could use ${user.home}.

Is there a way to get hostname into the config file?

Reproduction
Add host.name=${HOSTNAME} to an application.conf file, then try and access it from anywhere. For example try adding 

Logger.info(s"Hostname is ${current.configuration.getString("host.name").getOrElse("NOT-FOUND")}")

to the Global.scala.

Environment
This was run on a RHEL6 environment where echo $HOSTNAME produces precise32 so the environment variable exists, this is not the program hostname.

tysonjh
  • 1,329
  • 1
  • 12
  • 27
  • Did you set HOSTNAME explicitly as environment variable? "hostname" itself is a program. On which platform do you operate? How looks your application.conf and how do you retrieve the configuration setting? – Schleichardt Sep 12 '13 at 19:27
  • Yes, please show us your `application.conf` and also where you use that in the application as well. – maba Sep 12 '13 at 20:22
  • Updated question. HOSTNAME is set on the server, nothing special in application.conf besides attempting to set the `host.name` configuration variable. – tysonjh Sep 12 '13 at 20:45
  • 1
    FWIW I just came across this same annoying discrepancy between the docs and the actual implementation. If I remember correctly this same bug was there a few years back too. Maybe the Typesafe guys has abandoned the Typesafe Config project? – eirirlar Nov 19 '15 at 12:57

3 Answers3

8

The solution seems to be passing in the hostname via a system property as -Dhost.name=$HOSTNAME or -Dhost.name=$(hostname). I'd imagine in windows it would be something else, but this works for *NIX environments.

Unless anyone can come up with something cleaner this will be the accepted answer.

tysonjh
  • 1,329
  • 1
  • 12
  • 27
  • 8
    What's happening here is that HOSTNAME is a shell variable but not an environment variable. See http://stackoverflow.com/questions/3341372/differnce-between-the-shell-and-environment-variable-in-bash Another way to put it is that HOSTNAME is not "exported" it's just internal to the bash process. In lowlevel terms, when bash forks a child process it doesn't pass unexported variables to the child's environment. The practical implication is that you could solve this by doing `export HOSTNAME` before you start the JVM. – Havoc P Jan 11 '14 at 01:16
7

This probably isn't working because $HOSTNAME doesn't seem to actually be an environment variable:

jamesw@T430s:~$ echo $HOSTNAME
T430s
jamesw@T430s:~$ export|grep HOSTNAME
jamesw@T430s:~$

So it must be some other special bash thing.

James Ward
  • 29,283
  • 9
  • 49
  • 85
  • If the app is invoked via the shell then this variable should be available – tysonjh Sep 13 '13 at 14:35
  • 1
    I stand corrected: `scala> System.getenv("HOSTNAME")` and `scala> System.getProperty("HOSTNAME")` both return null. – tysonjh Sep 13 '13 at 14:39
1

You should see if calling System.getenv("HOSTNAME") returns a non-null value. If not, then HOSTNAME is not an env variable according to the java runtime which is what is important for mapping that to a config property in typesafe config. I tried this with HOSTNAME and even though I could echo it in bash, it was not available in java as a env substitution. I changed it to USER and everything worked as expected.

cmbaxter
  • 35,283
  • 4
  • 86
  • 95
  • You're also correct, the test verified that HOSTNAME appears to be unavailable in the JVM as an environment variable. Thank you – tysonjh Sep 13 '13 at 14:41