H. Peter Anvin [hpa@xxxxxxxxx] wrote: > sukadev@xxxxxxxxxx wrote: >> 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. > > That is correct. So afaics, we don't have any issues when operating only in one mode (single-instance or multi-instance). When both modes are used simultaneously, we have following options: 1. Let container-startup deal with it i.e use above bind-mount approach or, as Serge mentioned, have containers chroot and make ptmx->pts/ptmx symlink or another option ? 2. Have the ptmx-node even in the initial mount and a "permanent" ptmx symlink - Did we fully rule it out :-) 3. Choose #2 with a (yet-another) config token. Not sure if it adds value or further complicates the matrix. Both #1 and #2 have their pros/cons. Long term, one advantage I see with #2 is that we don't force container-scripts do something now that they can/should potentially undo later if we ever want to remove the single-instance semantics. Does presence of /dev/pts/ptmx in single-instance case break userspace ? If it only surprises, will adding notes to pts(4) man page help ? Or are there other options ? Thanks, Suka _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers