I noticed serious problem with PTS alocation on kernels 2.6.4 and 2.6.5:
It seems that once alocated /dev/pts entries are never reused, leading to
pty alocation errors. The testing system is fully compiled with kernel 2.2.x
headers (including glibc), but informations from my coleagues using systems
compiled on 2.4/2.6 headers seems to behave similarily.
The testcase and used kernel configuration are shown below.
Kernel 2.6.3 does not have this problem.
Is it bug or feature (and I am doing sth wrong) ?
NOTE: I realize that my glibc does not support minors > 255, so no more pts-es
is available, but problem is leakage of _free_ pts-es.
[ankry@green SPECS]$ for a in $(seq 4);do ssh -t remote tty;done
/dev/pts/253
Connection to remote closed.
/dev/pts/254
Connection to remote closed.
/dev/pts/255
Connection to remote closed.
not a tty
Connection to remote closed.
[ankry@green SPECS]$ ssh remote cat /proc/sys/kernel/pty/{max,nr}
2048
1
$ ssh olimp ls /dev/pts
1
.config tested (selected entries)
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=2048
or
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
(full .config available on request)
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Gdansk University of Technology
Andrzej Krzysztofowicz <[email protected]> wrote:
>
> I noticed serious problem with PTS alocation on kernels 2.6.4 and 2.6.5:
> It seems that once alocated /dev/pts entries are never reused, leading to
> pty alocation errors. The testing system is fully compiled with kernel 2.2.x
> headers (including glibc), but informations from my coleagues using systems
> compiled on 2.4/2.6 headers seems to behave similarily.
> The testcase and used kernel configuration are shown below.
> Kernel 2.6.3 does not have this problem.
> Is it bug or feature (and I am doing sth wrong) ?
You need a glibc upgrade - we broke things for really old glibc's. We're
(slowly) working on fixing it up.
Andrew Morton wrote:
>
> Andrzej Krzysztofowicz <[email protected]> wrote:
> >
> > I noticed serious problem with PTS alocation on kernels 2.6.4 and 2.6.5:
> > It seems that once alocated /dev/pts entries are never reused, leading to
> > pty alocation errors. The testing system is fully compiled with kernel 2.2.x
> > headers (including glibc), but informations from my coleagues using systems
> > compiled on 2.4/2.6 headers seems to behave similarily.
> > The testcase and used kernel configuration are shown below.
> > Kernel 2.6.3 does not have this problem.
> > Is it bug or feature (and I am doing sth wrong) ?
>
> You need a glibc upgrade - we broke things for really old glibc's. We're
> (slowly) working on fixing it up.
Hmmm, which version is enough ?
I use glibc-2.2.5, but people using glibc-2.3.3 snapshot, dated 20040101
also have the same problem...
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Gdansk University of Technology
Andrew Morton wrote:
> You need a glibc upgrade - we broke things for really old glibc's. We're
> (slowly) working on fixing it up.
Looking at patch-2.6.4, there are plenty of minor changes to the pty
code but nothing that looks like it would break userspace except for
_very_ old glibcs that don't know about /dev/pts at all and just used
the legacy ones.
I have some _non-glibc_ pty code that I wish to keep working. Can you
briefly explain how it breaks with moderately old glibcs such as the
glibc-2.3.3 that's said to be inadequate, and therefore what interface
change is needed in non-glibc code?
Thanks,
-- Jamie
Jamie Lokier <[email protected]> wrote:
>
> Andrew Morton wrote:
> > You need a glibc upgrade - we broke things for really old glibc's. We're
> > (slowly) working on fixing it up.
>
> Looking at patch-2.6.4, there are plenty of minor changes to the pty
> code but nothing that looks like it would break userspace except for
> _very_ old glibcs that don't know about /dev/pts at all and just used
> the legacy ones.
>
> I have some _non-glibc_ pty code that I wish to keep working. Can you
> briefly explain how it breaks with moderately old glibcs such as the
> glibc-2.3.3 that's said to be inadequate, and therefore what interface
> change is needed in non-glibc code?
>
Andrzej is using a glibc that "does not support minors > 255".
The oldest glibc I have around here is glibc-2.2.5-34 and it passes
Andrzej's `for a in $(seq 4);do ssh -t remote tty;done' test OK. I do not
know at which version they started to permit larger values for minors, but
it must have been some time ago.
A small number of people are hurting from the removal of first-fit pty
allocation and I do think it needs to be put back. I have a patch but
neither Peter nor I have actually tested it yet. I'll aim to get it into
2.6.6.