Red Hat Bugzilla – Bug 39237
Shell job control problems in Rawhide 20010503
Last modified: 2016-11-24 09:49:48 EST
I updated my systems from Rawhide 20010310 to Rawhide 20010503, and
now I am having problems with shell job control. The fix may well be
a simple configuration change to my systems, but as yet I have found
no such fix. I would like to know if anyone else can reproduce this
problem on a different installation of Rawhide 20010503.
I listed the "Component" as "kernel", but I don't have any idea which
component is the culprit.
The simplest manifestation of the problem is that job control
(e.g. intr=^C) does not work for shells (either bash or tcsh) started
via login on the text console or via rlogin. I am starting these
shells with no personal .rc file (just the standard system .rc).
After I have started X via /usr/X11R6/bin/startx, I have no problem
with job control on shells started under xterm or emacs.
If I start a bash via text console login or rlogin, job control will
not work. If I then start another bash via /bin/su, I get the msg
bash: no job control in this shell
If I start a tcsh, I get the msg
Warning: no access to tty (Inappropriate ioctl for device).
Thus no job control in this shell.
Another problem that I noticed is that the sh script that starts
StarOffice 5.2 doesn't work (just hangs), but if I start the
StarOffice binary directly, it works fine.
I don't see any of these problems on my Rawhide 20010310 systems. So
far, I have individually tried 20010310 versions of the following RPMS
on my 20010503 systems, so far with no change in the observed
I also tried remaking devices on my 20010503 system via
also without any change in the problem behavior.
One thing that I noticed via strace is that the shells (bash and tcsh)
get ENOTTY (inapropriate ioctl for device) error returns from calls to
ioctl(i, TCGETS, p). This seems to happen both when the
no-job-control problem is present (e.g. text-console on 20010503) and
when it is not (e.g. xterm on 20010503, text-console on 20010310).
I'm wondering if there is something else going on that causes these
errors to be a problem in 20010503.
I'm sure that there is a simple explanation and fix for these
problems, but I'm stumped and would greatly appreciate any clues that
you could provide. If necessary, I'd be happy to provide additional
details about my system configuration (e.g. the set of installed
Can you do me a favour and give the exact kernel version you are using?
(uname -r will tell you)
Perhaps I should have been clearer in the original bug report that the only
reason that I listed "kernel"
as the "Component" is that I don't know which component is causing the problem.
I initially tried to put the free text "component unknown" in the "Component
text" field, but that produced an error when I submitted
I am running kernel version 2.4.3-2.14.10 on my Rawhide 20010503 systems.
I am using the .i586.rpm on a PII and the .i686.rpm on a PIII,
and I see the same job-control problem on both systems. I also tried running
kernel-2.4.3-2.14.14.i386.rpm on the same 20010503 systems, with no change in
the job-control problem.
The Rawhide 20010503 release seems to have a complete set of 2.4.3-2.14.10
kernels and an incomplete
set of 2.4.3-2.14.14 kernels.
I am NOT seeing this problem on my Rawhide 20010310 systems, which are running
I tried this 2.4.2-0.1.25 kernel on my 20010503 systems, and still saw the
job-control problem. This
definitely suggests that the problem is NOT the kernel itself, but perhaps an
interaction between some
library or utility component and the kernel.
There has been a slight change in the kernel where on fork() the child is
now executed first; we were considering backing that out and this bugreport
convinces me that we really should. That it works in X is strange.
The other thing we changed recently was to increase the number of pty's from 256
to 2048, although I fail to see how that could break stuff.
> There has been a slight change in the kernel where on fork() the child is
> now executed first; we were considering backing that out and this bugreport
> convinces me that we really should. That it works in X is strange.
> The other thing we changed recently was to increase the number of pty's from
> to 2048, although I fail to see how that could break stuff.
Interesting. Can you reproduce the problem I'm seeing (no ^C on text console)
on any of your systems?
Did either of the two kernel changes you mentioned go in between 2.4.2-0.1.25
Were there any non-kernel changes that went along with these changes? I still
can't figure out why
I don't see the job-control problem with 2.4.2-0.1.25 kernel and the other RPMs
but I do see the job-control problem with the same 2.4.2-0.1.25 kernel and the
other RPMs from
I know very little about the details of pty's and tty's, but one thing I noticed
on my systems is that after
running the /dev/MAKEDEV script from the latest MAKEDEV-3.1.0-15 RPM, and
"console", "tty", and "pty" devices, I now have only 256 /dev/pty* device files
and 2593 /dev/tty* device files.
Was "/dev/MAKEDEV pty" supposed to have created 2048 /dev/pty* device files?
The changes went in in the 2.4.3 series. If you see this with 2.4.2 kernels
as well, it doesn't look like a kernel problem. I'll assign the bug to glibc
as that would be component that could cause this for both bash and tcsh.
Jakub: feel free to assign the bug back if you think glibc has nothing to do
What is surprising to me about the problem I'm seeing is that it doesn't seem to
be specific to a
single RPM. To clarify what I wrote in the original bug report, I have two sets
of systems: those running
pure Rawhide 20010310, which all do NOT have the job-control problem, and those
Rawhide 20010503, which all do have the the job-control problem.
The pure Rawhide 20010503 systems are running:
I would expect that if you ran this set of RPMs on a system in your lab, you
have no job control on a text-console shell. If you can't reproduce the problem
in this way,
then either the problem is in some other RPM, or there
is something strange about the way that I have configured my systems.
The pure Rawhide 20010310 systems are running:
So far, I have tried some simple RPM-replacement experiments on my pure Rawhide
For each of the RPMs that I listed, one at a time, I tried replacing the
20010503 version with the
20010310 version. Every time, I still saw the job-control problem. So it seems
like multiple RPMs are
involved. What I have NOT yet tried is simultaneously switching multiple RPMs
(e.g. kernel and glibc)
to the 20010310 version.
Just to be clear, modifying my pure Rawhide 20010503 system to use the
version of glibc-* did NOT make the job-control problem go away. So it doesn't
seem to be purely
a glibc problem.
The complete list of RPMs on my pure Rawhide 20010503 systems is as follows:
This is a duplicate of Bug 36839. The problem is a regression in /bin/login
sometime between util-linux-2.10s-8 and util-linux-2.11a-4.
*** This bug has been marked as a duplicate of 36839 ***