Bug 805507

Summary:	/etc/profile hides errors of /etc/profile.d/*.sh
Product:	[Fedora] Fedora	Reporter:	Michal Schmidt <mschmidt>
Component:	setup	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	16	CC:	bobgus, ovasik, pknirsch
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	805254	Environment:
Last Closed:	2012-03-22 09:56:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michal Schmidt 2012-03-21 13:56:21 UTC

+++ This bug was initially created as a clone of Bug #805254 +++

--- Additional comment from mschmidt 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 14:39:32 UTC

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 15:14:14 UTC

(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 15:36:29 UTC

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 15:43:03 UTC

bug 457243 and bug 202468 look related.

Comment 5 Ondrej Vasik 2012-03-21 16:00:39 UTC

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-22 00:03:38 UTC

(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 05:55:49 UTC

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 08:58:30 UTC

Fine with me. Thank you.

Comment 9 Ondrej Vasik 2012-03-22 09:56:53 UTC

Built as setup-2.8.51-1.fc18, closing RAWHIDE.