WSL Terminal always closes immediately - How to debug

[kmille]

Hey,

my WSL Terminal always closes immediately after starting it and I don't know why or how to debug it. I used wsltty-1.9.6-install.exe to install it. I use the Ubuntu 18.04 Image from the Windows Store on a Windows 10 Laptop.

That's how I call it: H:>%LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~ -V

The config file in "%APPDATA%\wsltty" is emtpy. Can you please help me. I can't go back to the default shell

[mintty]

See the mintty manual page: -V Print version information and exit. Why did you add that option?

[kmille]

Hey that was just a test. I normally run in it without the -V so just %LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~

[mintty]

Add option Hold=always to the config file.

[kmille]

sry for the late response: %LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~ -h=always Should be the same behaviour like using the config. But I tried this before. No error message for me. The window is just closing again...

[mintty]

On the command line, the option is -h always without a =, or -o Hold=always.

[kmille]

[mintty]

Sure I like closed issues :) but that does not look like a solution for you‽

[kmille]

You are right. Sorry

[kmille]

Hey, it's working again. And I don't know why 😄 Probably Windows domain foo magic or Windows Updates ...

thanks for your support!

[kmille]

hm the problem occurs again -:- Any ideas what to do with an immediately closing WSL Terminal?

[mintty]

We've had the Hold option already, at least it should not close then. You should see some error message or other trace of what happens. Is this related to #153, #152? Maybe #135? Or rather #142?

[mintty]

Did you change the WSL mount path configuration? The solution for #91 might not be sufficient...

[kmille]

I will try it and give you feedback

[jrhorn424]

I can connect to other distros fine, but not Alpine.

[mintty]

Reproduced, also when using wslbridge directly from cygwin. Navigating to /mnt/c/Users/.../wsltty/bin and trying to run wslbridge-backend directly also fails with ./wslbridge-backend: not found. That's weird; maybe Alpine has a safety policy not to run programs from Windows mounts? To test the latter assumption, I tried to copy wslbridge-backend into Alpine's /bin but that fails for permission right, also Alpine does not seem to support sudo - maybe it's a "closed shop"?

[Biswa96]

@jrhorn424 From where did you download Alpine? Probable cause, Alpine uses MUSL C library for it's compactness feature. The wslbridge-backend is compiled with GNU C library. So, there is incompatibility between C library. For Alpine, you have to compile the wslbridge-backend from source. This issue may not be related with mintty.

[mintty]

Even though the backend Makefile contains options -static-libgcc -static-libstdc++ already?

[Biswa96]

OK, I explain. When I compiled wslbridge-backend in Debian based distributions readelf -d wslbridge-backend shows:

Dynamic section at offset 0xd2898 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

Now in Alpine, I did this:

• Update & upgrade: apk update; apk upgrade
• Install bash because bash is hard coded in wslbridge: apk add bash bash-completion binutils
• Install pro tools: apk add alpine-sdk build-base gcc g++ make
• Apply this StackOverflow answer because MUSL has issue with strerror_r().
• Make /bin/bash default in /etc/passwd.
• Compile wslbridge-backend in Alpine.
• BOOM!

[jrhorn424]

Thank you, that works for me as well! Very much appreciated.

[kmille]

I still don't get it. It seems like the wslbridge is the problem. I use Terminus at the moment but it's pretty buggy if I use it with tmux. Should I ask at the wslbridge repo?

[mintty]

I've tried to follow Biswa's suggestion and compile wslbridge-backend in Alpine (commented out the strerror stuff) - with no success. You can report it to wslbridge but I wouldn't expect a solution in wslbridge itself (except for the strerror).

[Biswa96]

@mintty Did you install bash in Alpine? Because wslbridge.exe depends on bash.exe which executes /bin/bash only. And Alpine /bin/busybox has not bash. @kmille's issue is different that @jrhorn424. @kmille is using Ubuntu.

[mintty]

OK, right, I overlooked the bash thing in your comment. Got it working. Then I tried to compile statically again, with the error wslbridge-backend.cc:(.text.startup+0x115b): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking This is strange. Anyway, I disabled the getpwuid part and, with -static added to the backend Makefile, it works, i.e. wslbridge-backend compiled with gcc (in "normal" WSL, not Alpine). I could also reenable the strerror stuff. So there is in fact an opportunity to cover Alpine with a common wslbridge-backend binary, if only we find a solution for the getpwuid crap.

