# Percona Server 8.0: config_file variable does not reflect the my.cnf moved to /etc/percona

## TL;DR

The config_file variable records the main defaults file mysqld settled on at startup, not every file that contributed settings. On a standard build, a bare /etc/percona path is not in the option-file search order at all, and a file pulled in through an !includedir line is merged silently without ever updating config_file. Print the search order for your exact build with mysqld --verbose --help, check how the file is being reached (direct read, !includedir, or not at all), and prove which files are parsed with a sentinel value before changing any paths.

## Verbatim report

```text
Percona Server for MySQL 8.0.43-34: the configuration file was changed to /etc/percona,
but the config_file variable does not point to it after startup.
The server otherwise works, using settings from the /etc/percona file.
```

## Steps

1. Print the option-file search order for this exact build. Run mysqld --verbose --help and read the line that begins "Default options are read from the following files in the given order". Success check: you have the real list for this binary (commonly /etc/my.cnf, /etc/mysql/my.cnf, the build sysconfdir my.cnf, DATADIR/my.cnf, then the user file), instead of assuming a path is searched because it exists.
2. Compare the list against where your settings live. If /etc/percona is not in the printed list, mysqld never opens it as a main defaults file, no matter its permissions. Success check: you can say which searched file, if any, references your settings.
3. Check for an include bridge. Look in the searched files (usually /etc/my.cnf) for !include and !includedir lines. An !includedir line reads only files ending in .cnf inside that directory, in sorted order. Success check: either your file sits inside an included directory with a .cnf name, or you have confirmed there is no bridge and the file is simply not being read as a main file.
4. Understand what config_file can and cannot tell you. config_file tracks the main defaults file recorded at startup (the --defaults-file value when one is given, otherwise the searched file that was used). Files merged through !include or !includedir do not replace it. Success check: a config_file value that names /etc/my.cnf while settings clearly come from an included file is expected behavior, not proof the included file was ignored.
5. Run the sentinel test to separate "variable looks wrong" from "file is not parsed". Put a distinctive, harmless value that exists only in the candidate file (for example a max_connections value used nowhere else), restart in a maintenance window, and query the running server for that variable. Success check: if the running value matches the sentinel, the file IS parsed and only the config_file display is misleading; if it does not match, the file is not being read at all and step 2 or 3 found the reason.
6. If you need config_file itself to name your file, start mysqld with --defaults-file pointing at it as the FIRST argument (in the systemd unit override or service start options), or move the settings into a file that is in the printed search order. Success check: after restart, config_file shows the intended path and the sentinel value from step 5 is live.
7. Check file access only after the search-order question is settled. Confirm the mysql user can read the file and its parent directory, and scan the error log from the same startup for option-file warnings. Success check: no read warnings in the log; note that correct permissions cannot rescue a file that is outside the search order.

## When this applies

- Percona Server for MySQL 8.0.x (reported on 8.0.43-34) on Linux
- The config_file variable disagrees with where the admin placed the settings
- The server starts and mostly behaves, so this is a "which file was read" question, not a crash

## When this does not apply

- mysqld fails to start with an unknown variable or option-file parse error (fix the named line first)
- Settings are missing because of login-path or client option files (those are read by clients, not the server)
- You intentionally run several instances with different --defaults-file values per instance (check each unit separately)

## Variant phrasings

### config_file still shows the old path after moving my.cnf

Same failure. The variable follows the main defaults file mysqld recorded, so work steps 1 to 5 in order before moving anything back.

### Settings from an included cnf file apply but config_file does not change

Expected when the file arrives through !includedir. The merge works, the variable does not track included files. Use the sentinel test if you need proof for a specific setting.

## Why it happens

mysqld resolves option files before it processes command-line arguments, using a fixed per-build search list. Only the winning main file is recorded for config_file. Include directives are a second, quieter mechanism layered on top: they merge extra settings during parsing but were never wired into the variable that reports the configuration file, and a path that is in neither the search list nor an include line is invisible to the server even though it sits in /etc with the right name and permissions.

## Edge cases

- A file named exactly like a directory path (a regular file sitting where an !includedir expects a directory, or vice versa) fails silently. Verify the type of the path, not just its existence.
- Package upgrades can regenerate /etc/my.cnf and drop a hand-added !includedir line, which makes a previously working layout stop parsing after an update.
- Multiple searched files are ALL read in order, with later files winning on conflicts. config_file naming one of them does not mean the others were skipped.

## Provenance

Resolved from the public thread: https://forums.percona.com/t/percona-server-for-mysql-8-0-43-34-config-file-path-not-changed-after-changed-config-file-to-etc-percona/38865