Make timeout configurable

報告された起動コマンドを再現することから始め、summary に記載された2つの領域である、内部プロセスの spawn と WebSocket の timeout 処理を追跡します。完了の条件は、両方の timeout を設定可能にし、起動時のケースが不適切なデフォルト timeout だけを理由に終了されないことです。

Edit: Summary of timeouts to make configurable:

• Inner process spawn
• Web socket

Original issue:

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Chrome
• Local OS: Windows 10
• Remote OS: Ubuntu 22
• Remote Architecture: x86_64
• code-server --version:

4.14.1 5c199629305a0b935b4388b7db549f77eae82b5a with Code 1.79.2

Steps to Reproduce

1. Install the code-server version above, and launch it using this command: /usr/lib/rstudio-server/bin/code-server/bin/code-server --verbose --host=0.0.0.0 --port=40400 --disable-getting-started-override --disable-update-check --disable-telemetry

Expected

code server should start as expected on port 40400

Actual

The following error messages are spawned:

[2024-07-24T15:47:42.792Z] debug parent:3106566 spawned child process 3107105
[2024-07-24T15:47:52.794Z] error timed out
[2024-07-24T15:47:52.795Z] debug parent:3106566 disposing {}

Included a strace of the startup:
108342_2024-08-05-14_18_30_24Jul24Codeserver.log

Logs

No response

Screenshot/Video

No response

Does this bug reproduce in native VS Code?

This cannot be tested in native VS Code

Does this bug reproduce in GitHub Codespaces?

This cannot be tested in GitHub Codespaces

Are you accessing code-server over a secure context?

• I am using a secure context.

Notes

This was previously working, and the only time-related change that I've been able to identify is a restriction on outbound traffic for most URLs. The only clue I have at the moment is that the way outbound traffic has been blocked doesn't immediately show as connection blocked/no route to host. curl commands to blocked addresses get stuck at Trying and essentially never time out. I've used code-server in a completely offline context, but I'm wondering if there's some unexpected bug or error happening because some outbound connectivity test being executed by a child process just never returns.