Bug 56121
Summary: | tcsh login: Warning: no access to tty (Inappropriate ioctl for device). | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Robert Buffington <redhat> |
Component: | tcsh | Assignee: | Eido Inoue <havill> |
Status: | CLOSED DUPLICATE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | itai.nahshon |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-11-19 22:44:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Robert Buffington
2001-11-13 02:13:12 UTC
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. |