Bug 433283 - /etc/profile.d/script
/etc/profile.d/script
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh (Show other bugs)
5.1
i386 Linux
low Severity high
: rc
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-18 06:51 EST by Per Lindahl
Modified: 2008-02-25 04:38 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-18 07:13:58 EST
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 Per Lindahl 2008-02-18 06:51:51 EST
Description of problem:
On all our test servers running Redhat EL we have a script that gets executed
upon login to warn if the system is in use and currently running tests.

This script echo's a warning to all users login in including root and this works
flawlessly on all the other systems not running RHEL 3u9, 4.6 and 5u1. Since we
distribute our maintenance scripts via scp and that output interrupts the scp
transfer without the files being copied this is a major problem.  

Version-Release number of selected component (if applicable):
RHEL 3u9, 4u6 and 5.1 on ia32, x86_64 and ia64

How reproducible:
Every time

Steps to Reproduce:
1.create a script that does "cat /etc/fstab | tail -n 3"
2.put it in /etc/profile.d/testscript.sh ; chmod a+x /etc/profile.d/testscript.sh
3. logout from the system and login again if it runs and give you any output on
the screen then logout and try to scp a file to the system. It'll fail. The next
time you login you'll see that the file has not been copied 

rsync also fails when doing it over ssh
  
Actual results:
The file one tried to copy doesn't exist on the target system

Expected results:
That the file can be found on the target system.

Additional info:
Comment 1 Tomas Mraz 2008-02-18 07:13:58 EST
This is not a bug. You shouldn't print anything in profile.d script when the
shell is non-interactive. You can use for example the following code to test
whether the shell is interactive or not.

#!/bin/sh
if [ ! -z "$PS1" ] ; then
echo "You are running an interactive shell!"
fi
Comment 2 Johan Walles 2008-02-25 03:47:59 EST
(In reply to comment #1)
> You shouldn't print anything in profile.d script when the
> shell is non-interactive.

Tomas, that seems to make sense, but is it documented anywhere?

I have been looking, but I haven't found any documentation saying that profile.d
scripts shouldn't print stuff in non-interactive shells.
Comment 3 Tomas Mraz 2008-02-25 04:38:14 EST
I don't know whether it is explicitely mentioned somewhere but it seems logical
that non-interactive shells should not print anything themselves. When you do
for example 'ssh user@host ls' it will run the ls in non-interactive shell which
means that things printed from profile.d scripts would be concatenated with the
ls output. Even from the definition of the non-interactivity it seems logical to
not put any messages from the shell/profile scripts itself to output as they
won't be possibly getting to the user anyway.

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