Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Adding set -u to a user's .profile does not allow a them to log in on the graphical console.
Version-Release number of selected component (if applicable):
bash-4.2.46-20.el7_2.x86_64
How reproducible:
Put 'set -u' in .profile file of any user. Logout from the GUI and Try to Login again.
Steps to Reproduce:
1. Login to the GUI of any user.
2. Create .profile in the home directory of that user, write 'set -u' in it and save it.
3. Logout From the GUI.
4. Try to Login again using the same user credentials from the graphical console.
Actual results:
The login fails and the Login Screen appears again.
Expected results:
The Login should be successful and the Gnome Desktop should display for the user.
Additional info:
There is a similar BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1055784
*** Bug 1452538 has been marked as a duplicate of this bug. ***
Comment 3Siteshwar Vashisht
2017-05-19 10:59:48 UTC
I believe it is caused by a gdm script that is using unset variables. Reassigning to gdm component for further investigation.
Comment 4Ray Strode [halfline]
2017-05-22 15:18:50 UTC
No, couldn't be GDM. The GDM scripts don't run after ~/.profile.
More likely a problem with one or more of the scripts stuffed in /etc/profile.d ?
bug 1055784 mentioned in comment 0 is probably a hint for at least one of the problems, but maybe bash could avoid whack-a-mole fixes by bracketing the source lines in /etc/profile like
+ saved_set="echo -n $- | grep u"
+ [ -n "$saved_set" ] && set +u
for i in /etc/profile.d/*.sh ; do
…
done
+ [ -n "$saved_set" ] && set-u
(or equivalent, there may be a more )
On the other hand, I don't think there is a general expectation that arbitrary changes to ~/.profile will keep a functional system. There are many other settings and commands that could be put in ~/.profile that have the ability to break the login process. ~/.profile is complicated because it's used for both configuration, and scripting. Since it's a shell script it can clearly contain things we don't support.
Regardless, moving back to the bash component to figure out if this is
1) WONTFIX
2) something like the above proposed change to /etc/profile
or
3) needs to be cloned against each problem script in /etc/profile.d
Comment 6Siteshwar Vashisht
2017-05-24 08:51:07 UTC
I am able to login to terminal without any issues with 'set -u' in my .profile, so I thought it would be an issue with one of the gdm scripts. I will try to debug it further.
Comment 8Siteshwar Vashisht
2017-05-24 09:07:19 UTC
It looks like an issue with /etc/X11/xinit/xinitrc-common script.
Steps to reproduce :
1. Add 'set -u' in user's $HOME/.profile
2. Login as same user in runlevel 3
3. Execute startx. Below errors appears on stdout :
/etc/X11/xinit/xinitrc-common: line 46: XKB_IN_USE: unbound variable
Reassigning to xorg-x11-xinit component.
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, 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-2018:0713