Your message dated Thu, 8 Jul 2021 12:32:14 +0200
with message-id <[email protected]>
and subject line Re: lost session with "Error: Cannot find master process to 
attach to!"
has caused the Debian Bug report #958965,
regarding screen: lost session with "Error: Cannot find master process to 
attach to!"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
958965: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958965
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: screen
Version: 4.8.0-1
Severity: important

After increasing the window width, I got an error

  Error: Cannot find master process to attach to!
  Press [Enter] to quit.

Then the screen session was lost.

Note: I've been using screen for many years, this is the first time
I get such an error.

-- Package-specific info:
File Existence and Permissions
------------------------------

drwxr-xr-x 31 root root   1220 2020-04-27 02:53:50 /run
lrwxrwxrwx  1 root root      4 2015-06-18 10:17:14 /var/run -> /run
-rwxr-xr-x  1 root root 470024 2020-02-08 02:16:54 /usr/bin/screen
-rw-r--r--  1 root root     29 2017-06-20 22:41:20 
/etc/tmpfiles.d/screen-cleanup.conf
lrwxrwxrwx  1 root root      9 2015-06-18 23:53:21 
/lib/systemd/system/screen-cleanup.service -> /dev/null
-rwxr-xr-x  1 root root   1222 2017-04-03 01:11:05 /etc/init.d/screen-cleanup
lrwxrwxrwx  1 root root     24 2019-09-19 09:16:32 /etc/rcS.d/S18screen-cleanup 
-> ../init.d/screen-cleanup

File contents
-------------

### /etc/tmpfiles.d/screen-cleanup.conf
______________________________________________________________________
d /run/screen 1777 root utmp
______________________________________________________________________

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages screen depends on:
ii  libc6         2.30-4
ii  libcrypt1     1:4.4.16-1
ii  libpam0g      1.3.1-5
ii  libtinfo6     6.2-1
ii  libutempter0  1.1.6-6

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  <none>
ii  ncurses-term                6.2-1

-- no debconf information

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- End Message ---
--- Begin Message ---
On 2020-04-27 11:06:51 +0200, Vincent Lefevre wrote:
> After increasing the window width, I got an error
> 
>   Error: Cannot find master process to attach to!
>   Press [Enter] to quit.
> 
> Then the screen session was lost.
> 
> Note: I've been using screen for many years, this is the first time
> I get such an error.

I'm closing this bug since I could not reproduce the issue.

It isn't even clear that this was caused by the terminal window width
increase: the master could have died much earlier. The fact is that a
terminal window width change triggers an access to the socket, while
the other usual operations don't (even changing the screen window).
This can be seen with a "touch .screen/<socket>", then some usual
operations, then "stat .screen/<socket>": the atime isn't changed.
But then, after a terminal window width change, stat shows that atime
has been changed.

Note: Each time atime is changed, one needs the "touch" to be able to
detect another access if the corresponding filesystem has been mounted
with the relatime option, which is the default.

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

--- End Message ---

Reply via email to