Empêcher la déconnexion de tuer la session tmux

J'ai remarqué qu'une déconnexion (déconnexion) de ma session utilisateur X tuera toutes les tmuxsessions que j'ai lancées, même les sessions que j'avais exécutées sudo tmuxet les commandes similaires. Je suis sûr que cela ne s'est pas produit auparavant, mais un changement récent a affecté ce comportement.

Comment puis-je maintenir ces tmux(ou screen) sessions, même après la fin de ma session X?

— palswim
source

si vous êtes intéressé, unix.stackexchange.com/questions/490243/…

— Tim

De quelle «session utilisateur X» vous déconnectez-vous? Son nom de processus est ...?

— Tim

Bien que je ne pense pas que ce soit particulièrement pratique, vous pouvez démarrer la session tmux en dehors de X, c'est-à-dire sur tty1 comme décrit ici: unix.stackexchange.com/a/167388/67833

— Rolf

Cette «fonctionnalité» existait systemdauparavant, mais les systemddéveloppeurs ont décidé d'effectuer une modification par défaut , pour activer le paramètre de fin des processus enfants lors de la déconnexion d'une session.

Vous pouvez rétablir ce paramètre dans votre logind.conf( /etc/systemd/logind.conf):

KillUserProcesses=no

Vous pouvez également exécuter tmuxun systemd-runwrapper comme celui-ci:

systemd-run --scope --user tmux

Pour ces systèmes, vous pouvez simplement alias la commande tmux(ou screen):

alias tmux="systemd-run --scope --user tmux"

— palswim
source

Discussion supplémentaire dans un fil reddit .

— palswim

… Et dans bien d'autres endroits. Dans le bogue Debian auquel cela se réfère, j'ai expliqué comment on pouvait réellement faire systemd-logindfaire la bonne chose. bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

— JdeBP

@JdeBP Merci de nous avoir dit que l'envoi de SIGHUP au lieu de SIGTERM et SIGKILL permet aux démons de survivre à la fermeture d'une session logind de systemd. Je voudrais aussi apprécierions si vous pourriez aussi envisager unix.stackexchange.com/questions/484344/... et unix.stackexchange.com/a/490435/674

— Tim