We know that if you log in on a given pts - say, /dev/pts/27 - and then
start background some process, then log off, the background process will
(still) have /dev/pts/27 open. Yet, when you log out, that file
(/dev/pts/27) will (usually) be deleted (i.e., no longer present in
/dev/pts). However, since the background process still has it open, it
cannot be re-used (until said background process either closes it or exits).

When you look in /proc/<pid>/fd, you see that /dev/pts/27 is open (but is
listed as "deleted").

So, my question is: Why bother to delete it if it is still in use (and
can't be re-used)? (Remember, this is a question about the implementation;
I'm not talking about any user-space process deleting anything). Why not
delete it only after all processes have closed it (so that it can then be
re-used)?

My guess is that it gets deleted because the system detects that it is no
longer the "control terminal" of any process. But, as I've argued above,
this seems actually counter-productive. Is there any reason for it to be
this way?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/ItsTough

On Thu, 7 Jul 2022 15:23:24 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>We know that if you log in on a given pts - say, /dev/pts/27 - and then
>start background some process, then log off, the background process will
>(still) have /dev/pts/27 open. Yet, when you log out, that file
>(/dev/pts/27) will (usually) be deleted (i.e., no longer present in
>/dev/pts). However, since the background process still has it open, it
>cannot be re-used (until said background process either closes it or exits).
>
>When you look in /proc/<pid>/fd, you see that /dev/pts/27 is open (but is
>listed as "deleted").
>
>So, my question is: Why bother to delete it if it is still in use (and
>can't be re-used)? (Remember, this is a question about the implementation;
>I'm not talking about any user-space process deleting anything). Why not
>delete it only after all processes have closed it (so that it can then be
>re-used)?
>
>My guess is that it gets deleted because the system detects that it is no
>longer the "control terminal" of any process. But, as I've argued above,
>this seems actually counter-productive. Is there any reason for it to be
>this way?

Presumably you're referring to Linux in which case its probably another
"feature" of systemd rather than the kernel itself and looking for logic in
a lot of Poetterings decisions can be a waste of time.

gazelle@shell.xmission.com (Kenny McCormack) writes:
>We know that if you log in on a given pts - say, /dev/pts/27 - and then
>start background some process, then log off, the background process will
>(still) have /dev/pts/27 open. Yet, when you log out, that file
>(/dev/pts/27) will (usually) be deleted (i.e., no longer present in
>/dev/pts). However, since the background process still has it open, it
>cannot be re-used (until said background process either closes it or exits).
>
>When you look in /proc/<pid>/fd, you see that /dev/pts/27 is open (but is
>listed as "deleted").
>
>So, my question is: Why bother to delete it if it is still in use (and
>can't be re-used)? (Remember, this is a question about the implementation;
>I'm not talking about any user-space process deleting anything). Why not
>delete it only after all processes have closed it (so that it can then be
>re-used)?

If the the controlling terminal master (e.g. xterm) exits, the
slave side of the pseudo terminal cannot be subsequently opened, so
the pts kernel driver removes it from the 'devpts' pseudo file system (on
linux - SysV doesn't have a devpts pfs, so they don't remove the
entries in the /dev/pts subdirectory).

Accesses to the slave side by orphaned processes in the session or process
group(s) associated with the former master terminal will receive
EIO errors.

$ mount | grep pts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)

Sorry muttley, it has nothing to do with systemd.

Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
a écrit :
> Presumably you're referring to Linux in which case its probably another
> "feature" of systemd rather than the kernel itself and looking for logic in
> a lot of Poetterings decisions can be a waste of time.

/dev/pts has nothing to do with systemd, it predates it by many years.

You should be careful, hate twists your reasoning.

Nicolas George <nicolas$george@salle-s.org> writes:
>Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
> a �crit�:
>> Presumably you're referring to Linux in which case its probably another
>> "feature" of systemd rather than the kernel itself and looking for logic in
>> a lot of Poetterings decisions can be a waste of time.
>
>/dev/pts has nothing to do with systemd, it predates it by many years.
>
>You should be careful, hate twists your reasoning.

To the extent that systems exist without the 'devpts' pseudo filesystem,
they use 'udev' to manage dynamic changes to the /dev hierarchy. I
wouldn't be surprised if systemd has absorbed that functionality
(and indeed, it appears that udev was absorbed by systemd a decade ago).

On systems with the 'devpts' pfs, the pfs will remove the entry
when it is no longer useful (i.e. if/when the master side is closed).

In either case, since the /dev/pts entry cannot be used after the
master is closed, it makes no sense to keep it around.

Scott Lurndal, dans le message <N3ExK.426622$X_i.362259@fx18.iad>, a
écrit :
> On systems with the 'devpts' pfs, the pfs will remove the entry
> when it is no longer useful (i.e. if/when the master side is closed).

Since it is a virtual file system, there is no removal at all: the
filessytem just translates the internal tables of the kernel.

Nicolas George <nicolas$george@salle-s.org> writes:
>Scott Lurndal, dans le message <N3ExK.426622$X_i.362259@fx18.iad>, a
> �crit�:
>> On systems with the 'devpts' pfs, the pfs will remove the entry
>> when it is no longer useful (i.e. if/when the master side is closed).
>
>Since it is a virtual file system, there is no removal at all: the
>filessytem just translates the internal tables of the kernel.

Removing from the internal table of the kernel "removes" it from
the filesystem. Semantics.

On 2022-07-07, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> My guess is that it gets deleted because the system detects that it is no
> longer the "control terminal" of any process. But, as I've argued above,
> this seems actually counter-productive. Is there any reason for it to be
> this way?

You know, you could be looking at some systemd fuckery.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2022-07-07, Nicolas George <nicolas$george@salle-s.org> wrote:
> Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
> a écrit :
>> Presumably you're referring to Linux in which case its probably another
>> "feature" of systemd rather than the kernel itself and looking for logic in
>> a lot of Poetterings decisions can be a waste of time.
>
> /dev/pts has nothing to do with systemd, it predates it by many years.

Your reasoning being what? That systemd wouldn't mess with anything that
predated it?

Don't you know that it handles udev events and messes with dev?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On Thu, 07 Jul 2022 16:44:29 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Nicolas George <nicolas$george@salle-s.org> writes:
>>Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
>> a �crit�:
>>> Presumably you're referring to Linux in which case its probably another
>>> "feature" of systemd rather than the kernel itself and looking for logic in
>>> a lot of Poetterings decisions can be a waste of time.
>>
>>/dev/pts has nothing to do with systemd, it predates it by many years.
>>
>>You should be careful, hate twists your reasoning.
>
>To the extent that systems exist without the 'devpts' pseudo filesystem,
>they use 'udev' to manage dynamic changes to the /dev hierarchy. I
>wouldn't be surprised if systemd has absorbed that functionality
>(and indeed, it appears that udev was absorbed by systemd a decade ago).
>
>On systems with the 'devpts' pfs, the pfs will remove the entry
>when it is no longer useful (i.e. if/when the master side is closed).

An IPC link whether a pipe, fifo, message queue etc or a ptm/pts should not
be deleted until BOTH sides have closed the link.

>In either case, since the /dev/pts entry cannot be used after the
>master is closed, it makes no sense to keep it around.

If the slave process is still attached it could in theory wait for a new master.

On 07 Jul 2022 16:29:07 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
> a �crit�:
>> Presumably you're referring to Linux in which case its probably another
>> "feature" of systemd rather than the kernel itself and looking for logic in
>> a lot of Poetterings decisions can be a waste of time.
>
>/dev/pts has nothing to do with systemd, it predates it by many years.
>
>You should be careful, hate twists your reasoning.

You need to learn about systemd and where its tentacles have reached.

Muttley@dastardlyhq.com writes:
>On Thu, 07 Jul 2022 16:44:29 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Nicolas George <nicolas$george@salle-s.org> writes:
>>>Muttley@dastardlyhq.com, dans le message <ta6vfq$16rg$1@gioia.aioe.org>,
>>> a �crit�:
>>>> Presumably you're referring to Linux in which case its probably another
>>>> "feature" of systemd rather than the kernel itself and looking for logic in
>>>> a lot of Poetterings decisions can be a waste of time.
>>>
>>>/dev/pts has nothing to do with systemd, it predates it by many years.
>>>
>>>You should be careful, hate twists your reasoning.
>>
>>To the extent that systems exist without the 'devpts' pseudo filesystem,
>>they use 'udev' to manage dynamic changes to the /dev hierarchy. I
>>wouldn't be surprised if systemd has absorbed that functionality
>>(and indeed, it appears that udev was absorbed by systemd a decade ago).
>>
>>On systems with the 'devpts' pfs, the pfs will remove the entry
>>when it is no longer useful (i.e. if/when the master side is closed).
>
>An IPC link whether a pipe, fifo, message queue etc or a ptm/pts should not
>be deleted until BOTH sides have closed the link.

Technically, the PTM/PTS pair is not deleted until both sides have closed the link.

The directory entry for the slave is, however, removed when the master
side is closed. As it should be.

Muttley@dastardlyhq.com writes:
>On Thu, 07 Jul 2022 16:44:29 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:

>>In either case, since the /dev/pts entry cannot be used after the
>>master is closed, it makes no sense to keep it around.
>
>If the slave process is still attached it could in theory wait for a new master.
>

What theory is that? Pseudo terminal behavior is standardized by
the Open Group/POSIX specifications. /dev/ptm is a multiplexor
which 'creates' a new client side (pts) when opened. There is no
API to associate a new master with an existing PTS.

On Fri, 08 Jul 2022 14:00:23 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>>>In either case, since the /dev/pts entry cannot be used after the
>>>master is closed, it makes no sense to keep it around.
>>
>>If the slave process is still attached it could in theory wait for a new
>master.
>>
>
>What theory is that? Pseudo terminal behavior is standardized by
>the Open Group/POSIX specifications. /dev/ptm is a multiplexor
>which 'creates' a new client side (pts) when opened. There is no
>API to associate a new master with an existing PTS.

Why would it need an API other than what exists already? The ptm is a (virtual)
file. If it wasn't deleted something else with the correct permissions could in
theory open it. Perhaps deleting it is a security measure because of this
possibility.

Muttley@dastardlyhq.com writes:
>On Fri, 08 Jul 2022 14:00:23 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Thu, 07 Jul 2022 16:44:29 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>>>In either case, since the /dev/pts entry cannot be used after the
>>>>master is closed, it makes no sense to keep it around.
>>>
>>>If the slave process is still attached it could in theory wait for a new
>>master.
>>>
>>
>>What theory is that? Pseudo terminal behavior is standardized by
>>the Open Group/POSIX specifications. /dev/ptm is a multiplexor
>>which 'creates' a new client side (pts) when opened. There is no
>>API to associate a new master with an existing PTS.
>
>Why would it need an API other than what exists already? The ptm is a (virtual)
>file. If it wasn't deleted something else with the correct permissions could in
>theory open it. Perhaps deleting it is a security measure because of this
>possibility.
>

The master side of a pseudo terminal pair does not have a directory entry
in the file system. /dev/ptm is a special device that creates a pts pair
when opened.

On Fri, 08 Jul 2022 15:42:49 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Fri, 08 Jul 2022 14:00:23 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>Muttley@dastardlyhq.com writes:
>>>>On Thu, 07 Jul 2022 16:44:29 GMT
>>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>
>>>>>In either case, since the /dev/pts entry cannot be used after the
>>>>>master is closed, it makes no sense to keep it around.
>>>>
>>>>If the slave process is still attached it could in theory wait for a new
>>>master.
>>>>
>>>
>>>What theory is that? Pseudo terminal behavior is standardized by
>>>the Open Group/POSIX specifications. /dev/ptm is a multiplexor
>>>which 'creates' a new client side (pts) when opened. There is no
>>>API to associate a new master with an existing PTS.
>>
>>Why would it need an API other than what exists already? The ptm is a
>(virtual)
>>file. If it wasn't deleted something else with the correct permissions could
>in
>>theory open it. Perhaps deleting it is a security measure because of this
>>possibility.
>>
>
>The master side of a pseudo terminal pair does not have a directory entry
>in the file system. /dev/ptm is a special device that creates a pts pair
>when opened.

*sigh*. I know that, never mind, you obviously didn't understand what I meant.

Muttley@dastardlyhq.com:
>On Thu, 07 Jul 2022 16:44:29 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:

>>In either case, since the /dev/pts entry cannot be used after the
>>master is closed, it makes no sense to keep it around.
>
>If the slave process is still attached it could in theory wait for
>a new master.

Do I understand correctly, that you think of the following
scenario?

Say, there is a "bash" running in an "xterm".  Run the following
shell command to get a long‐running job which determines the
pathname of its pseudo terminal, waits one day, and finally opens
the pathname of its past pseudo terminal, writing a greeting to it,
then exit:

(
tty="$(tty)" &&
sleep -- "$(( 24 * 3600 ))" &&
printf '%s\n' 'Hello, world!' > "$tty"
) &

Running the command

ps -o ppid -o sid -o tty -o tpgid -o pgid -o pid \
-o stat -o args --sort=sid,pgid,stime -s 12217

from a different session group will show the long‐running job
12314.  (The "printf" command is not shown already as it won't be
started before the "sleep" will have exited.):

PPID SID TT TPGID PGID PID STAT COMMAND
12209 12217 pts/2 12217 12217 12217 Ss+ /bin/bash
12217 12217 pts/2 12217 12314 12314 S /bin/bash
12314 12217 pts/2 12217 12314 12317 S sleep -- 86400

After exiting the shell (and the xterm), the job will keep running
orphaned:

PPID SID TT TPGID PGID PID STAT COMMAND
1 12217 ? -1 12314 12314 S /bin/bash
12314 12217 ? -1 12314 12317 S sleep -- 86400

Now, imagine, that a new xterm is opened, running a shell, and, by
incident, the pseudo terminal it gets will have the same name
"/dev/pts/2".  This should be possible, because the old "/dev/pts/2"
entry has already been removed from the directory, i. e., it
wouldn't be "reserved" any more.

As the orphaned job will explicitly open "/dev/pts/2", it would
write to the new pseudo terminal that happens to have the same name
like the old had.

Therefore, wouldn't it be more sensible to not have the name
"/dev/pts/2" removed from the (virtual) directory as long as the old
process session has not ceased to exist in the system?  That would
prevent the pseudo terminal multiplexer to create a new "/dev/pts/2"
by accident, thus prevent the "printf" command to write to the new
"/dev/pts/2".

Of course the "printf" command should have used "/dev/tty" rather
than "/dev/pts/2" in the redirection, that is, the output of the
"tty" command should be considered to be obsolete as soon as it is
received (unless one knows that the controlling terminal is still
alive).

Helmut Waitzmann <nn.throttle@xoxy.net> writes:
>Muttley@dastardlyhq.com:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>>>In either case, since the /dev/pts entry cannot be used after the=20
>>>master is closed, it makes no sense to keep it around.
>>
>>If the slave process is still attached it could in theory wait for=20
>>a new master.
>
>Do I understand correctly, that you think of the following=20
>scenario?
>
>Say, there is a "bash" running in an "xterm".=C2=A0 Run the following=20
>shell command to get a long=E2=80=90running job which determines the=20
>pathname of its pseudo terminal, waits one day, and finally opens=20
>the pathname of its past pseudo terminal, writing a greeting to it,=20
>then exit:

So long as any process has the original /dev/pts/2 client side open, the mux
will _never_ assign /dev/pts/2 to a new process. Even if the directory entry
no longer exists, the internal operating system data structure (inode)
will exist so long as any process still has it open and the mux will
ignore it.