There is no way, but to prevent this I like using tmux. I start tmux, start the operation and go on my way. If I return and find the connection has been broken, all I have to do is reconnect and type tmux attach.

Here's an example.

$ tmux
$ make <something big>
......
Connection fails for some reason
Reconect

$ tmux ls
0: 1 windows (created Tue Aug 23 12:39:52 2011) [103x30]

$ tmux attach -t 0
Back in the tmux sesion

Step 1: run tmux

Initially, you have a terminal open, with bash running in it. I'll call this the original bash.

You run tmux from the original bash. Tmux runs two processes: the tmux server and the tmux client. The reason it does that is that you can detach from a tmux session and reattach to it later — this is a core feature of tmux. The tmux client connects to the terminal where the session is attached. The server runs the processes running in the tmux windows. When you detach from a session (C-b d), the client exits, but the server and the processes running in the session keep running. In addition to the two tmux processes, assuming you haven't started a tmux session yet, tmux creates a new session containing one window where it runs your shell: that's the second bash.

At this point, the relevant part of the process tree looks like this:

…
        ├─tmux: server───bash───pstree
        └─xterm───bash───tmux: client

This is from the pstree command on Linux. To get a similar display on macOS, see https://apple.stackexchange.com/questions/11770/linux-ps-f-tree-view-equivalent-on-osx. xterm is the terminal where I ran my original bash, and tmux: client is the tmux client started by running tmux in the original bash. tmux: server is the tmux server that the tmux client started, and its child bash is the second bash, where I ran pstree from.

On Linux, here's the output of ps inside tmux:

    PID TTY          TIME CMD
    108 pts/56   00:00:00 bash
    153 pts/56   00:00:00 ps

By default, Linux's ps only shows the processes that are running on the current terminal. That's why I see. On FreeBSD, and I expect also on macOS (I ran this on a machine where my shell is zsh, that's why it shows zsh rather than bash):

19690  0  Is   0:00.36 /usr/local/bin/zsh
20046  0  I+   0:00.01 tmux: client (/tmp//tmux-1001/default) (tmux)
20049  1  Rs   0:00.06 /usr/local/bin/zsh
20138  1  R+   0:00.01 ps

The reason the BSD ps shows more processes is that by default, it shows processes that are attached to any terminal. (The technical term is processes that “have a controlling terminal”.) It doesn't show processes that are not attached to a terminal at all, such as the tmux server.

To see all the processes involved and to get more information about these processes, let's run ps with a few options. The options to see the relevant data are slightly different on different unix variants. I'll show Linux and FreeBSD; macOS is probably close to FreeBSD but may be a little different. On Linux, here's the output of ps x -o pid,ppid,tty,comm f, filtered to the relevant processes:

    PID    PPID TT      COMMAND
    107       1 ?       tmux: server
    108     107 pts/1    \_ bash
    154     108 pts/1        \_ ps
      3       1 ?       xterm
      6       3 pts/0    \_ bash
    105       6 pts/0        \_ tmux: client

And on FreeBSD, with ps -U $(id -u) -A -o pid,ppid,tty,command -d (on macOS you'll need to remove -d and you won't get the tree presentation) (again filtered; on FreeBSD I'm logged in remotely so the original zsh is in a terminal provided by sshd):

  PID  PPID TTY   COMMAND
19689 19687 -     sshd: gilles@pts/0 (sshd)
19690 19689 pts/0 - /usr/local/bin/zsh
20046 19690 pts/0 `-- tmux: client (/tmp//tmux-1001/default) (tmux)
20048     1 -     tmux: server (/tmp//tmux-1001/default) (tmux)
20049 20048 pts/1 - /usr/local/bin/zsh
20149 20049 pts/1 `-- ps -U 1001 -A -o pid,ppid,tty,command -d

In both case you can see six processes:

• The terminal emulator that provides pts/0.
• The original shell, running in pts/0.
• The tmux client, running in pts/0, started from the original shell.
• The tmux server. It isn't running in a terminal. Its parent (PPID) is process 1. (This happens because when the tmux client starts the server, it double-forks: it creates a child process which itself creates child process, then exits immediately. When the intermediate process exits, the grandchild becomes orphaned and is therefore adopted by init, which is process 1.)
• The shell running inside tmux. It's running inside the single tmux window, which is the terminal pts/1.
• ps running inside the shell inside tmux.

Step 2: kill tmux

You kill the tmux process. But which one? We saw above that there are two. We also saw above that on macOS, ps with no options shows all processes that are running in a terminal. So you saw, and killed, the tmux client. This is equivalent to detaching from the session. The tmux server is still running. That's one of the reasons to use tmux: if the client is killed, for example because the terminal where the client is running goes away, the session keeps running.

Step 3: reattach the session

You can see the existing tmux session with tmux list-sessions. And you can reattach to it with tmux attach. If you have several sessions, you can choose which one to attach to by passing the session number after tmux attach, e.g. tmux attach 0 to attach to the session that tmux list-sessions describes as 0: 1 windows (created …) ….

If you want to kill the session without attaching to it, you can use tmux kill-session. There's even a command tmux kill-server which kills all the sessions.

Step 4: normal exit

When you press Ctrl+D or enter exit in the shell inside tmux, the shell exits. When the main process of a tmux window exits, tmux closes the window. When tmux closes the last window, the session exits.

Try

byobu -S wiki ls

to see if the tmux session is still there. It probably is given your ps output, and will be listed as session 1. Then try

byobu -S wiki attach-session -t 1

Maybe specify the full path to where you can see the "wiki" unix socket that was created when you did byobu -S wiki, which will be in whatever directory you executed that command in originally. Other behavior may occur if byobu or tmux was customized, but basically after you specify byobu -S <path-to-put-socket|path-to-existing-socket-including-socket-name> everything following is going to get passed to tmux. tmux just needs byobu to tell it where to look for its sockets, otherwise it will look in TMPDIR or something by default.

Hope this helps. This is my first ever stackoverflow question that (1) wasn't already answered many different ways, and (2) I knew a possible answer or at least a pointer in the right direction. :)

The answer is much simpler. Just put this in your ~/.tmux.conf file:

# if run as "tmux attach", create a session if one does not already exist
new-session -n $HOST

If you run tmux attach and there is a session, then it will attach to that session (whether it's already attached or not). If there is not a session already then it will create one for you.