Pretty cool use of ptrace.

When I start long running jobs, I try do start them that way, so I can check on them (and their output in a screen logfile) from anywhere:

screen -L -Logfile "batch-xyzzy-221005a" -S "xyzzy1" bash job.sh

Now I can just check the log with grep or less, or reattach to it if some action is needed.

Interesting. So far, my only ever use of disown was to decouple GUI apps that I launched from the terminal. I do that automatically now, as it's annoying when you forget, close the terminal, and a bunch of apps go away.

> The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. [...] To prevent the shell from sending the SIGHUP signal to a particular job, it should be removed from the jobs table with the disown builtin (see Job Control Builtins) or marked to not receive SIGHUP using disown -h.

> If the huponexit shell option has been set with shopt (see The Shopt Builtin), Bash sends a SIGHUP to all jobs when an interactive login shell exits.

https://www.gnu.org/software/bash/manual/html_node/Signals.h...

I think I remember in Linux many years ago (more than 15, maybe) the behavior was present in shells spawned from your DE, but I may be wrong.

    nohup <gui-app> &

?

There are various ways to get ahead of this problem too if you ssh into a tmux session automatically. There are various ways to achieve this.

I didn't know about reptyr, it's very cool. There were times I wished this was possible, but whenever I searched for a solution I got "It's not possible". Oh well...

  ssht() {
      ssh -t $1 'tmux a || tmux'
  }

  # Open new pane or window with the current directory
  bind '"' split-window -c "#{pane_current_path}"
  bind % split-window -h -c "#{pane_current_path}"
  bind c new-window -c "#{pane_current_path}"

  autossh -M 0 -t remote "tmux new-session -A -D -s $RANDOM$RANDOM$RANDOM$RANDOM"

Remote pair coding made fun again!

    $ reptyr 10330                                                                                                                                                
    Unable to attach to pid 10330: Operation not permitted 
    The kernel denied permission while attaching. If your uid matches
    the target's, check the value of /proc/sys/kernel/yama/ptrace_scope.
    For more information, see /etc/sysctl.d/10-ptrace.conf
    $ 

# echo 0 > /proc/sys/kernel/yama/ptrace_scope

or permanently by editing the file /etc/sysctl.d/10-ptrace.conf

> What are the risks in setting ptrace_scope to 0?

> - This restores the old behavior where one process can "trace" another process, even if there is no parent-child relationship.

> - In theory, a piece of malware can use this to harm you/your computer; e.g. it can attach to Firefox and log all of your URLs/passwords, etc. In practice this is extremely unlikely unless you blindly install binary debs from random sites, etc.

> - As far as debugging goes, the 0 settings is in fact required for gdb, strace, etc. to attach to non-children unless you run them with elevated privileges (sudo).

In practice I have it via bash alias `tma` , not long command as described. Until I can't bring my .bashrc to particular server of course - there long one, may try your suggestion though

By the way another approach is of course to use VNC (e.g. some process started in an xterm at work you can access by opening your entire desktop at home.)

kitty probably has some abilities to do this easily from the shell, as it has all sorts of abilities to interact programmatically with the scrollback history.

How about starting tmux by default inside a terminal, rather than running the shell directly inside the terminal?

Of course, an ssh session would also need to start tmux.

https://mosh.org/