The Slipstream server exits with status 255 without reporting a meaningful error when its required certificate files are missing.

[birdie-github]

Steps to reproduce

Download the Linux release binary and place it somewhere such as /opt/slipstream/, without copying the repository's certs/ directory.

Then run:

/opt/slipstream/slipstream-server-linux-x86_64 \
    --domain=example.com \
    --target-address=127.0.0.1:1080

Expected behavior

The server should print a clear diagnostic explaining that the required certificate file(s) could not be found, including the path it attempted to open, and then exit with a meaningful non-zero status.

For example:

Error: unable to open certificate file: /working/directory/certs/cert.pem: No such file or directory

Ideally, the release documentation should also explain that these files are required and where they should be obtained/generated.

Actual behavior

The process simply exits with status 255 and produces no useful diagnostic.

strace shows the actual cause:

openat(AT_FDCWD, "certs/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
exit_group(-1) = ?
+++ exited with 255 +++

This makes the failure look like a generic crash and is particularly confusing when running the server under systemd, where the only immediately visible symptom is:

(code=exited, status=255/EXCEPTION)

The problem is especially easy to misdiagnose as a systemd sandboxing or capability issue.

Suggested improvement

Handle file-opening errors explicitly and report them to stderr/journald, including:

• which file could not be opened;
• the underlying error (ENOENT, EACCES, etc.);
• a concise explanation of what is required to fix it.

The release packaging/documentation should also make the certificate dependency explicit. A standalone release binary currently does not appear to be sufficient by itself because it expects certs/cert.pem (and presumably its corresponding key) relative to the working directory.