Re: cannot start detached sessions (with -m -d) back to back
On Sun, 16 Jan 2022, Christos Zoulas wrote: screen -S ses -d -m -p 0 cat screen -S sys -X quit The 2nd session name should be `ses' shouldn't it? I can't reproduce this... Gah! now I can (with the old screen from the binary pkgs) and my "fix" doesn't work anymore. Dunno what changed. I'll look into it again. -RVP
Re: cannot start detached sessions (with -m -d) back to back
I can't reproduce this... Trying the following works: christos screen -S ses -d -m -p 0 cat screen -S sys -X quit > On Jan 4, 2022, at 6:45 AM, RVP wrote: > > On Mon, 3 Jan 2022, Christos Zoulas wrote: > >> Yes, in the end screen was at fault for setting CLOCAL in the pty which >> prevented from SIGHUP from being sent. I fixed it. >> > > I think the problem may be that in canonical mode, the slave goes to > sleep waiting for input (in tty.c:ttread()) and nothing wakes it up > when the master side is closed. The patch below seems to work, but, > please scrutinize it carefully as I've only tested it lightly and I'm > also operating without a license :) > > ---START PATCH--- > --- sys/kern/tty_pty.c.orig 2021-10-11 04:12:12.543371554 + > +++ sys/kern/tty_pty.c2022-01-04 11:08:51.163444059 + > @@ -637,6 +637,7 @@ > mutex_spin_enter(_lock); > CLR(tp->t_state, TS_CARR_ON); > tp->t_oproc = NULL; /* mark closed */ > + cv_broadcast(>t_rawcv); /* wake-up slave */ > mutex_spin_exit(_lock); > return 0; > } > ---END PATCH--- > > -RVP signature.asc Description: Message signed with OpenPGP
Re: cannot start detached sessions (with -m -d) back to back
On Tue, 4 Jan 2022, Christos Zoulas wrote:
Isn't t_rawcv used only during the open? (t_rawcvf is used in write,
and t_outcvf is used in read).
I figured it as `t_rawcv':
In the slave:
tty_pty.c:ptsread() calls ttread():
479 } else if (tp->t_oproc)
480 error = (*tp->t_linesw->l_read)(tp, uio, flag);
tty.c:ttread() sleeps on `t_rawcv' (this is the master-side in PTYs, of
course):
1992 error = ttysleep(tp, >t_rawcv, true, slp);
1993 mutex_spin_exit(_lock);
And, in the PTY-master:
tty_pty.c:ptcwrite():
810(tp->t_canq.c_cc > 0 || !canon)) {
811 cv_broadcast(>t_rawcv);
I haven't goofed this, I hope...
Thanks,
RVP
Re: cannot start detached sessions (with -m -d) back to back
In article , RVP wrote: >On Mon, 3 Jan 2022, Christos Zoulas wrote: > >> Yes, in the end screen was at fault for setting CLOCAL in the pty which >> prevented from SIGHUP from being sent. I fixed it. >> > >I think the problem may be that in canonical mode, the slave goes to >sleep waiting for input (in tty.c:ttread()) and nothing wakes it up >when the master side is closed. The patch below seems to work, but, >please scrutinize it carefully as I've only tested it lightly and I'm >also operating without a license :) > >---START PATCH--- >--- sys/kern/tty_pty.c.orig2021-10-11 04:12:12.543371554 + >+++ sys/kern/tty_pty.c 2022-01-04 11:08:51.163444059 + >@@ -637,6 +637,7 @@ > mutex_spin_enter(_lock); > CLR(tp->t_state, TS_CARR_ON); > tp->t_oproc = NULL; /* mark closed */ >+ cv_broadcast(>t_rawcv); /* wake-up slave */ > mutex_spin_exit(_lock); > return 0; > } Isn't t_rawcv used only during the open? (t_rawcvf is used in write, and t_outcvf is used in read). christos
Re: cannot start detached sessions (with -m -d) back to back
On Mon, 3 Jan 2022, Christos Zoulas wrote: Yes, in the end screen was at fault for setting CLOCAL in the pty which prevented from SIGHUP from being sent. I fixed it. I think the problem may be that in canonical mode, the slave goes to sleep waiting for input (in tty.c:ttread()) and nothing wakes it up when the master side is closed. The patch below seems to work, but, please scrutinize it carefully as I've only tested it lightly and I'm also operating without a license :) ---START PATCH--- --- sys/kern/tty_pty.c.orig 2021-10-11 04:12:12.543371554 + +++ sys/kern/tty_pty.c 2022-01-04 11:08:51.163444059 + @@ -637,6 +637,7 @@ mutex_spin_enter(_lock); CLR(tp->t_state, TS_CARR_ON); tp->t_oproc = NULL; /* mark closed */ + cv_broadcast(>t_rawcv); /* wake-up slave */ mutex_spin_exit(_lock); return 0; } ---END PATCH--- -RVP
Re: cannot start detached sessions (with -m -d) back to back
In article , Valery Ushakov wrote: >On Sat, Jan 01, 2022 at 21:49:00 +, RVP wrote: > >> OK, but, I think we can do better than rudely sending processes a SIGHUP. >> Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of >> /dev/ptmx seems to do the right thing: EOF when the PTY master is closed. >> >> File a PR (Category: pkg) > >Why pkg? This is a kernel bug. POSIX doesn't seem to say anything >about this, but Christos pointed out e.g. > > https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/pty.7.html > >that says > > A read() request made on the slave side of a pty after the master > side is closed returns 0 bytes. Closing the master side of a pty > sends a SIGHUP hangup signal to the tty process group number of the > corresponding slave side and flushes pending input and output. > >Solaris docs for (STREAMS-based) ptys say: > > When the master device is closed, an M_HANGUP message is sent to the > slave device to render the device unusable. The process on the slave > side gets the errno ENXIO when attempting to write on that stream, > but it will be able to read any data remaining on the stream head > read queue. When all the data has been read, read(2) returns 0, > indicating that the stream can no longer be used. Yes, in the end screen was at fault for setting CLOCAL in the pty which prevented from SIGHUP from being sent. I fixed it. christos
Re: cannot start detached sessions (with -m -d) back to back
u...@stderr.spb.ru (Valery Ushakov) writes: >Solaris docs for (STREAMS-based) ptys say: > When the master device is closed, an M_HANGUP message is sent to the > slave device to render the device unusable. The process on the slave > side gets the errno ENXIO when attempting to write on that stream, > but it will be able to read any data remaining on the stream head > read queue. When all the data has been read, read(2) returns 0, > indicating that the stream can no longer be used. M_HANGHUP also causes a SIGHUP signal to be sent to the controlling process. For interactive sessions that's the shell which intercepts the signal, resumes stopped jobs and passes the SIGHUP to them.
Re: cannot start detached sessions (with -m -d) back to back
On Sun, 2 Jan 2022, Valery Ushakov wrote: Why pkg? This is a kernel bug. Best guess on my part: I wasn't sure if ptmx was a full-fledged NetBSD citizen since libc uses /dev/ptm internally (only posix_openpt(3) opens ptmx). Category kern is fine with me; but, then, the fix is above my pay grade. -RVP
Re: cannot start detached sessions (with -m -d) back to back
On Sat, Jan 01, 2022 at 21:49:00 +, RVP wrote: > OK, but, I think we can do better than rudely sending processes a SIGHUP. > Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of > /dev/ptmx seems to do the right thing: EOF when the PTY master is closed. > > File a PR (Category: pkg) Why pkg? This is a kernel bug. POSIX doesn't seem to say anything about this, but Christos pointed out e.g. https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/pty.7.html that says A read() request made on the slave side of a pty after the master side is closed returns 0 bytes. Closing the master side of a pty sends a SIGHUP hangup signal to the tty process group number of the corresponding slave side and flushes pending input and output. Solaris docs for (STREAMS-based) ptys say: When the master device is closed, an M_HANGUP message is sent to the slave device to render the device unusable. The process on the slave side gets the errno ENXIO when attempting to write on that stream, but it will be able to read any data remaining on the stream head read queue. When all the data has been read, read(2) returns 0, indicating that the stream can no longer be used. -uwe
Re: cannot start detached sessions (with -m -d) back to back
On Sat, 1 Jan 2022, Adam Russell wrote: I can confirm that the patch given above works for me. I built this in pkgsrc. After the existing patches ran I manually applied the patch and then ran make. OK, but, I think we can do better than rudely sending processes a SIGHUP. Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of /dev/ptmx seems to do the right thing: EOF when the PTY master is closed. File a PR (Category: pkg) and I'll send in a better fix (and, hopefully, not break compatibility in the process) some time this week. Email me the PR# since I'm not on the pkgsrc lists. Thanks, -RVP
Re: cannot start detached sessions (with -m -d) back to back
Adam Russell wrote:
RVP wrote:
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p = windows;
windows = windows->w_next;
FreeWindow(p);
+ if (p->w_pid > 0) {
+ debug1("Hangup(%d);\n", p->w_pid);
+ killpg(p->w_pid, SIGHUP);
+ }
}
if (ServerSocket != -1) {
---END---
I goofed that (use-after-free). Try this one please:
---START---
diff -urN screen-4.8.0.orig/screen.c screen-4.8.0/screen.c
--- screen-4.8.0.orig/screen.c 2021-12-31 03:27:41.988827000 +
+++ screen-4.8.0/screen.c 2021-12-31 03:26:47.995416000 +
@@ -1801,8 +1801,13 @@
debug1("Finit(%d);\n", i);
while (windows) {
struct win *p = windows;
+ pid_t pid = p->w_pid;
windows = windows->w_next;
FreeWindow(p);
+ if (pid > 0) {
+ debug1("Hangup(%d);\n", pid);
+ killpg(pid, SIGHUP);
+ }
}
if (ServerSocket != -1) {
---END---
oh wow, great work! I will try this as soon as possible, which might not
be until tomorrow.
I can confirm that the patch given above works for me. I built this in
pkgsrc. After the existing patches ran I manually applied the patch and
then ran make.
Great work! Happy New Year!
-bash-5.1$ work/screen-4.8.0/screen -S some-session -p 0 -m -d;
work/screen-4.8.0/screen -ls; work/screen-4.8.0/screen -X quit; sleep
10; work/screen-4.8.0/screen -S some-session -p 0 -m -d;
work/screen-4.8.0/screen -ls; sleep 1; work/screen-4.8.0/screen -ls
There is a screen on:
18073.some-session (Detached)
1 Socket in /tmp/uscreens/S-adamcrussell.
There is a screen on:
20109.some-session (Detached)
1 Socket in /tmp/uscreens/S-adamcrussell.
There is a screen on:
20109.some-session (Detached)
1 Socket in /tmp/uscreens/S-adamcrussell.
Re: cannot start detached sessions (with -m -d) back to back
RVP wrote:
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p = windows;
windows = windows->w_next;
FreeWindow(p);
+ if (p->w_pid > 0) {
+ debug1("Hangup(%d);\n", p->w_pid);
+ killpg(p->w_pid, SIGHUP);
+ }
}
if (ServerSocket != -1) {
---END---
I goofed that (use-after-free). Try this one please:
---START---
diff -urN screen-4.8.0.orig/screen.c screen-4.8.0/screen.c
--- screen-4.8.0.orig/screen.c 2021-12-31 03:27:41.988827000 +
+++ screen-4.8.0/screen.c 2021-12-31 03:26:47.995416000 +
@@ -1801,8 +1801,13 @@
debug1("Finit(%d);\n", i);
while (windows) {
struct win *p = windows;
+ pid_t pid = p->w_pid;
windows = windows->w_next;
FreeWindow(p);
+ if (pid > 0) {
+ debug1("Hangup(%d);\n", pid);
+ killpg(pid, SIGHUP);
+ }
}
if (ServerSocket != -1) {
---END---
oh wow, great work! I will try this as soon as possible, which might not
be until tomorrow.
Re: cannot start detached sessions (with -m -d) back to back
On Fri, 31 Dec 2021, RVP wrote:
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c --- screen-4.8.0.orig/screen.c
2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p = windows;
windows = windows->w_next;
FreeWindow(p);
+if (p->w_pid > 0) {
+ debug1("Hangup(%d);\n", p->w_pid);
+ killpg(p->w_pid, SIGHUP);
+}
}
if (ServerSocket != -1) {
---END---
I goofed that (use-after-free). Try this one please:
---START---
diff -urN screen-4.8.0.orig/screen.c screen-4.8.0/screen.c
--- screen-4.8.0.orig/screen.c 2021-12-31 03:27:41.988827000 +
+++ screen-4.8.0/screen.c 2021-12-31 03:26:47.995416000 +
@@ -1801,8 +1801,13 @@
debug1("Finit(%d);\n", i);
while (windows) {
struct win *p = windows;
+pid_t pid = p->w_pid;
windows = windows->w_next;
FreeWindow(p);
+if (pid > 0) {
+ debug1("Hangup(%d);\n", pid);
+ killpg(pid, SIGHUP);
+}
}
if (ServerSocket != -1) {
---END---
-RVP
Re: cannot start detached sessions (with -m -d) back to back
On Fri, Dec 31, 2021 at 02:08:02 +, RVP wrote: > On Fri, 31 Dec 2021, Valery Ushakov wrote: > > > I think screen is racing against the child process in MakeWindow. > > I think something else might also be going on: Ouch. That probably also explains why I was getting corrupt ktrace.out files sometimes, there was still that ghost shell that was being traced. That most likely is a contributing factor. If the stuck program is still holding onto the slave side, the parent screen process gets select return earlier, I guess. When the pty that still has the ghost shell attached to the slave side is reallocated, the ghost shell returns from read with 16982 16982 sh RET read RESTART reissues read and gets EOF. So if the new child wins the race, the new shell gets the pty and the new screen session is started. > 2. For some reason, on NetBSD, closing the master PTY-fd in screen does not >cause programs on the slave side to exit (on EOF). This seems like a bug to me, but I don't know much about tty driver. > Hope this helps... Thanks! -uwe
Re: cannot start detached sessions (with -m -d) back to back
On Fri, 31 Dec 2021, Valery Ushakov wrote:
I think screen is racing against the child process in MakeWindow.
I think something else might also be going on:
On NetBSD 9.2_STABLE:
$ screen -S ses -d -m -p 0 sh # create
$ ps -Au# check for screen & sh
...
root1802 0.0 0.0 27148 1992 ? Is1:34am 0:00.00 SCREEN -S ses -d
-m -p 0 sh (screen)
...
rvp 1085 0.0 0.1 23488 2252 pts/4 Ss+ 1:34am 0:00.00 sh
...
$ screen -S ses -X quit # quit
$ screen -S ses -X quit # confirm
No screen session found.
$ ls -l /dev/pts/ # check for pts/4 used by sh
total 0
crw--w 1 rvp tty 5, 0 Dec 31 01:38 0
crw--w 1 rvp tty 5, 1 Dec 31 01:38 1
crw--w 1 rvp tty 5, 2 Dec 31 01:33 2
crw--w 1 rvp tty 5, 3 Dec 31 01:38 3
$ ps -Au# but sh still exists!
...
rvp 1085 0.0 0.1 23488 2252 pts/4 Is+ 1:34am 0:00.00 sh
...
$ fstat -p 1085 # and still holding on to pts/4
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
rvp sh 1085 wd /tmp 85400958320606835 drwxrwxrwt 192 r
rvp sh 10850 /dev/pts 11 crw-rw-rw- pts/4 rw
rvp sh 10851 /dev/pts 11 crw-rw-rw- pts/4 rw
rvp sh 10852 /dev/pts 11 crw-rw-rw- pts/4 rw
rvp sh 1085 12 / 1405459 crw-rw-rw- tty rw
$ ls -l /dev/pts/ # no pts/4
total 0
crw--w 1 rvp tty 5, 0 Dec 31 01:41 0
crw--w 1 rvp tty 5, 1 Dec 31 01:40 1
crw--w 1 rvp tty 5, 2 Dec 31 01:33 2
crw--w 1 rvp tty 5, 3 Dec 31 01:41 3
$ screen -S ses -d -m -p 0 sh # other sh instances won't start
# running bash(1), however, closes
# the older instance on the same PTY
$ kill -HUP 1085# kill still running sh
$ screen -S ses -d -m -p 0 sh # now screen will run
1. I don't use screen, but, it seems to me that `-X quit' should kill off all
programs upon termination.
2. For some reason, on NetBSD, closing the master PTY-fd in screen does not
cause programs on the slave side to exit (on EOF).
OP: Try this patch:
---START---
diff -u screen-4.8.0{.orig,}/screen.c
--- screen-4.8.0.orig/screen.c 2020-02-05 20:09:38.0 +
+++ screen-4.8.0/screen.c 2021-12-31 01:56:30.470670972 +
@@ -1801,6 +1801,10 @@
struct win *p = windows;
windows = windows->w_next;
FreeWindow(p);
+if (p->w_pid > 0) {
+ debug1("Hangup(%d);\n", p->w_pid);
+ killpg(p->w_pid, SIGHUP);
+}
}
if (ServerSocket != -1) {
---END---
Hope this helps...
-RVP
Re: cannot start detached sessions (with -m -d) back to back
On Fri, Dec 31, 2021 at 03:18:08 +0300, Valery Ushakov wrote: > I think screen is racing against the child process in MakeWindow. I filed https://savannah.gnu.org/bugs/index.php?61749 for this. -uwe
Re: cannot start detached sessions (with -m -d) back to back
On Thu, Dec 30, 2021 at 06:55:24 +0300, Valery Ushakov wrote:
> Building screeen with debugging shows that succesful session start has
> for the first read from the window:
>
> + hit ev fd 5 type 1!
> going to read from window fd 5
> -> 5 bytes
>
> but failed attempt has
>
> + hit ev fd 5 type 1!
> going to read from window fd 5
> Window 0: EOF - killing window
>
> where fd 5 is obtained from the cloning pty device /dev/ptmx (ptm(4))
>
> The comment in ptcread says:
>
> /*
>* We want to block until the slave
>* is open, and there's something to read;
>* but if we lost the slave or we're NBIO,
>* then return the appropriate error instead.
>*/
> ...
> if (!ISSET(tp->t_state, TS_CARR_ON)) {
> error = 0; /* EOF */
> goto out;
> }
I think screen is racing against the child process in MakeWindow.
>From a quick look it seems that the parent opens the master side and
saves the slave name. Then it calls ForkWindow and adds the master fd
to the list of descriptors to poll. Now the race is on, b/c it takes
some time for the child to open the slave side, and if the parent wins
the race, it will get EOF from the master, as the slave is not open
yet. E.g. a failed attempt:
$ kdump | sed -n -e '/select/p' -e '/EOF/p' \
-e '/\/dev\/pts/{' -e 'N' -e '/open/p' -e '}'
4831 4831 screen CALL __select50(0x100,0x7f7fff3739f0,0x7f7fff373a10,0,0)
4831 4831 screen RET __select50 1
"Window 0: EOF (errno 0) - killing window\n"
5218 5218 screen NAMI "/dev/pts/7"
5218 5218 screen RET open 0
vs. a succesful one:
19165 19165 screen CALL __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
26839 26839 screen NAMI "/dev/pts/7"
26839 26839 screen RET open 0
19165 19165 screen RET __select50 1
"serv_select_fn called\n"
19165 19165 screen CALL __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
19165 19165 screen RET __select50 1
Using brute force to make screen pre-open the slave in the parent
process should take care of the race
--- pty.c~ 2021-12-29 23:50:37.231129335 +0300
+++ pty.c 2021-12-31 03:11:48.652558852 +0300
@@ -288,6 +288,7 @@ char **ttyn;
}
initmaster(f);
*ttyn = TtyName;
+ pty_preopen = 1; /* XXX: uwe */
return f;
}
#endif
This is the HAVE_SVR4_PTYS version of OpenPTY (yes, screen still uses
k function definitions :)
-uwe
Re: cannot start detached sessions (with -m -d) back to back
On Wed, Dec 29, 2021 at 13:40:31 -0500, Adam Russell wrote:
> What I am finding is that works to some extent, but then that second session
> seems to quickly end.
>
> Here I start a session, list all sessions, quit all sessions, sleep for 10
> seconds, start a new session, list all sessions, sleep one second, and then
> list all sessions again.
>
> As you can see the second sessions, created after the ten second sleep, does
> get created, but is gone a second later.
Building screeen with debugging shows that succesful session start has
for the first read from the window:
+ hit ev fd 5 type 1!
going to read from window fd 5
-> 5 bytes
but failed attempt has
+ hit ev fd 5 type 1!
going to read from window fd 5
Window 0: EOF - killing window
where fd 5 is obtained from the cloning pty device /dev/ptmx (ptm(4))
The comment in ptcread says:
/*
* We want to block until the slave
* is open, and there's something to read;
* but if we lost the slave or we're NBIO,
* then return the appropriate error instead.
*/
...
if (!ISSET(tp->t_state, TS_CARR_ON)) {
error = 0; /* EOF */
goto out;
}
Need to ask someone familiar with the pty internals.
-uwe
Re: cannot start detached sessions (with -m -d) back to back
I have tried to reproduce what I believe are your findings, that some delay before starting the second session is enough to fix things. What I am finding is that works to some extent, but then that second session seems to quickly end. Here I start a session, list all sessions, quit all sessions, sleep for 10 seconds, start a new session, list all sessions, sleep one second, and then list all sessions again. As you can see the second sessions, created after the ten second sleep, does get created, but is gone a second later. -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d; screen -ls; screen -X quit; sleep 10; /usr/pkg/bin/screen -S some-session -p 0 -m -d; screen -ls; sleep 1; screen -ls There is a screen on: 2406.some-session (Detached) 1 Socket in /tmp/screens/S-adamcrussell. There is a screen on: 1197.some-session (Detached) 1 Socket in /tmp/screens/S-adamcrussell. No Sockets found in /tmp/screens/S-adamcrussell.
Re: cannot start detached sessions (with -m -d) back to back
On Wed, Dec 29, 2021 at 00:01:38 -0500, Adam Russell wrote: > This is what I see > > -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d > -bash-5.1$ screen -X quit > -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d > -bash-5.1$ screen -X quit > No screen session found. I was going to say I can't reproduce it, but then I could. I couldn't reproduce the problem as is, but I have screenrc that starts a bunch of windows, so I tested with -c /dev/null and then I do see the problem. The second invocation doesn't start the new screen, just as you show. But if you wait a little bit (about 5 seconds it would seem) after the first session is quat, then the new session is created ok again. [pardon my bash^Wcsh'isms, but i think it's appropriate here as it indicates the command is repeated as-is from history and spares the reader doing the verfication] $ screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit There is a screen on: 6098.pts-0.nbvio(Detached) 1 Socket in /tmp/screens/S-uwe. No screen session found. $ !! screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit There are screens on: 6098.pts-0.nbvio(Detached) 2902.test (Detached) 2 Sockets in /tmp/screens/S-uwe. $ !! screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit There is a screen on: 6098.pts-0.nbvio(Detached) 1 Socket in /tmp/screens/S-uwe. No screen session found. $ !! screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit There are screens on: 6098.pts-0.nbvio(Detached) 14114.test (Detached) 2 Sockets in /tmp/screens/S-uwe. This is with natural typing pace. -uwe
