Your message dated Sat, 11 Sep 2021 19:15:52 +0200
with message-id
<caht6kzextbk89674cotiu-iumywxvfppct2schwjjvvqcg_...@mail.gmail.com>
and subject line Closing
has caused the Debian Bug report #928648,
regarding Sessions do not survive X restart under some conditions
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.)
--
928648: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928648
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: tmux
Version: 2.9a-1
Severity: normal
In 2.9a-1 and 2.8-3, the following procedure resulted in tmux sessions
not surviving an X restart (which is my primary use case for tmux):
* Use a fresh user
* Log in to an i3 window manager session (when prompted, press enter)
* Win-d, enter xterm
* run tmux
* From a different console, restart lightdm
* Log in again and open a terminal again
* `tmux attach` finds "no sessions"
At the same time, using gnome-terminal instead of xterm results is in
survival of the tmux session, as it should always do.
Variations I've tried:
* XFCE as a window manager: same behavior (press Alt-F2 rather than
Win-d)
* TWM shells (whatever terminal emulator their desktop menu spawns)
behave like gnome-terminal (session survives)
* Logging out instead of restarting lightdm: tmux always survives
(logout is Win-Shift-e on i3, or in the top-left menu in XFCE)
* entering Alt-Print-K (SysRQ SAK) instead of restarting lightdm: same
behavior
For comparison, I've also tried whether a SAK on a terminal kills the
tmux session: It does (when with tmux launched on console 2 and attached
on console 3, a SAK on either console takes down the whole session); I
think it should not (cf. kernel Documentation/SAK.txt), but I'm not sure
how relevant this is to the above case of depending on the chosen
terminal emulator to survive an X lockup.
In case there is no obvious cause for this, is there any additional
testing I can provide?
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tmux depends on:
ii libc6 2.28-10
ii libevent-2.1-6 2.1.8-stable-4
ii libtinfo6 6.1+20181013-2
ii libutempter0 1.1.6-3
tmux recommends no packages.
tmux suggests no packages.
-- no debconf information
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Not a bug in tmux; something is killing the server and there's nothing
tmux can do about it. Closing.
--- End Message ---
