Skip to content

fix(daemon): make the data directory before logging into it - #15

Merged
meocong merged 4 commits into
masterfrom
fix/background-first-run
Aug 14, 2026
Merged

fix(daemon): make the data directory before logging into it#15
meocong merged 4 commits into
masterfrom
fix/background-first-run

Conversation

@meocong

@meocong meocong commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

summo serve --background failed on a machine that had never run Summo:

Caused by:
    No such file or directory (os error 2)

The log a background daemon writes lives in ~/.summo, and on a fresh install nothing has made ~/.summo yet — the background start is itself the first thing that touches it.

Found by unpacking the released tarball and pointing it at an empty home, which is the only case where it happens, and the case every new user is in.

🤖 Generated with Claude Code

`summo serve --background` on a machine that has never run Summo failed with a bare
"No such file or directory": the log file is created inside `~/.summo`, and on a fresh
install nothing had made `~/.summo` yet. Found by running the released tarball against
an empty home, which is the only situation in which it happens — and the first thing a
new user does.
`full-flow` failed with "libsherpa-onnx-c-api.so: cannot open shared object file" on a
run whose only change was a one-line fix in the daemon. The binary is linked with an
`$ORIGIN` rpath, which is right for the shipped bundle where the libraries sit beside
the executable; out of `target/debug` it works only because Cargo copies them there
while the build script runs, and on a warm cache the build script does not run.

Cargo's own `deps/` always has them, so the harness puts that on the library path.
Reproduced by moving the copies out of `target/debug` — the daemon then failed to start
exactly as it did on CI, and passed with this.
The previous commit inserted a helper between `export` and `async function boot`, which
exported the helper and left `boot" unexported — `assistant.mjs` imports it by name and
died on a module error. Caught by running the whole suite rather than the one test the
change was about.
`full-flow` has been failing with "libsherpa-onnx-c-api.so: cannot open shared object
file" on runs that changed nothing near it. The library is put beside the binary by the
crate's build script; a warm cargo cache skips the build script, and the `$ORIGIN` rpath
then points at a directory with nothing in it. The harness now also puts `target/debug`
and its `deps` on the library path, which covers the local case, and this covers the one
where the file is not in the target directory at all.
@meocong
meocong merged commit e421407 into master Aug 14, 2026
10 checks passed
@meocong
meocong deleted the fix/background-first-run branch August 14, 2026 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant