Bug 165873 - shopt -q login_shell in /etc/bashrc fails, blocks scp
Summary: shopt -q login_shell in /etc/bashrc fails, blocks scp
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-13 06:01 UTC by Wayne Pollock
Modified: 2014-03-17 02:55 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2005-10-17 19:56:18 UTC

Attachments (Terms of Use)

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
   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):

How reproducible:

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

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

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