pseudo terminals in 7.0 - pts implementation

Robert Watson rwatson at
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.


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