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 1344007 - /etc/profile.d scripts should have a way to override settings
Summary: /etc/profile.d scripts should have a way to override settings
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: setup
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: Alois Mahdal
Lenka Špačková
Depends On:
Blocks: 1400961 1420851 1465906 1465925 1472751
TreeView+ depends on / blocked
Reported: 2016-06-08 13:29 UTC by Paulo Andrade
Modified: 2019-11-14 08:19 UTC (History)
4 users (show)

Fixed In Version: setup-2.8.71-8.el7
Doc Type: Enhancement
Doc Text:
The _setup_ package now provides a way to override unpredictable environment settings The _setup_ package now provides and sources the `sh.local` and `csh.local` files for overrides of environment variables from the `/etc/profile.d` directory, which is sourced last. Previously, an undefined order could result in unpredictable environment settings, especially when multiple scripts changed the same environment variable.
Clone Of:
Last Closed: 2018-04-10 18:51:06 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1015 0 None None None 2018-04-10 18:51:24 UTC

Description Paulo Andrade 2016-06-08 13:29:40 UTC
The issue with %config should be reported to
packages that own the files. One example is
grep, that defaults to --color=auto. This does
not work for example with wyse terminals.

  The issue of defined sort order would be to
have filenames there starting with a number,
so that one could override settings from a
previous file with a local one.

  One alternative, to not need to modify several
packages to use a defined pattern could be to
create a new /etc/profile.d/sh.local file,
that would be the placeholder to override
settings done by other /etc/profile.d/*.sh
and then, just call this script from /etc/profile
after all *.sh ones.

One example for testing wyse environment is
to use https://github.com/gutschke/wy60.
$ ./wy60
$ ls | grep README

Comment 2 Ondrej Vasik 2016-06-09 06:02:14 UTC
I think the summary is a bit confusing here. /etc/profile.d is a directory, so this definitely shouldn't be marked as %config.

But if I get it right, you propose to have this tracking bz - and check all existing profile.d scripts for %config macro. In addition, you propose to have defined order of the profile.d scripts execution. As you can see in https://git.fedorahosted.org/cgit/setup.git/tree/profile on line 65, this can be easily solved by modifying "for i in /etc/profile.d/*.sh ; do" with "for i in $(ls /etc/profile.d/*.sh | sort) ; do" (or something similar with less overhead than ls ;) ) - so you will have defined order of the profile.d scripts sourcing. Of course, having /etc/profile.d/sh.local and source this after all *.sh scripts is another alternative...

Can you confirm this is basically what you expect from this bugzilla ? What solution do you prefer?

Comment 3 Paulo Andrade 2016-06-09 13:08:20 UTC
Yes it would the files in the directory. I think I did not made
if much clear because I did not fully describe implications, of
likely too many packages owning files there.

I think ls | sort may depend on locale, while starting with a
numeric value is unlikely, but would require sort -n.

The idea of sh.local is kind of to match rc.local :) Just have
a placeholder for the user to try to fix or override system
settings, and does not end in .sh to not match the pattern of
the files to be sourced.

Comment 4 Ondrej Vasik 2016-06-09 13:43:25 UTC
ls | sort can be made locale independent with LC_ALL=C (I would do that anyway, as mb path of sort is much slower). However, maybe the sh.local is really better idea. I'm fine with that addition. 

Looking at the repofile from 7.2, there is not that many profile.d scripts shipped by RH (with packages where the files are):

However, I think missing %config option is probably something what you can expect from 3rd party rpms. And I haven't checked these above listed files for it, yet...

Comment 9 Ondrej Vasik 2017-11-17 08:10:21 UTC
Thinking a bit more about the issue, sorting can potentially break existing setups (where it worked by miracle). Therefore for 7.5 going only with adding the sh.local file and running it. It should resolve the issue - as admin would be able to override settings from previous /etc/profile.d scripts.

Comment 12 Alois Mahdal 2018-02-05 14:07:18 UTC
Added test for the new feature and verified by re-running whole test suite.  Looks fine; results as expected.

Comment 15 errata-xmlrpc 2018-04-10 18:51:06 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, and where to find the updated
files, follow the link below.

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


Note You need to log in before you can comment on or make changes to this bug.