On Sat, 28 May 2016 14:49:41 -0400 Joey Hess <i...@joeyh.name> wrote: > Since the number of commands that start such a process is limited to > screen/tmux/nohup, these could just be shimmed to do whatever's > needed to let them keep running past logout. > > Course it would make more sense to have a proper API that such programs > can use themselves. > > I have tried to develop such a shim: > > #!/bin/sh > cmd="$(basename "$0")" > # hardcoded path so this shim can be in eg ~/bin/screen and run the real > program > systemd-run -q --scope --user /usr/bin/$cmd "$@"
I don't think systemd-run (or transient scopes in general, including those created by the program natively) are the right solution to this problem. Instead, I think screen, tmux, a VNC server, or any other command that runs a user session independent of the one it was called from, should be invoking PAM to start a new session. The PAM session machinery would then run pam_systemd, which would register with logind. PAM is the right way to start a new user session. And in addition to providing a solution that isn't systemd-specific, this also integrates with any other session mechanism as well. For instance, if you use PAM to manage agents for SSH or similar, this solves the problem of screen having SSH_AUTH_SOCK point to a stale SSH agent that died with the session screen started from. I would suggest adding PAM session support to screen.
