RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1815047 - profile.sh misdetects login shell
Summary: profile.sh misdetects login shell
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: environment-modules
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Lukáš Zaoral
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 2128975
TreeView+ depends on / blocked
 
Reported: 2020-03-19 11:34 UTC by Parikshit Khedekar
Modified: 2023-05-16 10:57 UTC (History)
7 users (show)

Fixed In Version: environment-modules-4.5.2-3.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2128975 (view as bug list)
Environment:
Last Closed: 2023-05-16 09:02:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2023:2952 0 None None None 2023-05-16 09:02:36 UTC

Description Parikshit Khedekar 2020-03-19 11:34:50 UTC 
Description of problem:

The modules startup should honor $SHELL to determine the login shell, instead of examining the parent of the currently running process to see what shell it might be.

Code available now,

~~~
if [ -n "${BASH:-}" ]; then
   shell=${BASH##*/}
elif [ -n "${ZSH_NAME:-}" ]; then
   shell=$ZSH_NAME
else
   shell=$(/usr/bin/basename $(/usr/bin/ps -p $$ -ocomm=))
fi

if [ -f /usr/share/Modules/init/$shell ]; then
   . /usr/share/Modules/init/$shell
else
   . /usr/share/Modules/init/sh
fi
~~~

Change Proposed

~~~
if [ -n "$SHELL" ] ; then
   shell=${SHELL##*/}
elif [ -n "${BASH:-}" ]; then
   shell=${BASH##*/}
elif [ -n "${ZSH_NAME:-}" ]; then
   shell=$ZSH_NAME
else
   shell=$(/usr/bin/basename $(/usr/bin/ps -p $ -ocomm=))
fi
~~~



Version-Release number of selected component (if applicable):

/usr/share/Modules/init/profile.sh from the environment-modules-4.1.4-4.el8.x86_64 RPM.


How reproducible:

Always with the parent process is running /bin/sh and the current process is the user process which may well be using a different SHELL setting, like csh.


Steps to Reproduce:
1. Any GRID job which runs as parent process from BASH and the current process is in different shell. 
2.
3.

Actual results:

Determines the shell by assuming bash as default else lands to see the parent process. So fails with CSH.

Expected results:

Should be able to see what shell the user is using and following change of code will help to do it as,

~~~~~

if [ -n "$SHELL" ] ; then
   shell=${SHELL##*/}
elif [ -n "${BASH:-}" ]; then
   shell=${BASH##*/}
elif [ -n "${ZSH_NAME:-}" ]; then
   shell=$ZSH_NAME
else
   shell=$(/usr/bin/basename $(/usr/bin/ps -p $ -ocomm=))
fi

~~~~~

Additional info:
Comment 4 Xavier Delaruelle 2020-12-30 09:33:44 UTC 
SHELL environment variable is unfortunately misleading as it is set by login shell to the value defined for user in passwd, not the value corresponding to the running login shell.

# getent passwd root
root:x:0:0:root:/root:/bin/fish
# sh -l
# echo $SHELL
/bin/fish
# ps -p $$ -ocomm=
sh

In the above example, the default login shell for root account is set to /bin/fish in passwd. However if /bin/sh is started as a login shell, it will set $SHELL to /bin/fish even if it is /bin/sh that is running.

I am interested to get more information on the error you get and what are the steps to reproduce this issue.

/etc/profile.d/modules.sh is evaluated by SH shells. It first tries to determine the current running shell through the current environment setup (testing BASH or ZSH_NAME variables) then if no clue the name of the current process ($$) is fetched.

In the situation you describe, the parent shell /bin/sh will go through /etc/profile then /etc/profile.d/modules.sh will be evaluated to initialize "module" for this shell. Any csh sub-shell from there will go through /etc/csh.cshrc then /etc/profile.d/modules.csh will be evaluated to initialize "module" for this subshell.
Comment 8 Lukáš Zaoral 2022-06-01 14:55:49 UTC 
Hello,
I agree with the concerns raised and demonstrated by Xavier about using the value of the SHELL environment variable to guess the used shell.
Could you please provide a clear description of steps required to reproduce this issue?

Thank you!

Lukas
Comment 13 Xavier Delaruelle 2022-09-15 04:37:24 UTC 
@lzaoral I got clearer information on this issue at https://github.com/cea-hpc/modules/issues/473. It impacts users having a non sh-like login shell running jobs through HPC scheduler like PBS.

I propose a fix on the github ticket that could be easily applied to the EL packages.

Xavier
Comment 14 Lukáš Zaoral 2022-09-15 10:05:01 UTC 
That's perfect Xavier, thank you!  I'll get to it next week.
Comment 22 errata-xmlrpc 2023-05-16 09:02:33 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (environment-modules bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2952
Note You need to log in before you can comment on or make changes to this bug.