This is on a home Linux system, so there is only one user (me) and I have >root, so there is no issue with access.
I've noticed, on one particular machine, that sometimes there will be a
file, say /dev/pts/6, in /dev/pts, but there is no process running on that >device and nobody has it open. My understanding is that the file should be >purged when the last process that had it open closes it (or exits).
This is on a home Linux system, so there is only one user (me) and I have >root, so there is no issue with access.
This is on a home Linux system, so there is only one user (me) and I have root, so there is no issue with access.
I've noticed, on one particular machine, that sometimes there will be a
file, say /dev/pts/6, in /dev/pts, but there is no process running on that device and nobody has it open. My understanding is that the file should be purged when the last process that had it open closes it (or exits).
I verify that nobody has it open by doing: sudo fuser /dev/pts/6
and it reports nothing. My general guess as to the problem is that the process that had it open exited, but whatever background process is responsible for cleaning up /dev/pts didn't notice. Note also that I
cannot remove the file manually (even as root!)
The effect of this is that that pts is basically "lost", until the next reboot. I want to know a) How/why this happens and b) If there is anything
I can do to get it back.
gazelle@shell.xmission.com (Kenny McCormack) writes:
This is on a home Linux system, so there is only one user (me) and I have >>root, so there is no issue with access.
I've noticed, on one particular machine, that sometimes there will be a >>file, say /dev/pts/6, in /dev/pts, but there is no process running on that >>device and nobody has it open. My understanding is that the file should be >>purged when the last process that had it open closes it (or exits).
It's not a file, per-se.
/dev/pts is managed by the 'ptsfs' filesystem.
$ mount | grep pts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
There is likely a reference to the pty somewhere; try using the 'w' command.
We use thousands of pty's every day with no leakage issues.
The /dev/pts file is removed when all file descriptors on either end of
the pty are closed.
Richard Kettlewell <invalid@invalid.invalid> wrote:
...
The /dev/pts file is removed when all file descriptors on either end of
the pty are closed.
Yes, that is what is SUPPOSED TO HAPPEN.
But is isn't (always). fuser and lsof both say noone has it open.
Richard Kettlewell <invalid@invalid.invalid> wrote:
...
The /dev/pts file is removed when all file descriptors on either end of >>>the pty are closed.
But is isn't (always). fuser and lsof both say noone has it open.
checking for the other end as well
Richard Kettlewell <invalid@invalid.invalid> wrote:
gazelle@shell.xmission.com (Kenny McCormack) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
...
The /dev/pts file is removed when all file descriptors on either end of >>>>the pty are closed.
But is isn't (always). fuser and lsof both say noone has it open.
checking for the other end as well
OK, I tried a few things, but could not figure out how to check for that.
Any ideas?
Lots of processes have /dev/ptmx open; how to know which one is connected
to /dev/pts/6?
Lots of processes have /dev/ptmx open; how to know which one is connected
to /dev/pts/6?
Le mardi 20 avril 2021, Kenny McCormack a crit:
Lots of processes have /dev/ptmx open; how to know which one is connected
to /dev/pts/6?
For each fd in /proc/$pidmaster/fd/ that points to /dev/ptmx, check the >following (works only on recent kernels):
grep tty-index < /proc/$pidmaster/fdinfo/$fd
Another way to get the information, which is more universal but also is
more difficult to follow, is to make a TIOCGPTN system call on the file >descriptor (from a debugger attached to the process).
grep tty-index < /proc/$pidmaster/fdinfo/$fd
Ah, now we are getting somewhere.
Unfortunately, the system that has the problem is running kernel
4.something and does not have tty-index (in the fdinfo/X file). Other systems here that are runnning kernel 5.something do have it, but "man
proc" doesn't mention it.
I'm guessing that it contains the number of the tty (/dev/pts/X) that this instance of /dev/ptmx is connected to. Is that correct?
Another way to get the information, which is more universal but also is >>more difficult to follow, is to make a TIOCGPTN system call on the file >>descriptor (from a debugger attached to the process).
Well, that sounds interesting. And very complicated...
(And time consuming...)
Another way to get the information, which is more universal but also is >>more difficult to follow, is to make a TIOCGPTN system call on the file >>descriptor (from a debugger attached to the process).
Well, that sounds interesting. And very complicated...
(And time consuming...)
gazelle@shell.xmission.com (Kenny McCormack) writes:
[...]
Another way to get the information, which is more universal but also is >>>more difficult to follow, is to make a TIOCGPTN system call on the file >>>descriptor (from a debugger attached to the process).
Well, that sounds interesting. And very complicated...
(And time consuming...)
It's really quite simple. First, the numeric value of TIOCGPTN needs to ...
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 234:47:38 |
Calls: | 6,624 |
Files: | 12,172 |
Messages: | 5,319,700 |