Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Question on implementation of /dev/pts
126 views
Skip to first unread message
Kenny McCormack
Jul 7, 2022, 11:23:28 AM7/7/22
to
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
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
Mut...@dastardlyhq.com
Jul 7, 2022, 11:52:31 AM7/7/22
to
On Thu, 7 Jul 2022 15:23:24 -0000 (UTC)
gaz...@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
gaz...@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?
"feature" of systemd rather than the kernel itself and looking for logic in
a lot of Poetterings decisions can be a waste of time.
Scott Lurndal
Jul 7, 2022, 12:24:48 PM7/7/22
to
gaz...@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
>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)?
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.
Nicolas George
Jul 7, 2022, 12:29:11 PM7/7/22
to
Mut...@dastardlyhq.com, dans le message <ta6vfq$16rg$1...@gioia.aioe.org>,
a écrit :
You should be careful, hate twists your reasoning.
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.
> "feature" of systemd rather than the kernel itself and looking for logic in
> a lot of Poetterings decisions can be a waste of time.
You should be careful, hate twists your reasoning.
Scott Lurndal
Jul 7, 2022, 12:44:33 PM7/7/22
to
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.
Nicolas George
Jul 7, 2022, 12:46:06 PM7/7/22
to
Scott Lurndal, dans le message <N3ExK.426622$X_i.3...@fx18.iad>, a
écrit :
filessytem just translates the internal tables of the kernel.
é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
> when it is no longer useful (i.e. if/when the master side is closed).
filessytem just translates the internal tables of the kernel.
Scott Lurndal
Jul 7, 2022, 1:13:43 PM7/7/22
to
the filesystem. Semantics.
Kaz Kylheku
Jul 7, 2022, 8:54:05 PM7/7/22
to
On 2022-07-07, Kenny McCormack <gaz...@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.
> 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?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Kaz Kylheku
Jul 7, 2022, 8:55:20 PM7/7/22
to
On 2022-07-07, Nicolas George <nicolas$geo...@salle-s.org> wrote:
> Mut...@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
> Mut...@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.
predated it?
Don't you know that it handles udev events and messes with dev?
Mut...@dastardlyhq.com
Jul 8, 2022, 8:05:33 AM7/8/22
to
On Thu, 07 Jul 2022 16:44:29 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Nicolas George <nicolas$geo...@salle-s.org> writes:
>>Mut...@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
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Nicolas George <nicolas$geo...@salle-s.org> writes:
>>Mut...@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).
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.
Mut...@dastardlyhq.com
Jul 8, 2022, 8:06:04 AM7/8/22
to
On 07 Jul 2022 16:29:07 GMT
You need to learn about systemd and where its tentacles have reached.
Scott Lurndal
Jul 8, 2022, 9:58:09 AM7/8/22
to
Mut...@dastardlyhq.com writes:
>On Thu, 07 Jul 2022 16:44:29 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>Nicolas George <nicolas$geo...@salle-s.org> writes:
>>>Mut...@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.
>On Thu, 07 Jul 2022 16:44:29 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>Nicolas George <nicolas$geo...@salle-s.org> writes:
>>>Mut...@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.
The directory entry for the slave is, however, removed when the master
side is closed. As it should be.
Scott Lurndal
Jul 8, 2022, 10:00:27 AM7/8/22
to
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.
Mut...@dastardlyhq.com
Jul 8, 2022, 11:34:15 AM7/8/22
to
On Fri, 08 Jul 2022 14:00:23 GMT
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.
sc...@slp53.sl.home (Scott Lurndal) wrote:
>Mut...@dastardlyhq.com writes:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>sc...@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)
>Mut...@dastardlyhq.com writes:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>sc...@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.
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.
Scott Lurndal
Jul 8, 2022, 11:42:53 AM7/8/22
to
in the file system. /dev/ptm is a special device that creates a pts pair
when opened.
Mut...@dastardlyhq.com
Jul 8, 2022, 12:01:20 PM7/8/22
to
On Fri, 08 Jul 2022 15:42:49 GMT
*sigh*. I know that, never mind, you obviously didn't understand what I meant.
Helmut Waitzmann
Aug 2, 2022, 4:36:00 PM8/2/22
to
Mut...@dastardlyhq.com:
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).
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).
Scott Lurndal
Aug 2, 2022, 5:45:33 PM8/2/22
to
Helmut Waitzmann <nn.th...@xoxy.net> writes:
>Mut...@dastardlyhq.com:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>>>In either case, since the /dev/pts entry cannot be used after the=20
>Mut...@dastardlyhq.com:
>>On Thu, 07 Jul 2022 16:44:29 GMT
>>sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>>>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.
0 new messages