‘can’t read “env(HOSTNAME)”: no such variable’

Clovertech Forums Cloverleaf ‘can’t read “env(HOSTNAME)”: no such variable’

  • Creator
    Topic
  • #119625
    Erik Mueller
    Participant

      Good morning,

       

      I am experiencing different behaviour in my Cloverleaf running on a Linux 19.1.x Cluster compared to my Cloverleafs running on Linux 19.1x Standalone server and my Windows 6.1.x Standalone servers.

       

      I have a tcl script that has the following two lines:

      global env

      set servername $env(HOSTNAME)

       

      This tcl script works fine on:

      1. Cloverleaf 19.1.x Standalone Linux
      2. Cloverleaf 6.1 Standalone Windows
      3. hcitcl on the active node of the Cloverleaf 19.1.x Linux Cluster

       

      However, when the my thread on the Cloverleaf 19.1.x Linux Cluster tries to execute the tcl script, I get the following error

      ‘can’t read “env(HOSTNAME)”: no such variable’

      I have also tried the following command:

      set servername “$::env(HOSTNAME)”

      which resulted in this error:

      result = ‘can’t read “::env(HOSTNAME)”: no such variable’

      This command however does work when the thread calls my tcl script

      set servername [info hostname]

      When I execute the following command in hcitcl

      parray env

      I can see the variable “env(HOSTNAME)” in the output but when I add “parray env” to my tcl script, I do not see “env(HOSTNAME)” in the process log which explains my tcl error.

       

      Can anybody shed some light on why the env(HOSTNAME) is not defined when my thread calls the tcl script on my Cloverleaf 19.1.x Linux cluster but is defined on the other Cloverleaf servers and is defined when running hcitcl?

      Thanks,

      Erik

       

      • This topic was modified 2 years, 9 months ago by Erik Mueller.
    Viewing 0 reply threads
    • Author
      Replies
      • #119628
        David Barr
        Participant

          “env” is an array that’s automatically set from the environmental variables of the process. If $env(HOSTNAME) is not set, that means the engine process doesn’t have that environmental variable.  Processes inherit their environment from the process they were started from. If you have $HOSTNAME set in your shell, and you use the “hcienginerun” command to start your process, then it will have HOSTNAME set. My guess is that your process in the cluster is being started by the system startup scripts and they don’t have $HOSTNAME set.

          On my linux system, there’s a line in /etc/profile that sets the hostname variable:

          HOSTNAME=/usr/bin/hostname 2>/dev/null

          I would make sure that line is in there.  Reading that file could also be related to the login shell that you’re using for your hci account. We’re using bash, and if you’re using sh or ksh, that could be related to the problem.

          If you just want a simple way of fixing the hostname issue in scripts and you don’t care about fixing the rest of the environment issues, you could replace “$::env(HOSTNAME)” in your scripts with “[info hostname]”. This should have the same effect but doesn’t depend on environmental variables.

          • #119629
            Erik Mueller
            Participant

              Hi,

              Thanks very much for your reply.

               

              I have checked  /etc/profile and it also has the line:

              HOSTNAME=/usr/bin/hostname 2>/dev/null

              Perhaps the issue is that the Cloverleaf Service is running at a Cluster Resource?

              I will update my tcl scripts to use “[info hostname]”

              Thanks again,

              Erik

            • #119795
              Erik Mueller
              Participant

                Hi,

                 

                I have more unusual behaviour that has confused me.

                 

                Now on my standalone Linux server, I am getting this error

                [pd :pdtd:ERR /0:AuditArchitecture:06/11/2022 00:00:00] Tcl error:
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] msgId = none
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] proc = ‘AuditArchitecture’
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] args = ”
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] result = ‘can’t read “env(HOSTNAME)”: no such variable’
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] errorInfo: ‘
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] no such variable
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] (read trace on “env(HOSTNAME)”)
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] invoked from within
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] “set servername $env(HOSTNAME)”
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] (procedure “getSiteListRouteData” line 15)
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] invoked from within
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] “getSiteListRouteData”
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] (procedure “AuditArchitecture” line 25)
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] invoked from within
                [pd :pdtd:ERR /0:AuditArchitecture:–/–/—- –:–:–] “AuditArchitecture {CONTEXT pdupoc_read} {ARGS {}} {MODE time} {VERSION 3.0}”‘

                Strangely, when I run it from hcitcl, [info hostname] returns “localhost”

                hcitcl>set servername “$::env(HOSTNAME)”
                uksalqapcl01
                hcitcl>set servername $env(HOSTNAME)
                uksalqapcl01
                hcitcl>set servername [info hostname]
                localhost
                hcitcl>

                 

                Something must have changed as this was working for months and I’ve not made any changes to any of my scripts.

                 

                Any ideas?

                Thanks,

                Erik

              • #119808
                Erik Mueller
                Participant

                  Hi,

                  When I executed hostname -f on the Linux prompt, it returned “localhost”.

                  It seems the issue was that the IP address and Hostname were not in the /etc/hosts file on the Linux server.

                  Once that was added it worked from the Linux prompt and when the thread executed the script.

                   

                  Erik

            Viewing 0 reply threads
            • You must be logged in to reply to this topic.