More nonzero exit codes when trying to exit a WSL instance lately

[sirredbeard]

User reports increased frequency of non-zero exit codes when exiting WSL in Ubuntu 18.04:

Second user confirms in Pengwin.

I am re-directing conversation here.

Aaron and Stephen could you please provide steps to reproduce?

Aaron I see in your screenshot that you have SSH'd into a remote server, shut it down, and then exited that shell. I am curious how did you spawn that shell though?

When I exit a shell in Windows Terminal it normally closes the terminal. Are you launching it in Windows Terminal? With a custom entry by chance? What do you have in the Windows Terminal entry for that shell?

[valorin]

I can reliably reproduce [process exited with code 130] on Pengwin. It seems to happen when I use Ctrl+c in a session and later try to close the session.

Steps:

1. Open window/tab
2. Start some ongoing process, such as tail -f
3. Press Ctrl+c to cancel the process
4. Press Ctrl+d to quit the session

The session stays open, and displays [process exited with code 130] instead of quitting.

valorin@Pengwin:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Pengwin
Release:        11
Codename:       bullseye

{
    "guid": "{7f586916-8357-53d4-bb2b-ca96f639898a}",
    "name": "Pengwin",
    "commandline": "wsl.exe ~ -d WLinux",
    "icon": "ms-appdata:///roaming/pengwin.png",
    "backgroundImage": "ms-appdata:///roaming/dark-pengins.png",
    "source": "Windows.Terminal.Wsl"
},

In case it's helpful, I don't have any Terminal keybindings set for the letters d, or c.

[sirredbeard]

@valorin

Does the behavior change when you omit "commandline" and change "name" to "WLinux"?

{
    "guid": "{7f586916-8357-53d4-bb2b-ca96f639898a}",
    "name": "WLinux",
    "icon": "ms-appdata:///roaming/pengwin.png",
    "backgroundImage": "ms-appdata:///roaming/dark-pengins.png",
    "source": "Windows.Terminal.Wsl"
},

I know why you did that, just curious if the change is because you are calling it by wsl.exe instead of the name.

[valorin]

No difference in behaviour @sirredbeard. I also realised I can replicate by clicking Ctrl+c without running a process. The mere act of hitting Ctrl+c causes the code 130.

I just tried using the raw Pengwin console, instead of Windows Terminal and was unable to replicate. So it only happens within Windows Terminal. I'm on Version: 0.10.761.0 right now, but I updated it only yesterday from v0.9.something and I have been getting the code 130 error for the past few weeks. (I can't remember exactly when it started.)

[valorin]

I also just confirmed the same code 130 error on my Ubuntu 18.04, Debian, and Kali instances. All are WSL2, installed from the store, and updated using apt periodically with no system changes I can think of.

[sirredbeard]

I can reproduce the code 130:

By calling Ubuntu via the command line method you are using:

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu via wsl.exe",
                "commandline": "wsl.exe ~ -d Ubuntu",
                "source": "Windows.Terminal.Wsl"
            },

But not when Ubuntu or other distro is called this way:

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl"
            },

Repeated same with my Ubuntu 20.04 test image:

            {
                "guid": "{4ac2e77b-9dac-50fa-9c00-39e6b455b32b}",
                "hidden": false,
                "name": "Ubuntu2004 via wsl.exe",
                "commandline": "wsl.exe ~ -d Ubuntu2004",
                "source": "Windows.Terminal.Wsl"
            },

But not:

            {
                "guid": "{4ac2e77b-9dac-50fa-9c00-39e6b455b32b}",
                "hidden": false,
                "name": "Ubuntu2004",
                "source": "Windows.Terminal.Wsl"
            },

Can you post your profiles.json?

I suspect this is some interaction between how WSL is being launched within Windows Terminal.

[valorin]

I don't think this is a WSL bug - or at least my code 130 isn't. I just did a Ctrl+c in my Git Bash console (C:\Program Files\Git\bin\bash.exe) and it threw the same error code. So it looks to me like a Windows Terminal bug.

It will be interesting to see if Aaron's error is linked to Terminal like mine, or something completely different.

[valorin]

Looks like it's the intended Windows Terminal behaviour: microsoft/terminal#4223

[akulbe]

@valorin @sirredbeard I haven't been able to consistently reproduce this bug, so I'm not sure… but I looked at microsoft/terminal/#4223 and it just doesn't seem right for ^D to not work for Linux-in-WT… because it works in Terminal-on-Linux, that way… so why not here???

[akulbe]

Put a copy of my profiles.json up.

[valorin]

The cause in my case is that WT detects an error code was returned by the last command. So when you click ^D and it goes to close the tab, it checks for an error code from the last command first. As of v0.8, WT prevents itself from closing a tab when there is an error code, to avoid the problem where the tab throws an error when it's first launched. If it auto-closed, a broken profile would open and close quickly and you'd miss the error code.

It may be different in your case, but in every test I ran, it always displayed the error when the last command didn't close cleanly.

[valorin]

One of the discussions in the WT issues explains that the gnome terminal handles the ^D differently than they can in WT. Hence the different behaviour. I'll try to find it for you when I'm back at my computer.

[valorin]

Ah this is the comment I'm thinking of: microsoft/terminal#4223 (comment)

[DHowett-MSFT]

Just for the record, it isn’t related to WT “handling” Ctrl+D differently. Terminal tracks exactly one process and reports on its exit code. In all WSL cases, that process is wsl.exe. It doesn’t go digging to find your shell, or the last command you ran.

Your shell is reporting, by using exit(130);, that it is exiting with code 130. wsl.exe dutifully reports that exit code, and Terminal receives it.

This is how bash, zsh and a number of other shells report their exit statuses when the last command was unsuccessful either through its own failure or through the user pressing ^C.

[dseven]

@DHowett-MSFT , I wonder if it could be possible to allow the user to specify a list of exit statuses to be considered "fatal", and close the tab if none of those is observed?

[yveslange]

I have set "closeOnExit": "always" and it seems to be ok. I would maybe switch back if anything suspicious is happening or to debug my terminal.

[knuth-konrad]

Thx to both @DHowett-MSFT and @yveslange . The former for explaining why this happens (and that it "works as intended"), and that I didn't broke my WSL installation somehow. The latter for providing a means to handle it the way that suits my needs.

[hakuno]

@yveslange That did the trick.

[tijko]

As noted previously I can confirm having the "C:\Users\tkonick\AppData\Local\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json" field of "closeOnExit": "always"