H. Peter Anvin [hpa@xxxxxxxxx] wrote: > Alan Cox wrote: >> O> We can't, really, because it will open the global ptmx. This is an >>> unfortunate side effect of the backwards-compatibility code. >>> >>> This is also why I don't like the bind mount; the symlink option has the >>> nice property that f*ckups are more obvious. >> It's asking for trouble with existing systems and users that >> upgrade. /dev/ptmx should remain a proper device file for the non >> container case. > > I did say that as being the desired *eventual* goal. > >> Should /dev/ptmx give you a node in the 'master' pty namespace or a node >> in your current containers pty namespace ? > > Well, since there is no "current containers pty namespace" per se, it will > give you a node in the default (initial) pty namespace unless the bind > mount is set up. But that node will not be accessible if there is a newinstance mount without the bind mount ? IOW 1. mount -t devpts -o newinstance lxcpts /dev/pts 2. mount -o bind /dev/pts/ptmx /dev/ptmx If both #1 and #2 or neither happen there is no problem. If #1 is NOT followed by #2, ptys break in new namespace. An open of /dev/ptmx in this case will allocate a pty in the initial namespace, but since #1 is complete, we lookup the pty (/dev/pts/7) in the new namespace and fail. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers