Spawns another shell (only one term) with WSL2

[OlivierMary]

Hi there,

Just try the new release 3.0.6.

And with WSL2 I have another tmux client.

I had this code at the end of my .zshrc :

if [[ -z "$TMUX" ]]; then
  tmux new-window -n "DIR $(basename $PWD)" -t TMUX
  nbTerm=$(tmux list-clients | grep TMUX | wc -l)
  if [[ $nbTerm -eq 0 ]]; then
    tmux attach -t TMUX || tmux new -s TMUX -n MAIN
  else
   #exit 0;
  fi
fi

I commented the exit 0; to debug why the wsltty windows exited.

So with only one terminal I got a zsh term (not the needed tmux session) and I see a tmux client connected :

if I attach the session I got this:

So another unknow tmux term with low size connected.

That explain why my term exited with the exit 0; but that code work since a long time.
I can change the code to keep 2 clients but that broke the size of all automatic initialized tmux sessions. I have to kill 'TMUX' session and recreate it, not a good deal...

[Biswa96]

Does it also happen with WSL1? What does happen in CMD and wsl.exe?

[mintty]

What exactly do you claim about the terminal? I see smaller font size in the screenshot but it could simply be a matter of presentation. Whatever behaviour you are reporting, is it different with a previous version of mintty/wsltty? Can you demonstrate it without zsh please, and maybe even isolate it from using tmux? Otherwise at least a screen log would be helpful.
Please understand it is really hard to deal with fuzzy incident reports that would require to create a certain test environment first...

[OlivierMary]

Does it also happen with WSL1? What does happen in CMD and wsl.exe?

WSL1 and wsltty 3.0.5 no problem with same code.

@mintty
Same with chsh /bin/bash

and no .bashrc

PID 34 ?

[Biswa96]

WSL2+CMD: I appended the code in .zshrc file and use chsh -s /usr/bin/zsh to change zsh as default. tmux list-session shows TMUX: 1 windows. But ps -aef | grep tmux shows two tmux processes. Any special config in .minttyrc file?

[OlivierMary]

So you reproduce, 2 process, when you attach to current session you get the low resolution tmux ?
No special config in .myttyrc

[OlivierMary]

Hum on my WSL 1 and wsltty 3.0.5 I got this:

2 process but 1 client and in good tmux session.

I didn't say it but no problem on WSL2 without wsltty

[OlivierMary]

In my .zshrc I test list-clients not list-sessions

[OlivierMary]

• add the code at the and of your .zshrc
• chsh /bin/zsh
• exit all term + restart lxmanager service if you want to be sure.
• start a terminal
• you must be in tmux session named TMUX with one window called MAIN and you must be the only one client

on WSL 1 + wsltty 3.0.5 you must have that:

I got the same on WSL 2 without wsltty

and this issue, so on WSL 2 + wsltty 3.0.6 I got
you got an zsh promt not in tmux and if you connect/attach to tmux session you get

[Biswa96]

Understand. I did every steps that you have provided but can not see any defect in case of WSL2+wsltty.

[OlivierMary]

Ok,

Cannot now (no wsl2 on this PC), will try it at home later

[mintty]

In the video, I see you have a full-screen terminal, later start another terminal window, and resize it to full-screen.
I am asking, AGAIN:
What is actually wrong? From a mere terminal point of view, without any background about tmux or whatever you may do, what do you claim about mintty behaviour?
If you do not clarify on this basic question, I can only close the issue.

[OlivierMary]

the video it's on WSL 1, I said on WSL 2 I got this:

that can only happen if another client is running with lower size than my terminal.
And this client it's not a visible terminal/client/pts/tty

[mintty]

How do you leave the initial tmux session? With ^D/exit or by closing the terminal window?

[OlivierMary]

When I do the test I reset lxmanager so I kill all wsl process

[mintty]

Which may well cause zombie processes to remain.
So why do you do that? What happens if you simply exit tmux normally in all test steps, to compare?

[OlivierMary]

I do that cause exit do the same..., on a fresh reboot that do the same too...

[mintty]

Don't understand. When you terminate a process with exit, it will be properly cleaned up. When you force-close it by killing itsk platform, it may not. Particularly with tmux, it's its purpose to catch that and not terminate, so you shouldn't be surprised that you're left with pending processes.
I'd say behaviour is absolutely normal as far as described.

[OlivierMary]

I said, what ever you do to close the term exit/ctrl+d/close windows/restart lexmanager service, have the same issue the result is wrong with wsl2+ mintty 3.0.6 and good with wsl1 + mintty, wsl1 without mintty, wsl2 without mintty

[mintty]

OK, it is possible that closing a tmux session behaves differently in WSL 2 for some obscure reason.
I do not see any relation to the terminal, however.

[OlivierMary]

It's just running with wsl2 + mintty open 2 tty client for one windows.

