On my Archlinux,
/dev/pts is mounted by the devpts, so who created the
/dev/pts/ptmx device node? What's the purpose of this node? it's the same (Major=5 Minor=2) device node same as
/dev/ptmx/, but with different access mode, for what?
The old AT&T System 5 mechanism for pseudo-terminal slave devices was that they were ordinary persistent character device nodes under
/dev. There was a multiplexor master device at
/dev/ptmx. The old 4.3BSD mechanism for pseudo-terminal devices had parallel pairs of ordinary persistent master and slave device nodes under
/dev. These were special device nodes on an ordinary disc filesystem.
On OpenBSD, some of this is still true nowadays.
/dev is still a disc volume, and slave devices are still real on-disc nodes. They are created on demand, however. The kernel internally issues the relevant calls to create new device nodes there when issued a
PTMGET I/O control on the
On FreeBSD, none of this is still true. There isn't even a multiplexor device any more.
/dev is not a disc volume at all. It is a
devfs filesystem. Slave devices appear in the
devfs filesystem under its
pts/ directory in response to the
posix_openpt() system call, which is an outright system call, not a wrapped
ioctl() on an open file descriptor to some "multiplexor" evice.
For a while on Linux, pseudo-terminal slave devices were persistent device nodes. What you are looking at is its "new"
devpts filesystem (where "new" means introduced quite a few years ago, now) in conjunction with
devtmpfs. This almost permits the same way of doing things as on FreeBSD with
But there are some differences. In particular, there is still a "multiplexor" device.
- In the older "new"
devptssystem, this was a
ptmxdevice in a different
devtmpfsfilesystem, with the
devptsfilesystem containing only the automatically created/destroyed slave device files. Conventionally the setup was
/dev/ptmxand an accompanying
- But Linux people wanted to have multiple wholly independent instances of the
devptsfilesystem, for containers and the like, and it turned out to be quite hard synchronizing the (correct) two filesystems when there were many
devptsfilesystems. So in the newer "new"
devptssystem all of the devices, multiplexor and slave, are in the one filesystem.
For backwards compatibility, the default was for the new
ptmxnode to be inaccessible unless one set a new
ptmxmodemount option. In backwards compatibility mode one could still run things the older single-instance way, and one did by default unless one used an explicit
newinstanceoption when mounting a
- In the even newer still "new"
devpts(that has been around since 2016) the per-instance multiplexor device in the
devptsfilesystem is now the primary multiplexor, and the
devtmpfsis a shim provided by the kernel that tries to mimic a symbolic link, a bind mount, or a plain old actual symbolic link to
pts/ptmx. The multiple-instance way is now the only way.
- What would be the best way to work around this glibc problem?
Documentation/filesystems/devpts.txt. Linux kernel.
- Daniel Berrange (2009-05-20).
/dev/ptsmust use the 'newinstance' mount flag to avoid security problem with containers. Red Hat bug #501718.
- Eric W. Biederman (2015-12-11). devpts: Sensible /dev/ptmx & force newinstance. Linux kernel mailing list.
- Eric W. Biederman (2016-04-08). devpts: Teach /dev/ptmx to find the associated devpts via path lookup. Linux kernel mailing list.