From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90)
Description of problem:
With /bin/tcsh defined as the login shell, upon login, the message is
printed on the terminal screen: Warning: no access to tty (Inappropriate
ioctl for device). Thus no job control in this shell.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change your shell to /bin/tcsh
Actual Results: Warning: no access to tty (Inappropriate ioctl for
Thus no job control in this shell.
Expected Results: No such error message
Changing the shell to bash gets rid of the problem which is why I
suspected the problem is with tcsh-6.10-6.
Actually, I've seen the same behavior with Bash when I su to root.
Specifically, the steps to reproduce are:
boot to runlevel 5
Login as a user
% su -l
At this point, bash prints:
"no job control in this shell"
It does not happen on the shell that starts when the normal user logs in. I
don't know if this is because it's a normal user or because its the first log in...
I have additional information related to this bug. It is not consistent.
Sometimes the error comes up and sometimes it doesn't. To add to the fun, it is
inconsistent with the same tty. This system was initially a Dell RedHat 6.2
system upgraded to 7.1 and then to 7.2. The problem manifested itself after the
7.2 upgrade. This problem does not occur on a similar system that started at
RedHat 7.1 upgraded to RedHat 7.2 with the same tcsh package (6.10-6).
I'm having the same problem with a tcsh shell. A possibly useful hint. It began
only after a RH7.1-7.2 upgrade, or on a fresh Rh7.2 install. It almost never
happens with an xterm, but happens a often with rlogin, but subsequent logins.
I'm using automount home dirs and NIS, so maybe there's a race condition there
I see similar problems also with redhat 7.1 and also with bash. I suspect that
it started in 7.1 after upgrading to kernel 2.4.9. I'm guessing that bash users
are not complaining that much (or sis I miss something) because bash does not
lose too much functionality when that happens.
There is something in th tcsh FAQ about using a non compliant include file.
I exclude this because things work OK most of the time. Also, once that I got
a "broken" session it's inherited to other shells that start from it.
I wrote a small program that trays vaious IOCT's and also trying to open
/dev/tty (and fails) my conclusion for now is that it is a kernel problem.
Possibly when a new pty is allocated it has a session that is not 0. Then the
process that dd the open (after it did setsid() properly) is left without a
controling tty (p->tty). from there on all my findings match a process that
has no controlling tty.
I'm going to investigate more in this direction. -- itai
*** This bug has been marked as a duplicate of 54741 ***
I'm happy to tell you that the problem that
I have seen in not in the kernel but in /bin/login.
(part of util-linux). It exists in RedHat 7.2 and also
in a recent update for RedHat 7.1.
I opened a new bug for util-linux.
See new bug# 56551.
IMHO This one (56121) can be closed.