[mintty]

Let me try to interpret: You want 2 mintty windows for a WSL 2 distribution, with tmux running in each?

[OlivierMary]

No.

Today with WSL 2 + mintty I have:

• only 1 mintty window
• 1 tty connected with my default sh --> for me zsh running run tmux automatically
• 1 tty (the tty that I see) with only zsh (not in Tmux cause of my code + already one tty on tmux)

I want:

• only 1 mintty window
• 1 tty (the tty that I want to see) connected with my default sh --> so for me a zsh with tmux started automatically

I think you can see it with zsh/zsh+tmux/bash like my morning's comment:

In this example I don't want PID 34.

[mintty]

As a side note, if you always want tmux to wrap your session, you could perhaps set it up as your shell; or you could exec tmux to save your outer shell level.

Let us isolate a minimal test case. You login (start WSL), no .zshrc magic, invoke tmux explicitly, leave its shell with exit (or detach?), leave the outer shell with exit. You login again and find your detached tmux session, whatever. Then with WSL 2 it's somewhat different. Can you try to analyse your issue on that level please.

Anyway, as I said, I don't see any relation to the terminal. Just curious what could make such trouble in your exotic setup.

[OlivierMary]

that is my test with bash no ? chsh with /bin/bash I get 2 bash pts client

[OlivierMary]

And that without any .bashrc

[OlivierMary]

with default shell /bin/bash for me I must start a fresh wsltty and get only one bash process when i do ps -aef |grep bash

If I'm wrong tell me.

[mintty]

Normally, yes. So with WSL 2 you get 2 bash processes already?

[OlivierMary]

Yes,

Just after a boot I recorded this with bash as default shell:

[OlivierMary]

And same WSL2 but without mintty I have this:

[LumaKernel]

[LumaKernel]

Sorry for confusing, with newer Windows account (name: neko), I forgot to switch the WSL version.
I switched and checked the problem also happens in the clear environment.

log

Microsoft Windows [Version 10.0.19608.1006]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\neko\AppData\Local\wsltty\bin>wslbridge2
dog@MyComputer:/mnt/c/Users/neko/AppData/Local/wsltty/bin$ rm ~/.log
dog@MyComputer:/mnt/c/Users/neko/AppData/Local/wsltty/bin$ exit
exit

C:\Users\neko\AppData\Local\wsltty\bin>wslbridge2
dog@MyComputer:/mnt/c/Users/neko/AppData/Local/wsltty/bin$ cat ~/.log
.bashrc:68:dog:80:25:/home/dog/.bashrc:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/ProgramData/scoop/shims:/   64     1 /init
   65    64 /init
   66    65 /mnt/c/Users/neko/AppData/Local/wsltty/bin/wslbridge2-backend --cols 80 --rows 25 --port 60747 --
   68    66 /bin/bash
   75    68 ps xao pid,ppid,cmd
----
::interactive
.bashrc:51:dog:80:24:/home/dog/.bashrc:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
----
  PID  PPID CMD
    1     0 /init
   49     1 /init
   50    49 /init
   51    50 -bash
   64     1 /init
   65    64 /init
   66    65 /mnt/c/Users/neko/AppData/Local/wsltty/bin/wslbridge2-backend --cols 80 --rows 25 --port 60747 --
   68    66 /bin/bash
   89    51 ps xao pid,ppid,cmd
----
::interactive
dog@MyComputer:/mnt/c/Users/neko/AppData/Local/wsltty/bin$
dog@MyComputer:/mnt/c/Users/neko/AppData/Local/wsltty/bin$ echo $$
68

[LumaKernel]

[mintty]

Actually WSL2 was already mentioned in the issue title; I changed it according to current analysis.

[seowalex]

I'm having the same problem after upgrading to WSL2. Any way I can assist the troubleshooting process?

> tmux list-clients
/dev/pts/0: wsl [80x24 xterm-256color] (utf8)
/dev/pts/2: wsl [174x45 xterm-256color] (utf8)

[mintty]

@Biswa96, it is related to the "$(wslpath -u ...)". If I replace that with a fixed string as an experiment, it does not happen. I'll check how we can do without it in general.

[seowalex]

Thanks for the quick reply. In the meantime, is there any workaround possible?

[mintty]

No; the issue is not really severe.

[LumaKernel]

@seowalex
(For reference:

Depending on the situation, but my dirty workaround (deleted, it is now fixed!) works for me so far. In general, find a difference, think of it as a premise and return early.
)

[wjrogers]

I have the same problem with Ubuntu 18.04, WSL2, wsltty 3.2.0. I noticed it because sometimes tmux would not read its config, and I couldn't figure out why. I start tmux in .bashrc with exec tmux new, and I also use keychain. At startup, I see this:

