[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SIGTTIN when exec-ing from .profile/.bashrc
From: |
neil . hoggarth |
Subject: |
SIGTTIN when exec-ing from .profile/.bashrc |
Date: |
Fri, 23 Mar 2001 15:47:43 GMT |
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I.
-I. -I./lib -I/usr/include -g -O2
uname output: Linux pc-linus.physiol.ox.ac.uk 2.2.16-3 #1 Mon Jun 19 18:10:14
EDT 2000 i486 unknown
Machine Type: i386-redhat-linux-gnu
Bash Version: 2.03
Patch Level: 8
Release Status: release
Description:
If bash2 is started as a login shell from /bin/login, and .profile or
.bashrc use the exec builtin to replace the shell with another process
then the newly exec-ed process appears to have problems reading from
the terminal - strace shows such a process stuck in a tight loop,
repeatedly processing SIGTTIN.
This affects /bin/bash2 in the Redhat 6.x GNU/Linux distribution, as
well as /bin/sh and /bin/bash on RedHat 7.0 (which are both bash v2).
The problem doesn't manifest itself if bash v1 is used as a login
shell on the same system. It only appears to occur when bash2 is
exec-ed from /bin/login - such as when the login occurs over telnet or
on the console. It doesn't occur when bash2 is the login shell but has
been launched by sshd rather than login.
Repeat-By:
Create a .profile which contains something like "exec tcsh". Make
bash2 the login shell for the account. Attempt to login.
- SIGTTIN when exec-ing from .profile/.bashrc,
neil . hoggarth <=