Bug 165873

Summary: shopt -q login_shell in /etc/bashrc fails, blocks scp
Product: [Fedora] Fedora Reporter: Wayne Pollock <pollock>
Component: setupAssignee: Bill Nottingham <notting>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 4CC: rvokal, steve
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-17 19:56:18 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 Wayne Pollock 2005-08-13 06:01:55 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
otherhost$ scp file fc4-host:.
This just hangs, although ssh, sftp do work, and the
reverse direction (fc4-host to otherhost) works.
[FC4 has openssh-4.1p1-3.1]

openssh.com FAQ #2.9 let me to the problem: /etc/bashrc
is running all the profile.d/*.sh scripts even though
this is a non-interactive session. The culprit is this
line:
   if ! shopt -q login_shell ; then # We're not a login shell
My older FC2 system used a different test:
   if [ "x$SHLVL" != "x1" ]; then # We're not a login shell
After commenting out the original test and substituting this
one, everything is now working.

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

How reproducible:
Always

Steps to Reproduce:
1.otherhost$ scp file fc4-host:.
2.
3.
  

Actual Results:  Session just hangs (scp -v flag shows keep-alives and that is all)

Expected Results:  File "file" should be transferred to fc4-host.  (After authentication,
if keys aren't used.)

Additional info:

The test from openssh.com to show the problem was to try:
   otherhost$ ssh fc4-host /bin/true
and check for any output (there should be none, but a blank
line is produced.  I didn't bother checking the scripts
in /etc/profile.d/*.sh to see which one did that, as none of
those scripts should run at all in this case!)
Comment 1 Tim Waugh 2005-08-15 08:46:09 UTC 
Fixing component. (/etc/bashrc is owned by the 'setup' package.)
Comment 2 Steve Stavropoulos 2005-10-15 15:13:46 UTC 
The bug isn't in /etc/bashrc, but in one of the /etc/profile.d/*.sh files. If
the session is a login session then /etc/profile is run which runs all
/etc/profile.d/*.sh scripts. If the session is not a login session (that means
/etc/profile won't run) then /etc/bashrc should run the /etc/profile.d/*.sh
scripts. Bottomline is that the /etc/profile.d/*.sh should run in all cases.
 I suggest that the reporter of this bug finds the offending script and reports
the bug to the respecting package. As for this bug, IMO it should be marked as
NOTABUG.