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): tcsh-6.10-6 How reproducible: Always Steps to Reproduce: 1. Change your shell to /bin/tcsh 2. Logout 3. Login Actual Results: Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell. Expected Results: No such error message Additional info: 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 Press Ctrl+Alt+F1 Login as a user % su -l Password: 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 somewhere.
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.