And, for that matter, this is not the original issue opened here, but that was fuzzy anyway...

[Biswa96]

wslbridge-backend.cc:(.text.startup+0x115b): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

@mintty That is known issue. See here https://github.com/rprichard/wslbridge/issues/26

[mintty]

I've tried to load getpwuid with dlopen but it did not work...

[kmille]

In the mantime: I works again #yail \o/ I still have no clue but I'm sure it's not a problem of mintty. It's probably caused by our domain foo. Thanks it adavance!

[mintty]

While the original problem (@kmille) may be a different issue, I think the Alpine/wslbridge-backend binary compatibility issue is solved by patching wslbridge-backend. I'll apply a patch that implements getpwuid directly by reading /etc/passwd, so static compilation will work.

[Biswa96]

Isn't static compiling made it bigger binary file? And what is the difference between your patch and glibc implementation of getpwuid?

[mintty]

Size is ~1.7MB rather than 150KB. But it works. My getpwuid only checks /etc/passwd while there are other authentication mechanisms (network/domain controlled).

[mintty]

Released 3.0.1.

[mintty]

Reopened with 3.0.1.2, see #169.

[mintty]

Are there any other distributions that have this problem? If it's only Alpine, we could add an alternative, Alpine-compiled wslbridge-backend to the package, and make a choice based on the selected distribution.

[itsjef]

Are there any other distributions that have this problem? If it's only Alpine, we could add an alternative, Alpine-compiled wslbridge-backend to the package, and make a choice based on the selected distribution.

@mintty I am having the same issue with both Ubuntu 18.04.02 LTS and Debian

[mintty]

With Ubuntu, it's more likely #171. Please check your WSL version (1 or 2) for the distribution.

[itsjef]

@mintty My WSL version is 1, I'm also not participating in Windows Insiders anyway.

[Biswa96]

It may be helpful if wsltty makes -h always a default option.

[itsjef]

Hmm I also added -h always but only got a blank window 🤔

[mintty]

I've installed Ubuntu 18.04 LTS and Debian, run Start Menu → WSLtty → configure WSL shortcuts, and it works for me.

[mintty]

Maybe there are other Windows/WSL changes, applicable to WSL version 1, that impede WSLtty function? Which version do you run?

[itsjef]

@mintty I ran Start Menu → WSLtty → configure WSL shortcuts for both version 3.0.1 and 3.0.1.2 but the problem still occured

[itsjef]

Is there a way I can create a crash log and upload it here so you guys can look into the issue? I think that will help.

[mintty]

Do you see a file wslbridge.exe.stackdump in either your %USERPROFILE%, %LOCALAPPDATA%\wsltty or %LOCALAPPDATA%\wsltty\bin folders? If there is one, we can try to set up something to debug it.

[itsjef]

@mintty I don't, is there an option to turn on stack dump?

[mintty]

If there is no crash happening, that would not help. It seems rather that either the wslbridge frontend or backends is stalled.

[mintty]

You can install a cygwin environment (https://cygwin.com/setup-x86_64.exe). Then, in a cygwin terminal, copy cp $LOCALAPPDATA/wsltty/bin/wslbridge* /bin. Invoke mintty --WSL manually, from a cygwin shell.

[itsjef]

I did it but the terminal still closed immediately. 🤔

[mintty]

closed immediately

You said before you get a blank window. That's not the same symptom. Any output if you force it to stay open with mintty -h alw --WSL?

[itsjef]

When I ran mintty -h alw --WSL, a blank window appeared, if I drop the -h alw then it would close immediately.

Occasionally the window will stay open and I can use it normally but it's very rare 😕

[itsjef]

I'm thinking it's a wslbridge issue. I have tried using goreliu/wsl-terminal but the window also opens and closes at once.

[mintty]

I'm thinking it's a wslbridge issue.

I thought so already but I have no idea how to proceed with analysis, remotely.

Occasionally the window will stay open ...

Oh. Well, WSL sometimes needs a while until startup has settled. If you only wait enough...?