After the slave end is used (open(), read(), write(), close()), the master's read() finishes and returns with an EIO error. But I was expecting to be able to open()/close() multiple times the slave end without disrupting the master fd.
Is it possible to keep the two ends valid after the slave's close()? How can I keep my "master" program running when the slave end is closed? Am I supposed to re-run to entire grantpt(); unlockpt(); ptsname(); sequence?
Short: no
Long: a pseudo-terminal slave connection is one end of a connection, like a pipe. Both are ways that data is passed back and forth between user processes through the kernel.
Once one end is closed, you lose the connection. The ptsname description in POSIX says:
Upon failure,
ptsname()shall return a null pointer. This could occur if fildes is an invalid file descriptor or if the slave device name does not exist in the file system.
Once you close a file descriptor, it is invalid.
If you want to reuse a connection, you could do some workaround such as passing the open slave file descriptor to a newly-created process, e.g., from a server application which you write to manage the slave file descriptors.
Further reading:
close - close a file descriptor (POSIX)grantpt - grant access to the slave pseudo-terminal device (POSIX)pipe - create an interprocess channel (POSIX)ptsname - get name of the slave pseudo-terminal device (POSIX)unlockpt - unlock a pseudo-terminal master/slave pair (POSIX)The above was written in 2016. A 2022 comment mentions TIOCGPTPEER, which is an ioctl code allowing an application to obtain a new file descriptor:
(since Linux 4.13) Given a file descriptor in fd that refers to a pseudoterminal master, open (with the given open(2)-style flags) and return a new file descriptor that refers to the peer pseudoterminal slave device. This operation can be performed regardless of whether the pathname of the slave device is accessible through the calling process's mount namespace.
(the closed file-descriptor is still invalid).
pty_close() lxr.free-electrons.com/source/drivers/tty/pty.c#L41 closing the slave fd wakes reads and writes with flag TTY_IO_ERROR set, but only writes on the master fd are woken up with the flag TTY_OTHER_CLOSED set. The devpts entry is removed only when closing the master fd. It doesn't look like if the devpts entry should no longer be used, does it? openpty() from the glibc which is able to keep de pty opened even after the slave end is closed. There solution is simple: openpty() opens the slave node so that the process which created the pty can keep it opened as long as necessary, while other processes can use the pty, including closing and reopening it. I didn't check if this is a standard behaviour. Per comment on the other answer: Yes, actually.
When you create the pty pair, have your master end process open the slave end, and keep it open. That way no matter how many clients open and close the slave, its reference count never goes to zero, and it never becomes invalid.