~ $ pstree
init─┬─init───init─┬─ssh-agent
     │             ├─tmux: client
     │             └─tmux: server─┬─bash
     │                            └─bash───pstree
     ├─init───init───wslbridge2-back───tmux: client
     └─{init}

I added these lines at the beginning of my .bashrc (thanks @LumaKernel):

# work around https://github.com/mintty/wsltty/issues/197
if [[ -n "$WSL_DISTRO_NAME" ]]; then
  command -v cmd.exe > /dev/null || return
fi

and now I see this at startup, which fixes all practical problems I was having:

~ $ pstree
init─┬─init───init───bash
     ├─init───init─┬─ssh-agent
     │             ├─tmux: server───bash───pstree
     │             └─wslbridge2-back───tmux: client
     └─{init}

[wjrogers]

In case the comparison helps, this is what the process tree looks like when I open an Ubuntu terminal in Windows Terminal:

/mnt/c/Users/wjrog $ pstree
init─┬─init───init─┬─ssh-agent
     │             ├─tmux: client
     │             └─tmux: server───bash───pstree
     └─{init}

[mintty]

That "workaround" does not change anything for me. Also, the issue is sufficiently narrowed down for further handling.

[seowalex]

Any updates on this issue?

[mintty]

Updates would appear right here.

[OlivierMary]

Hi,

That progress in investigation but it's still invalid issue?

[mintty]

It's a wslbridge2 issue but that's a component of wsltty, so that assessment wasn't quite proper.

[mintty]

I have made a local patch to wslbridge2, allowing option -b to accept a WSL path so that it does not involve wslpath in that case. Unlike my previous observation, that does not help.

[michaelrommel]

# work around https://github.com/mintty/wsltty/issues/197
if [[ -n "$WSL_DISTRO_NAME" ]]; then
  command -v cmd.exe > /dev/null || return
fi

I had this issue as well, which prevented me from building a npiperelay between an OpenSSH Authentication Agent on the windows side and consumers of the SSH_AUTH_SOCK on the Linux side. Only thing I changed, was to replace return with exit, which also terminates the bash shell.

[mintty]

Thanks for the hint, I added it to the wsltty project page.

[michaelrommel]

Thanks! For those who wonder, here is the whole shebang for getting the Windows OpenSSH Authentication Agent service connected to WSL2, I have that sourced from my .zshrc / .bashrc:

  AGENTS=($( /bin/ls -1 2>/dev/null /tmp/ssh-agent-*.sock |tr 2>/dev/null "\n" " " ))
  FOUND=0
  for AGENT in "${AGENTS[@]}"; do
    if [ $FOUND -eq 0 ]; then
      OWNER=$(ls -l "$AGENT" |awk '{print $3}')
      if [[ "$OWNER" == "$USER" ]]; then
        [[ ${DEBUG} == true ]] && echo "Trying agent $AGENT"
        export SSH_AUTH_SOCK=$AGENT
        if ! ss -a | grep -q "$SSH_AUTH_SOCK"; then
          # stale agent socket
          [[ ${DEBUG} == true ]] && echo "Removing stale agent $AGENT"
          rm -f "${AGENT}" "${AGENT}.log"
          unset SSH_AUTH_SOCK
        else
          FOUND=1
        fi
      fi
    fi
  done

  if [ -z "$SSH_AUTH_SOCK" ]; then
    # we need a new relay
    [[ ${DEBUG} == true ]] && echo "Launching ssh-agent relay"
    export SSH_AUTH_SOCK=/tmp/ssh-agent-$$.sock
    rm -f $SSH_AUTH_SOCK
    ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,umask=007,fork \
                   EXEC:"/mnt/d/ProgramFiles/npiperelay/npiperelay.exe -ei -s \
                   -v //./pipe/openssh-ssh-agent",nofork &
    ) >${SSH_AUTH_SOCK}.log 2>&1
  fi

  [[ ${DEBUG} == true ]] && echo "Checking for ssh keys"
  ssh-add -l >/dev/null 2>&1
  RC=$?
  if [ $RC = 1 ]; then
    # keys are still missing, though
    [[ ${DEBUG} == true ]] && echo "Adding default ssh keys.."
    ssh-add ~/.ssh/id_ed25519 ~/.ssh/id_rsa
  fi

This is a slightly modified version of the example given in the wsl-ssh-agent repo. As mentioned there you will need npiperelay.

This complicated version uses dynamically allocated ssh-agent-sock names. I wrote that, because of the superfluous shell discussed in this issue, where the fixed socket was blocked and the startup hung. Maybe with the workaround from wjrogers the original proposal would now also work.

[Biswa96]

I think I have fixed this issue. Compile wslbridge2 or download the binaries from Appveyor CI artifacts. The issue was nothing fancier. I just forgot to close the sockets, one of my typical programming mistakes.

[mintty]

Released 3.4.1.