Repository: deno
Issue: Language server exits abruptly when run in a Docker container
Labels: bug,lsp

Version: Deno 1.39.4

## Environment

aarch64 linux
Docker For Mac
macOS Monterey 12.6.1
Macbook Pro (M1 Max)

## Issue

When containerized, `deno lsp` runs with i/o working initially before exiting with exit code 1 after a number of seconds.

## Details

It should be possible to run the `lsp` command within a container and use it either within that container or from the host of the container.  This would be desirable to me because it would allow the VS Code extension to rely on the same Deno binary being used by the containers for my application, allowing me to scope versions of Deno to my projects.

Here is an [example implementation](https://github.com/Ravenstine/deno-lsp-docker) of what I'm talking about which reproduces the issue.  Instructions are included in that repo.

In VS Code, go to **View > Output** to and select "Deno Language Server" to observe the output, which I've configured to be more verbose in the settings file for the workspace.

What you'll witness is that the containerized language server actually works for several seconds before exiting and being restarted by the extension until it stops at 5 crashes.  In the `main.ts` file, you can see that hovering over the code will show language information depending on whether the language server is in a good state or is starting or crashing.  I have the Deno extension turned off globally, so I know that it's not accidentally filling in when the instance in the workspace fails.

So far, I can't tell why `lsp` would have any problem in this situation.

I did an experiment where, in the path of execution, I added a Deno script that pipes to and from the actual `lsp` command (using a subprocess) in order to see whether Deno is the source of the problem or Docker.  The result is that the `lsp` command is returning an exit code of 1 with no other information, and there's nothing about Docker that is spontaneously exiting or whatever.  If that were not the case, then the main process of my intermediary script should have exited, but only the subprocess exited.

The way Docker handles volumes also does not appear to be a factor.  Upon modifying the project to not use volumes but copy the project contents into the Docker Image, and then rebuilding, the problem still occurs.

I have tried different versions of Deno (going back to 1.37) as well as different Docker image variants (Debian, Alpine, Ubuntu, Distroless, etc.) to similar effect.  Using an Alpine base image for aarch64 and installing Deno from the Alpine repo also does the same thing; though in that case it seems like `lsp` is a bit longer-lived before it exits abruptly.

If what I'm trying to achieve currently isn't supported, I think it's a legitimate use case that should be considered.  At the moment, I don't have any reason to believe that Docker is the source of the issue other than that it's the environment in which the issue can be reproduced; plenty of software can run identically in containers and receive i/o without unique difficulties.

UPDATE: The only Deno version I've tried that doesn't seem to encounter any issues with `lsp` in Docker is v1.10.3.  That's as far back as I can go in terms of pre-built Docker images.  The next version, v1.11.0, has what seems like a similar abrupt exiting issue.