Bug 165873 - shopt -q login_shell in /etc/bashrc fails, blocks scp
shopt -q login_shell in /etc/bashrc fails, blocks scp
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-13 02:01 EDT by Wayne Pollock
Modified: 2014-03-16 22:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-17 15:56:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Wayne Pollock 2005-08-13 02:01:55 EDT
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 04:46:09 EDT
Fixing component. (/etc/bashrc is owned by the 'setup' package.)
Comment 2 Steve Stavropoulos 2005-10-15 11:13:46 EDT
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.

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