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?
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.
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)?
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.
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).
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.
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.
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?
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.
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.
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.
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.
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 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.
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 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.
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:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 129:31:31 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,157 |