Environment variable LOG_DIR not respected in server.xml

[k8vance88]

@msmigiel commented on Wed May 08 2019

I'm running Open Liberty 19.0.0.4 on Windows 10 and am seeing an odd issue.

In my server.xml, I have a section for logging as follows:

<logging hideMessage="SRVE9967W, CWWKO0221E" maxFileSize="64" consoleLogLevel="INFO" logDirectory="${env.LOG_DIR}" messageFileName="${env.MESSAGE_FILE}" traceFileName="${env.TRACE_FILE}" traceSpecification="" />

In my batch script to start Liberty, I define the variables as:
set LOG_DIR=%USER_HOME%\logs
set LOG_FILE=%JVM%_%COMPUTERNAME%_%CURRENT_DATE%.log
set MESSAGE_FILE=%JVM%_%COMPUTERNAME%_%CURRENT_DATE%.log
set TRACE_FILE=%JVM%_trace_%COMPUTERNAME%_%CURRENT_DATE%.log

I am not using a bootstrap.properties. When I start Liberty with the above, I see that a folder called "${env.LOG_DIR}" is created in my Liberty server's folder (usr\servers\defaultServer) and has the properly named message and trace files. The problem is that logDirectory is not using the variable I pass to it as a variable but rather a file name. As a workaround, if I add the following to my script:

set LOG_PATH=%LOG_DIR%

and change to the following in server.xml:

logDirectory="${env.LOG_PATH}"

it works. I can't figure out why LOG_DIR doesn't work but LOG_PATH does. According to what I've read, this is the proper way to use environment variables and LOG_DIR is one used by the Liberty script itself.

[scottkurz]

Seems related to the doc issue I opened: OpenLiberty/docs#6391

[jimblye]

Can this issue just be closed/cancelled, since we are are unsetting LOG_DIR on purpose? Working as Designed? Then document in OpenLiberty/docs#6391 that the LOG_DIR is unset by the server script and that if an application needs the value of LOG_DIR, they should save that in another variable in server.env.
This doesn't seem like something we are going to change/fix.

server script

  // Unset set/tested variables to prevent collisions with nested process invocations
  if [ -z "$LOG_DIR" ]
  then
    X_LOG_DIR=${SERVER_OUTPUT_DIR}/logs
  else
    X_LOG_DIR=${LOG_DIR}
    unset LOG_DIR
  fi

[jimblye]

It was decided to stop unsetting LOG_DIR.

I found that we unset other variables as well:

• PID_FILE (unix, IBM-I)
• PID_DIR (unix, IBM-I)
• LOG_FILE
• LOG_DIR

These are documented here.

The comment in the "server" script is this:
.# Unset set/tested variables to prevent collisions with nested process invocations

Similar comment in Windows server.bat:
@Rem Unset these variables to prevent collisions with nested process invocations
set LOG_DIR=
set LOG_FILE=

Internally we reassign these variables to new variables with an "X_" prefixed to the variable names; eg. X_LOG_DIR.

In the PR, I only removed the unset of the LOG_DIR variable, since that is all that was asked for.