Remote server SIGABRTs on old kernels (CentOS 6 / 2.6.32): getrandom returns ENOSYS

Problem

After a recent Zed update, remote SSH to a CentOS 6.6 server (Linux kernel 2.6.32) broke: the client hangs on the yellow "connecting" state forever. Servers with modern kernels connect fine.

What's actually happening

The remote binary downloads and runs fine — zed-remote-server-… version prints 1.18.1 with no linker errors. The crash happens the moment the client connects and the server tries to set up its IPC session.

strace on the remote host shows the exact failure:

[pid 15048] syscall_318(0x7f7eb10e6f90, 0x20, 0, 0, 0, 0) = -1 (errno 38)
[pid 15048] tkill(15048, SIGABRT)
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=15032, si_uid=0} ---
+++ killed by SIGABRT +++

• Syscall 318 on x86_64 Linux is getrandom(2)
• errno 38 is ENOSYS — getrandom was added in Linux 3.17, and kernel 2.6.32 doesn't implement it
• The Rust runtime treats the entropy failure as unrecoverable and aborts the whole process

On the client side this surfaces as stdout_task failed: failed to read message from stdout: unexpected end of file, followed by an endless reconnect loop.

Regression

This setup worked fine until a couple of months ago. Older remote server builds clearly fell back to /dev/urandom when getrandom returned ENOSYS; a recent dependency update seems to have made the syscall mandatory.

Ask

Please handle old kernels gracefully again — either:

1. Fall back to /dev/urandom when getrandom returns ENOSYS, or
2. At minimum, fail with a clear, human-readable error ("remote host kernel too old: getrandom syscall not supported") instead of a silent SIGABRT plus an infinite client reconnect loop.

Environment

• Zed client: 1.18.1 (Windows)
• Remote host: CentOS 6.6, Linux 2.6.32, x86_64
• Remote binary: zed-remote-server-stable-1.18.1