On desktop workspaces, our runonce scripts are currently not executed when logging in via the desktop, and then opening a terminal (everything is fine when logging in via ssh). This means for instance that pyenv is not automatically available on the Python Workbench Desktop catalog item.
After investigation, it turns out the cause is the following:
Our runonce.sh script is called by /etc/profile if and only if the user has a login shell
When logging in via xrdp (so also via Guacamole), a login shell is started with the /etc/xrdp/startwm.sh script. This script will thus trigger /etc/profile and thereby runonce.sh
But the shell started by xrdp is not an interactive shell (after all, the user has started a graphical session, and has not attached a terminal). So runonce.sh does not detect $PS1, and therefore does not execute its logic.
Possible solutions:
don't check for $PS1 in runonce.sh
set the default terminal application in the desktop environment to be a login shell by default
start a terminal application with a login shell as a startup application in the desktop environment
On desktop workspaces, our runonce scripts are currently not executed when logging in via the desktop, and then opening a terminal (everything is fine when logging in via
ssh
). This means for instance thatpyenv
is not automatically available on the Python Workbench Desktop catalog item.After investigation, it turns out the cause is the following:
runonce.sh
script is called by/etc/profile
if and only if the user has a login shellrunonce.sh
checks additionally whether the shell is an interactive shell by checking for the presence of$PS1
xrdp
(so also via Guacamole), a login shell is started with the/etc/xrdp/startwm.sh
script. This script will thus trigger/etc/profile
and therebyrunonce.sh
xrdp
is not an interactive shell (after all, the user has started a graphical session, and has not attached a terminal). Sorunonce.sh
does not detect$PS1
, and therefore does not execute its logic.Possible solutions:
$PS1
inrunonce.sh