FluxOS v8.18.0: Live Application Logs

Fluxers! FluxOS v8.18.0 is out, and it is a big one — 945 commits since v8.17.0. The headline feature is one that developers have been asking for since the day applications landed on Flux: live application logs, pushed to you as your container writes them.

Underneath that sits a large amount of reliability work on redeploys and on the app synchronisation layer. Let’s go through it.

Logs, as they happen

Until now, reading the logs of an application running on Flux meant asking a node for a chunk of them and asking again. That works, but it is not how you debug something. You want the lines to arrive.

In v8.18.0 a node takes the container’s log stream directly from Docker and pushes lines to the viewer as they are written. If a node cannot offer a stream, the poll is kept, so you always get something. And the polling path itself was rebuilt around a cursor: a log answer now says separately what is ahead of where you got to and what is behind a line limit, so paging forward never silently skips a line.

Some specifics that matter if you have ever lost output in a log viewer:

• A reader resumes from where it got to, not from a line count, so nothing is missed between polls. We verified this against a real fleet rather than a mock.
• A line too long for the node to hold is cut, and you are told — rather than truncated in silence or, worse, dropped.
• A page of long lines that fitted is no longer reported as an overflow.
• Logs keep a floor of history instead of none, so attaching to a container does not mean starting from a blank pane.
• A log read releases the event loop while it decodes, so pulling a large log no longer makes the node unresponsive to everything else.
• One Docker stream per container, claimed before the daemon is asked. A viewer that unsubscribes leaves the room it was watching, and a feed that ends releases the connections holding it — so a busy log pane cannot leak node resources.

Finding a container is also faster now: FluxOS asks Docker about the one it wants rather than listing every container on the machine and searching.

Redeploys that do what they say

The second theme of the release is component redeploy. This is the operation that updates one component of a multi-component application, and several sharp edges have been filed off:

• One component’s failed teardown no longer uninstalls the whole app. This is the important one.
• A soft redeploy that never removed the app must not uninstall it — likewise.
• A component redeploy now reports only what it actually reinstalled, answers through the stream it opened exactly once, and accepts the bare app name too.
• A failed soft install finishes its teardown before the endpoint answers, so you are never told about a state the node has not reached.
• An install now says which of three things it did, rather than returning a success that could mean any of them.
• A container FluxOS removed itself is no longer treated as evidence of tampering.

A hard component redeploy is now covered end to end by tests that wipe that component and only that component, and the argument contract is pinned so it cannot drift.

Node stability

Several fixes in this release exist because a single bad path could take a whole node down. An exec that cannot start now answers its caller instead of exiting the node. A missing container is an error the caller can read, and reporting it does not kill the process. A failed log poll reports on both channels and resolves on neither. A runner that throws reaches the process that restarts the node. A stopped loop stays stopped, and a stop waits for what it owns.

None of these are features. All of them are the difference between a node that stays up and one that does not.

App sync and placement

The synchronisation layer — how nodes agree on which applications live where — also got a pass. A sync request is opened only once its signature exists, and a stopped orchestrator holds no authority. A node answers the temporary stream on the same terms as everything else, and a chunk is verified where it arrives. The sync budget now bounds the attempt, and a peer already tried is not tried again. A peer is credited with answering when its answer arrives, rather than when we finish with it.

Alongside that, application announcements no longer absorb the work they are announcing, the announce interval comes from the row it refreshes, and stopping one is final.

Updating

FluxOS updates itself, so most operators need do nothing. If you run a legacy node, this is the moment to plan the migration to PoUW v2 — nodes still on the legacy environment after the announced deadline will be banned from FluxCloud.

The full changelog is on GitHub, and the log viewer is already live in Flux Home.