Redis 6.0.8 repairs configuration rewrite output

A server can accept its configuration, run normally and then write a file it cannot read at the next start. Redis 6.0.7 has that failure mode in configuration rewriting for OOM score values. Redis 6.0.8 fixes the generated line and adds a test aimed at checking the complete configuration representation. The consequence is operational because the malformed file becomes a startup failure later.

The release notes date 6.0.8 to September 9, 2020. The tagged notes rate the upgrade high and urge users of 6.0.7 with Sentinel or CONFIG REWRITE to upgrade promptly. That warning names the affected operational path, rather than describing an error in ordinary key storage.

I have used Redis since its release, and I consider generated configuration part of its operational interface. A successful in-memory change is only one result. Once the service writes that state back to disk, the output has to retain enough syntax and meaning to establish the same configuration after a restart.

The writer omitted the setting name

The fix by Yossi Gottlieb changes the start of the OOM-score-values rewrite function. Previously it began with an empty string and appended the numeric values. The replacement begins with the directive name and a space before adding those values.

This is a small patch with a large effect. A configuration line needs both the keyword identifying the setting and the arguments supplying its value. A list of numbers cannot stand in for the complete directive. The running process already has the values in structured state, so the error appears when that state is serialised.

The release notes say the condition can arise after values are supplied through CONFIG SET or loaded from the configuration file. A deployment does not need a particular interactive administration habit to encounter it. Reading the setting at startup and later invoking the rewrite path can be enough.

The resulting file is corrupt in the sense of invalid configuration syntax. The notes describe Redis failing to start with it. They do not describe the rewrite defect as corruption of the stored key dataset. Keeping those objects distinct explains both the failure and the scope of the fix.

The setting describes process selection under memory pressure

The 6.0.8 configuration documents oom-score-adj and its associated values. The feature aims to make background children more likely to be killed than other Redis processes, and replicas more likely than primaries. Higher adjustment values mean greater likelihood of selection.

The supplied values are zero, two hundred and eight hundred for the primary, replica and background-child roles. The adjustment mechanism is disabled by default. Having values in the configuration is therefore separate from enabling the behaviour that applies them.

The comments describe values relative to the initial OOM adjustment when the server starts. They also describe an operating-system permission limit. An unprivileged process can increase its adjustment, but cannot freely decrease it below the initial value without the relevant authority.

Those semantics make this a multi-value configuration item with role-dependent meaning. Serialising only the numbers loses the keyword needed to interpret them, even though their order remains intact. The fix restores the complete directive representation.

For illustration, the valid file form includes the keyword and all role values.

oom-score-adj no
oom-score-adj-values 0 200 800

These lines describe the shipped settings. They are not a recommendation to change the host's process-killing policy. The startup parser must be able to read them whether an operator adopts the feature or retains its disabled state.

The command handler also rejects rewriting when the server has no configuration file. That separate error reports the absence of a destination file, while this defect concerns an existing file receiving invalid content. The two cases require different explanations even though both involve the same command.

Sentinel shares the rewrite machinery

The urgency statement includes Sentinel, and the testing change shows that Sentinel's configuration flush calls the same rewrite function. This explains why the defect is relevant beyond someone manually issuing the command against an ordinary data server.

The representation of configuration is shared infrastructure. A specialised process can reach a general writer even when its main purpose differs from serving keys. That makes a rewrite defect capable of affecting a management component as well as a data process.

The specific advice remains the release's advice for 6.0.7 users. It should not be broadened into a claim that every Sentinel installation on every version has an invalid file. Version, setting and rewrite behaviour determine the disclosed failure path.

The test exercises omitted defaults too

The broader testing patch adds a force-all mode to the rewrite state. Normal rewriting can omit settings at their default value unless they already appear in the file. The test mode overrides that omission, making all configuration keywords available to the round-trip check.

That distinction addresses a coverage problem. A broken writer for a default-valued option can remain unexecuted if the test only rewrites an otherwise minimal file. Exercising every keyword makes the test inspect representations that ordinary selective rewriting may leave out.

The patch describes its purpose as verifying valid output and avoiding unintended configuration changes. Both properties matter. A file can be syntactically valid while silently describing a different state, so a parser merely accepting the output is an incomplete account of the intended test.

The debug command supporting force-all writing is explicitly described as a testing facility. It is not a replacement workflow that affected operators must adopt. The production command and Sentinel call continue to use ordinary rewriting, while the additional path broadens verification.

I find this response useful because it fixes the missing syntax and addresses why similar omissions might escape a narrow test. Redis 6.0.8 restores the keyword before the OOM score values, then adds a mechanism for exercising configuration output even when defaults would normally suppress it. That connects the repaired startup input with the process that produces it.