Bug 805507 - /etc/profile hides errors of /etc/profile.d/*.sh
/etc/profile hides errors of /etc/profile.d/*.sh
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
16
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-21 09:56 EDT by Michal Schmidt
Modified: 2012-03-22 05:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 805254
Environment:
Last Closed: 2012-03-22 05:56:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2012-03-21 09:56:21 EDT
+++ This bug was initially created as a clone of Bug #805254 +++

--- Additional comment from mschmidt@redhat.com on 2012-03-21 09:53:19 EDT ---

Good to know. To summarize the problem:
1) /etc/X11/prefdm executes /usr/sbin/gdm
2) /usr/sbin/gdm is a shell script running in POSIX mode (it has #!/bin/sh)
3) /usr/sbin/gdm sources /etc/profile
4) /etc/profile sources /etc/profile.d/rvm.sh
5) rvm.sh depends on non-POSIX bash functionality, so a syntax error is hit.

The whole thing quits with error code 2.

I see at least 2 issues that made this problem needlessly difficult to debug:
 - /etc/X11/prefdm executes the display manager with ">/dev/null 2>&1",
   thus hiding the error messages.
 - /etc/profile sources the files /etc/profile.d/*.sh with:
   . "$i" >/dev/null 2>&1
   again hiding the error messages.
Comment 1 Ondrej Vasik 2012-03-21 10:39:32 EDT
This is not really true, it hides errors only for the case of noninteractive login. For interactive logins the errors are shown. This is necessary for e.g. ssh logins (these could be quite wordy without these redirections).
If you have some idea for improvement, feel free to propose an adjustment. Otherwise I will have to close this not a bug, as this redirection is required.
Comment 2 Michal Schmidt 2012-03-21 11:14:14 EDT
(In reply to comment #1)
> This is necessary for e.g. ssh logins (these could be quite wordy without
> these redirections).

I fail to see the problem. Could you give me an example of what a wordy login is?
Comment 3 Ondrej Vasik 2012-03-21 11:36:29 EDT
I'll try to find the original bugzilla number with the request for disabling info from profile.d scripts for noninteractive logins.
Comment 4 Michal Schmidt 2012-03-21 11:43:03 EDT
bug 457243 and bug 202468 look related.
Comment 5 Ondrej Vasik 2012-03-21 12:00:39 EDT
Yep, these are both the similar cases for tcsh... reasoning with less will be the same even in bash, but I can't find the related bash (/etc/profile) bugzilla.

I probably did that together with tcsh fix by http://git.fedorahosted.org/git/?p=setup.git;a=commitdiff;h=722b1261607fb28328c708d45a39e8786139aa70 as the #202468 caused a regression #464788 and it was necessary to fix it somehow. Reverting them doesn't seem to be a good idea, but probably it should be possible to see debug output even for noninteractive mode via some envvar or something.
Comment 6 Michal Schmidt 2012-03-21 20:03:38 EDT
(In reply to comment #5)
> Yep, these are both the similar cases for tcsh... reasoning with less will be
> the same even in bash, but I can't find the related bash (/etc/profile)
> bugzilla.

I have doubts whether bash was ever affected by the less problem (bug 202468). When bash is running as non-login and non-interactive, to run a shell script (such as when spawned from popen(3): "/bin/sh -c command"), it does not run /etc/profile.
This is different from tcsh, because tcsh runs /etc/csh.cshrc even if run as "tcsh -c command".

Furthermore, even if we suppose there is some good reason for suppressing stdout, it does not follow that stderr ought to be suppressed as well.
Comment 7 Ondrej Vasik 2012-03-22 01:55:49 EDT
Fair enough... suppressing stdout only seems to be a compromise.

I'll change it in next rawhide build. Given the fact that it was suppressed in Fedora more than 3 years without complains and the main benefit here is debugging of the failures I think that waiting for possible future setup bugfix with rawhide only update should be ok. Are you ok with closing RAWHIDE after rawhide fix (no F16/F17 update ?) ?
Comment 8 Michal Schmidt 2012-03-22 04:58:30 EDT
Fine with me. Thank you.
Comment 9 Ondrej Vasik 2012-03-22 05:56:53 EDT
Built as setup-2.8.51-1.fc18, closing RAWHIDE.

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