Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#374 breaks tmux #376

Open
yan12125 opened this issue Apr 10, 2021 · 3 comments
Open

#374 breaks tmux #376

yan12125 opened this issue Apr 10, 2021 · 3 comments
Labels

Comments

@yan12125
Copy link
Member

Expected Behavior

tmux server created inside LXQt persists after logging out and can be attached later

Current Behavior

Since #374, the tmux server is gone upon logging out

Possible Solution
Steps to Reproduce (for bugs)
  1. Run qterminal from within LXQt (click the quicklaunch button in my case)
  2. Run tmux
  3. Detach the tmux session. Now the tmux server is a sub-process of lxqt-session. Here are partial outputs of pstree:
        │                        └─lxqt-session─┬─
        │                                       ├─tmux: server───zsh
  1. Log out of the LXQt session
Context

I wanted to observe how proccese are killed #374 by running journalctl --follow in tmux.

System Information
  • Distribution & Version: Arch Linux
  • Kernel: 5.10.28
  • Qt Version: 5.15
  • liblxqt Version: git
  • lxqt-build-tools Version: git
  • Package version: git
@tsujan
Copy link
Member

tsujan commented Apr 10, 2021

Check how other desktop environments work?

I think other DEs may do nothing, other than stopping some of their own processes. I've seen Gnome/KDE processes that persisted after logging out of them (and took lots of CPU time until I killed them in LXQt). That's not what we want.

IMHO, #374 is an elegant and clean solution. A list that can be edited/provided by the user and also a few hard-coded exceptions might solve this problem.

@stefonarch
Copy link
Member

I think starting processes that are thought to survive the session is a dev-only thing - an average user doesn't do it.

@palinek
Copy link
Contributor

palinek commented Apr 10, 2021

We have few options here I can imagine now:

  1. create a specific whitelist/regexp configuration of app names in session configuration
  2. in lxqt-session examine some flag of the process (easiest way for linux would be to examine env. vars of the process and in case some well defined variable exists...let the process alone; the drawback here is, that in BSD I don't know about the possibility to examine env. vars of other/child process)
  3. in lxqt-session check the "well-defined" env. var for whitelist/regexp app names (most easy portable implementation - configuration of env. vars for session is done; but a bit hidden for the end user)

For now the easiest way is to let the "parent" process of "need to live" process to be alive and that should ignore the TERM signal -> then our "need to live" process will survive, e.g.:

#/bin/bash
trap 'DUMMY=1' TERM

# start the requested process
"$@"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants