zellij
zellij copied to clipboard
I'm not seeing zellij detach on a SIGHUP
Should this work? If I start a zellij session and my ssh connection to a remote is terminated for whatever reason (such as my closing my laptop lid) I would expect my current zellij session to be detached from the session. However, this doesn't occur.
Hey, this is actually supposed to work. What is happening instead?
The session seems to get killed off. When I rellogin and do a zellij attach there are no sessions. If I explicitly detach everything works as expected.
Quite odd... could you describe what you're doing exactly?
I'll have to try and reproduce what is occurring without closing my laptop lid for 30 minutes :)
So, I'm not sure what your box is doing when you close the lid - but could it be that it's killing the Zellij server process?
I don't think so. What I'm doing:
- ssh to a remote host.
- start zellij, and run some long running process.
- ... time passes and I close the lid When I open the lid and log back into that remote host there are no zellij sessions running. That does not occur if I manually detach the session.
This is my typical workflow with tmux and/or screen and that all works fine.
I had a few quick tries yesteday which killing my login session, or closing the terminal window and I could not reproduce, so something else must be going on.
Hmm... quite odd! @raphCode - do you think this is related to the bug you recently fixed?
In case @newhook is running the latest version (v0.31.4), it could indeed be this issue since the fix is still unreleased: https://github.com/zellij-org/zellij/issues/1532
You may want to look into the environment in which SSH processes are launched on the server side. There is some tendency on systemd based settings to kill all of a user's processes once the user has logged out (AIU a relic of desktop environments' inability to keep tabs on daemons they spawn).
For tmux, I had to sometimes start my server as systemd-run --scope --user tmux new-session
; if starting zellij similarly resolves your issue, it's likely that systemd kills your "rogue daemon processes".