The mariadb 10.4 server fails to start using command
/usr/local/libexec/mysqld --user=root --defaults-file=/usr/local/etc/my.cnf
2019-08-17 15:36:56 0 [ERROR] /usr/local/libexec/mysqld: unknown variable 'defaults-file=/usr/local/etc/my.cnf'
It looks like a failure to correctly parse the command line, with the result that it interprets both the option and its value as a single, unrecognisable variable.
I forgot to select "affects many"
mysqld --defaults* arguments must be specified first before any other arguments like "--user"
This is specified in the top of mysqld --help --verbose:
The following specify which files/extra groups are read (specified before remaining options):
--defaults-file=# Only read default options from the given file #.
--defaults-extra-file=# Read this file after the global files are read.
--defaults-group-suffix=# Additionally read default groups with # appended as a suffix.
At a minimum, then, the error message is totally broken and misleading!
But I can't think of a good reason why mariadb should be enforcing position dependence in the first place, since it's not required by the syntax.
Its been this way always and all mysql releases too.
The syntax make it significantly easier to parse settings in order and make it quite clear what is intended.
In your example /usr/local/libexec/mysqld --user=root --defaults-file=/usr/local/etc/my.cnf, if the defaults-file contains a `user=mysql` setting are you intending for this to override --user=root? Because traditionally later arguments took precedence over earlier settings, and also args take precedence over file configs, but if the file config is explicit, does this expectation change?
I agree the error message should be better. Could write an upstream bug https://jira.mariadb.org/ or patch https://github.com/MariaDB/server/pulls.
As far as I'm aware, the precedence rule has been around awhile and is both global and unambiguous: if, for some variable X, there are contradictory assignments A and B in a config file, and C and D on the command line, D is always the one that wins: later over earlier, command line over config file. Process the default config file(s) in reading order first, assigning as you go, then scan the command line for config file references and process those files as found, and finally process the rest of the command line in reading order, again assigning as you go.
What possible benefit could anyone get from a special, unnecessary precedence rule?
"It's always been that way" or "we've always done it that way" is really an admission, not a justification.
Its an explanation. I'm sorry you wanted a discussion, because I don't.
It wasn't my intention to offend you, and I'm sorry that I did. Your comment to which I responded appeared to approve of and defend the status quo, and my response was to that. I think we might both agree that the pointless ignoring of standards is a bad idea.
Regardless, I did and do appreciate your explanation, and I'm sorry that I didn't say so immediately.
Have you created an upstream PR with MariaDB?
Closing this one here...