strange RHEL 8 bug

[David Barr]

When I log into Linux and type the “env” command, it includes the following lines:

BASH_FUNC_which%%=() { ( alias;
eval ${which_declare} ) | /usr/bin/which –tty-only –read-alias –read-functions –show-tilde –show-dot $@
}

If I restart the host server from the command line, then this environmental setting makes it into the host server process (checked with “ps xeww”):

BASH_FUNC_which%%=() { ( alias;

Now if I restart an engine process from the GUI, and one of the threads in the process tries to call a shell command with “exec sh -c” then the command fails, and I get this error:

[sms :sms :ERR /0: uu_in:11/10/2022 13:54:25] Tcl error:
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] msgId = none
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] proc = ‘tps_david’
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] args = ”
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] result = ‘testing bug with which
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] sh: which: line 1: syntax error: unexpected end of file
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] sh: error importing function definition for `which”
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] errorInfo: ‘
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] testing bug with which
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] sh: which: line 1: syntax error: unexpected end of file
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] sh: error importing function definition for `which’
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] while executing
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] “exec sh -c “echo testing bug with which””
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] (procedure “tps_david” line 30)
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] invoked from within
[sms :sms :ERR /0: uu_in:–/–/—- –:–:–] “tps_david {CONTEXT sms_ib_data} {ARGS {}} {MODE start} {VERSION 3.0}”‘

The workaround is to either start the host server using startup scripts (systemd) or type “unset which” before manually starting the host server. Starting engine processes from the command line doesn’t seem to cause the problem, it’s only when they are started from the host server.

I’ve got a ticket open with Redhat about this because the problem doesn’t seem Cloverleaf specific.

Topic

[David Barr]

I was thinking that this is a Redhat problem, but I’ve changed my mind. It’s a problem with the host server. You can type “hciss -dumpenv” to confirm that the java libraries used by the host server don’t properly capture the BASH_FUNC_which%% variable.

[Rob Lindsey]

I am not sure exactly what is going on but I know that we are able to start the HostServer from the command line and have the IDE and Global Monitor able to start and restart processes without any issues.  We do use the application user of   hci  on RHEL to be able to start and stop the host server.

Rob Lindsey

[David Barr]

The problem doesn’t prevent stopping and starting processes. We don’t use Global Monitor, so I’m not sure if that’s affected.

The problem only happens if your TPS proc calls a bash process either through exec or I assume by opening a pipe. I could probably rewrite my TPS proc not to use bash. I could use exec with the command I’m trying to call. I think I threw “sh -c” in there because I was trying to store the command in a variable so that I could log what I was running and pass the same variable to exec, but I ran into quoting issues. Rewriting the TPS proc would be another potential workaround for us.

I ran a Java decompiler on the host server to see what was causing the bug, and it looks like the host server is executing the “env” command as a subprocess and reading the output of the command to get variable settings. Because of the Redhat change, this won’t work. Cloverleaf should be using System.getenv(). I’ve got a Jira ticket started with R&D.

[Author]

Replies