MDEV-31527: Add --validate-config option to check configuration without starting the server

[bodyhedia44]

MDEV-31527: Add --validate-config option

Summary

Add a new --validate-config command-line option that validates the server
configuration (from config files and command line) and exits with exit code
0 on success or non-zero on failure, without actually starting the server.

Use case

mariadbd --defaults-file=/etc/my.cnf --validate-config

DBAs can verify configuration changes before restarting production servers.

Test cases (mysql-test/main/validate_config.test):

1. Valid config → exit 0
2. Unknown CLI option → exit non-zero
3. No pid file created (server doesn't start)
4. No help text output
5. Bad option in config file → exit non-zero with error message
6. Valid config file → exit 0 with success message

Exit codes

Scenario	Exit code
Valid configuration	0
Unknown option	2
Unknown variable	7

How to use

Validate a config file before restarting

mariadbd --defaults-file=/etc/my.cnf --validate-config

Validate with additional command-line overrides

mariadbd --defaults-file=/etc/my.cnf --validate-config --max-connections=500

Matching MySQL 8.0 behavior

This is equivalent to MySQL 8.0's --validate-config option, adapted for
MariaDB's parsing architecture.

[gkodinov]

Thank you for your contribution. This is a preliminary review.

[bodyhedia44]

Done

[gkodinov]

Thanks for working on this with me. LGTM. One question for the final reviewer.

Please update the jira and the commit message and stand by for the final review.

[raghunandanbhat]

What happens if someone tries to check the version while validating the config? (Version print should probably take precedence and exit 0). Add a test for this case.

Please make the suggested changes & thanks for contribution!

[bodyhedia44]

Done

[raghunandanbhat]

When --help is present, mariadbd does not validate invalid configs, just prints the help text and exits (same with --version).

$ ./mariadbd --help --invalid-config
./mariadbd  Ver 13.0.0-MariaDB-debug for Linux on x86_64 (Source distribution)
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Starts the MariaDB database server.

Usage: ./mariadbd [OPTIONS]

For more help options (several pages), use mariadbd --verbose --help.

@bodyhedia44, your tests suggest that --help should take precedence over --validate-config. What if all three - --invalid-option, --help and --validate-confg are present? Should this validate the invalid config or just print help text and exit?

the current behavior is, it validates and prints the error indicating unknown option

$ ./mariadbd --help --invalid-config --validate-config
2026-03-10 23:02:11 0 [ERROR] ./mariadbd: unknown option '--invalid-config'
./mariadbd  Ver 13.0.0-MariaDB-debug for Linux on x86_64 (Source distribution)
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Starts the MariaDB database server.

Usage: ./mariadbd [OPTIONS]

For more help options (several pages), use mariadbd --verbose --help.

Same is true for --version, --validate-config and --invalid-option as well.

maybe @vuvova or @sanja-byelkin can comment on this?

[raghunandanbhat]

To be clear on the existing behavior (before this patch):

• mariadbd --help --invalid-option - prints help and exits cleanly. it does not evaluate the invalid config.
• mariadbd --version --invalid-option - prints version and exits cleanly. it does not evaluate the invalid config.
• mariadbd --help --verbose --invalid-option - takes the long path to load plugins for the verbose help menu, evaluates the config, and crashes with an "unknown option" error. it is the only exception.

currently, the PR breaks this behavior. if a user runs mariadbd --help --validate-config --invalid-option, the server incorrectly takes the long initialization path, evaluates the config, and crashes with an "unknown option" error, rather than short-circuiting to print the help text. please fix this.

add two more tests to ensure we don't regress. they verify that --help and --version correctly ignore invalid configurations and exit cleanly, even when --validate-config is present.

• --exec $MYSQLD_BOOTSTRAP_CMD --help --validate-config --invalid-config
• --exec $MYSQLD_BOOTSTRAP_CMD --version --validate-config --invalid-config

[bodyhedia44]

Done

[raghunandanbhat]

code looks good; please make the change in the test and it is ready for testing.

[bodyhedia44]

Done

[raghunandanbhat]

looks good. thanks @bodyhedia44

[vuvova]

in your patch opt_abort = opt_validate_config || opt_help || opt_version.

there's no need to test all four variables here

[vuvova]

I don't think this should have && !opt_help && !opt_version. A user asked to validate config, execution got that far, they deserve to see a message

[gkodinov]

Notes from the tester (copy from the Jira). Either discuss directly on Jira or rectify and commit an updaye:

1: This should not be happening:
Abdelrahman Hedia
--validate-config --log-bin creates binlog index file in datadir ( -bin.index)

2: Adjustments of values for options - they give warnings+ server will start with that adjusted value.
So - it is "Configuration is valid." - but maybe not what user intended? Maybe worth to mention it in the note or state?, e.g.:

2026-06-15 16:08:32 0 [Warning] option 'table_open_cache': unsigned value 0 adjusted to 10
2026-06-15 16:08:32 0 [Warning] option 'innodb-buffer-pool-size': unsigned value 1 adjusted to 2097152
2026-06-15 16:08:32 0 [Note] Plugin 'FEEDBACK' is disabled.
2026-06-15 16:08:32 0 [Note] Configuration is valid.

[bodyhedia44]

Done

[gkodinov]

LGTM. Please wait for @raghunandanbhat 's review

[ParadoxV5]

Late but non-important comment:
What do the software/script conventions define --dry/--dry-run as?

[raghunandanbhat]

git has a --dry-run, don't know others. its like conducting a rehearsal.

[vuvova]

it's MySQL compatibility, if I'm not mistaken. We should use the same name that MySQL does

[raghunandanbhat]

@bodyhedia44, your recent changes failed to compile on few buildbots, please fix them.

since this is a mysql compatibility feature, I'd be ok with it not validating configs related to storage engines or plugins which are not initialized (similar to what mysql does) -

The scope of the --validate-config option is limited to configuration checking that the server can perform without undergoing its normal startup process. As such, the configuration check does not initialize storage engines and other plugins, components, and so forth, and does not validate options associated with those uninitialized subsystems.

@vuvova any thoughts? skip validating configs for uninitialized serve components?

[raghunandanbhat]

this message can be misleading at times when only warning is printed and no options were adjusted.
validate_config_has_warnings is set for every WARNING_LEVEL message, not just value adjustments. So an out-of-scope warning like --validate-config --plugin-load-add=aaaa emitting unknown variable ... - prints "some option values were adjusted" even though nothing was adjusted.

Either set the flag only when a value is actually adjusted or re-word the message to something honest for all warnings. ex: "Configuration is valid; warnings were reported, see above."

[bodyhedia44]

Hi @raghunandanbhat

All three failing CI checks are unrelated to this PR — none touch the --validate-config code path, and main.validate_config passes on every builder that ran it.

amd64-msan-clang-20 and amd64-ubuntu-2204-debug-ps — both fail on innodb.skip_locked_nowait, which times out with ER_LOCK_WAIT_TIMEOUT (1205). It's a timing-sensitive InnoDB row-lock test (unrelated to config parsing).

amd64-debian-12-deb-autobake — fails at dpkg-checkbuilddeps: Unmet build dependencies: libboost-system-dev, aborting in <1s before any compilation. That's a build dependency missing on the worker, not a code issue.

[bodyhedia44]

the old faild builds i fixed it

[bodyhedia44]

@raghunandanbhat Gentle ping on this! I've addressed the previous comments and it's ready for another look whenever you have a moment.

[raghunandanbhat]

looks good, thanks @bodyhedia44.