feature: improve error messages#162
Merged
Merged
Conversation
Previously a failed execvpe surfaced only "execvpe failed", discarding errno entirely. Capture errno immediately and include it along with the program name, plus actionable hints for the common ENOENT (wrong PATH or argument order), EACCES, and ENOEXEC cases.
setrlimit failures reported only "failed to set resource limit" with no indication of which limit or why. Include the resource id and the errno string from the OS.
Setting the hostname previously reported a bare "failed to set hostname" and panicked if a user-supplied hostname contained a NUL byte. Include the errno and the offending hostname, and return an error rather than panicking on an invalid (interior-NUL) hostname.
A config with no executable panicked with "expected executable to be configured". Since the executable comes from user-supplied config, return a clear error instead of aborting the process.
capget reported only "capget(2) failed", and capset printed the syscall return value (always -1) rather than the actual errno. Both now include the OS error string; capset keeps the cap masks as labelled context.
When the runner exited via a signal, status.code() is None and the error was a generic "failed to launch/monitor child process". Report the runner path and the exit status (which renders the signal on unix). The exec() path now names the runner and includes the underlying io::Error.
"unable to pivot root" and "unable to unmount old root" gave no reason. Include the errno string so failures (e.g. EINVAL from a non-mountpoint target) are diagnosable.
Mount data comes from user config and could contain an interior NUL byte, which made CString::new(...).unwrap() panic. Propagate a descriptive error naming the data and target mount point instead.
The styrolite binary panicked on ordinary user mistakes: a missing config path argument and a nonexistent config file. Return clean errors (with a usage hint and the offending path), and attach the file path as context to config read/parse failures.
"styrolite exec failed" was misleading: runner.exec() replaces the process on success and propagates a descriptive error on failure, so this fallback is never expected. Name the runner and state what happened.
The async feature pulled in tokio with no features enabled, so tokio::process was unavailable and any build with --features async failed to compile (run_async could not construct a tokio::process::Command). Route tokio/process through the async feature so it is enabled exactly when async is.
Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
azenla
approved these changes
Jul 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
also while here, fix building async features outside protect