pseudo terminals in 7.0 - pts implementation
Robert Watson
rwatson at FreeBSD.org
Thu Nov 22 00:16:30 PST 2007
On Sun, 18 Nov 2007, Robert Watson wrote:
> On Sun, 18 Nov 2007, Dan Epure wrote:
>
>> 7.0-BETA3 still has issues regarding the pts implementation . problems
>> found: 1. - GNU screen: starting a screen, opening a few windows and
>> quiting screen leaves the allocated pseudo terminal in use. 100 screen
>> user, using each one opening 10 windows will deplete the default of 1000
>> pseudo terminals leaving the system unusable. 2. - 'ls /dev/ptmx' creates
>> an additional entry in /dev/pty/. when the number of entries equals
>> kern.pts.max the system became unusable.
>
> The first of these is likely a reference management bug of some sort -- I
> find that if I close a pty in screen by exiting the shell, the pts device is
> GC'd properly, but if I close it by killing the session with ctrl-k, then
> the pts device is not properly GC'd and processes hung off it not properly
> killed. I believe that closing the master device is not properly kicking
> the slave device and causing its consumers to exit, hence the pts device not
> being closd and released. Christian was taking a look at this a couple of
> days ago, and I've CC'd him.
>
> The second problem is more tricky, and has to do with the cloning model.
> Similar problems can exist with other variations on the ptmx implementation,
> and I need to give some thought to how to address this.
Dan,
So, thinking a bit more about the second problem, I think it is inherrent to
the way we've designed the /dev/ptmx cloning model, which is unfortunate. My
current leaning is to disable the ptmx mechanism in 7.0 and put together a
revised one for 7.1. The reason to do this is to avoid encoding the
user<->kernel interface for allocating pty's via ptmx along the current lines,
which we'd then need to continue supporting in future releases. I'm going to
spend a bit of time over the next day or two looking at revising the interface
to fix these problems.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-stable
mailing list