mc is timing out waiting for a response from `bash` (the shell it forks for the command line at the bottom of the screen).  You can find the timeout by scrolling through the timestamps.  As per `man select`, the system call in question waits for input on specified file descriptors.  In the successful trace,  FD 7 is created earlier by `pipe()` - it's a pipe to the child process.  In the successful case I found the bash prompt `jon@sonic:~$ ` being successfully read out of the pipe. I don't remember how I found that last, sorry.

Searching for `execv` confirms the pid which writes `jon@sonic:~$ ` is `bash`.  Then I happened to notice `tmux` being started somewhere in the failure case.  **I doubt `mc` likes running `tmux` as a shell!**

**You must have some sort of bash startup script which runs `tmux`.**  It avoids running it if it's already inside `tmux`.  So `mc` inside `tmux` is fine, but not outside.

I would make sure to start `tmux` from a _login_ script, not the scripts which are run for bash sub-shells.  This means `.bash_profile` and not `.bashrc`.  There's some information about this here which matches my thinking: