A restart does not re-read the log configuration, and a second server cannot be built in one process #113

New issue

Closed

opened 2026-08-13 22:59:43 +02:00 by Claude · 0 comments

Claude commented

2026-08-13 22:59:43 +02:00

Collaborator

M9 named both and left them: a restart rebuilds the server in-process the way upstream's own loop does rather than exec-ing a new one, so log is the one configuration section a restart does not re-read — an operator who raises the log level and restarts from the dashboard gets the old level back. The subscriber is a process-wide global, which is also why a second install in one process fails.

Two ways out, and the choice is the issue: exec a fresh process on restart (upstream's behaviour is closer to this and it makes the whole configuration re-read trivially correct), or make the subscriber reloadable so the global stops being one. The second is more work and keeps the fast in-process restart that was measured at half a second.

The second install case is not academic — it is what a test that wants two servers in one process needs, and it is why the restart path currently cannot be tested that way.

Where to start

crates/jellyfin-server/src/main.rs:59 documents the restart as it stands — the
loop re-reads the configuration file and rebuilds every adapter from it — and
crates/jellyfin-server/src/logging.rs is the exception, because the subscriber
is a process-wide global that can only be installed once.

The choice is the issue, and it should be made explicitly rather than
discovered:

Exec a fresh process. Closest to upstream, makes every configuration
section re-read correct by construction, and costs the half-second in-process
restart that M9 measured.
Make the subscriber reloadable (a reload handle held by the composition
root). More work, keeps the fast restart, and is also what unblocks the second
half of this issue — two servers in one process, which is what a test of the
restart path needs and cannot have today.

How to know it is done

Raise the log level in the configuration, restart from the dashboard button, and
see the new level take effect — measured from the log, not asserted. And a test
that builds two servers in one process without the second failing.

House rules

CLAUDE.md is the short version and these are the parts that bite: tests run
under cargo nextest; upstream's source is the checkout in upstream/ at the
pin (v12.0-rc5, 6d501ba4) and not the clone beside the repository;
generated files are regenerated rather than edited; a comment says what the code
does, not how it got there; and Dn references stay out of code and comments.
ARCHITECTURE.md decides which crate a thing goes in and which dependency edges
are illegal, DECISIONS.md says why a rule exists.

The reference pair is cargo xtask reference up (and reference provision,
which is idempotent); a run is
cargo run -p jellyfin-harness -- replay --upstream URL --ours URL --scenario FILE --out DIR,
with diff-db for the two databases. crates/jellyfin-harness/README.md says
what a diff means and what an ignore entry has to carry — every entry needs a
reason and an expiry milestone, and an adds-only history is the smell the risk
table names.

M9 named both and left them: a restart rebuilds the server in-process the way upstream's own loop does rather than exec-ing a new one, so `log` is the one configuration section a restart does not re-read — an operator who raises the log level and restarts from the dashboard gets the old level back. The subscriber is a process-wide global, which is also why a second install in one process fails. Two ways out, and the choice is the issue: exec a fresh process on restart (upstream's behaviour is closer to this and it makes the whole configuration re-read trivially correct), or make the subscriber reloadable so the global stops being one. The second is more work and keeps the fast in-process restart that was measured at half a second. The second install case is not academic — it is what a test that wants two servers in one process needs, and it is why the restart path currently cannot be tested that way. --- ## Where to start `crates/jellyfin-server/src/main.rs:59` documents the restart as it stands — the loop re-reads the configuration file and rebuilds every adapter from it — and `crates/jellyfin-server/src/logging.rs` is the exception, because the subscriber is a process-wide global that can only be installed once. The choice is the issue, and it should be made explicitly rather than discovered: - **Exec a fresh process.** Closest to upstream, makes every configuration section re-read correct by construction, and costs the half-second in-process restart that M9 measured. - **Make the subscriber reloadable** (a reload handle held by the composition root). More work, keeps the fast restart, and is also what unblocks the second half of this issue — two servers in one process, which is what a test of the restart path needs and cannot have today. ## How to know it is done Raise the log level in the configuration, restart from the dashboard button, and see the new level take effect — measured from the log, not asserted. And a test that builds two servers in one process without the second failing. ### House rules `CLAUDE.md` is the short version and these are the parts that bite: tests run under `cargo nextest`; upstream's source is the checkout in `upstream/` **at the pin** (`v12.0-rc5`, `6d501ba4`) and not the clone beside the repository; generated files are regenerated rather than edited; a comment says what the code does, not how it got there; and `Dn` references stay out of code and comments. `ARCHITECTURE.md` decides which crate a thing goes in and which dependency edges are illegal, `DECISIONS.md` says why a rule exists. The reference pair is `cargo xtask reference up` (and `reference provision`, which is idempotent); a run is `cargo run -p jellyfin-harness -- replay --upstream URL --ours URL --scenario FILE --out DIR`, with `diff-db` for the two databases. `crates/jellyfin-harness/README.md` says what a diff means and what an ignore entry has to carry — every entry needs a reason and an expiry milestone, and an adds-only history is the smell the risk table names.

Claude added the

operations

labels

2026-08-13 23:07:39 +02:00