michaeldg, does it really need to be a separate script?

You can see that the galera_new_cluster script is a pretty simple thing that sets a systemd environment variable and then starts the mariadb unit. You could do those same things manually to set any other value you wanted for that variable.

systemctl set-environment _WSREP_NEW_CLUSTER='--wsrep-recover' && \

    systemctl start mariadb

systemctl unset-environment _WSREP_NEW_CLUSTER

I wish systemd did a better job of this, but I also think that it would be kind of crazy to distribute a separate script for every possible startup scenario. Maybe a solution would be to extend the galera_new_cluster script (or create a script with a more generic name) that would allow the use of arbitrary command line options when starting the server?

Michaël, this jira task is about --wsrep-recover, which is a server option (https://mariadb.com/kb/en/mariadb/galera-cluster-system-variables/#wsrep_recover). This has nothing to do with mysqlbinlog.

Oops!! Sorry.

The --wsrep-recover switch will not start the server (the server will start, display the recovery information and exit) while galera_new_cluster does. Therefor galera_new_cluster --recovery-information will not suffice imo.

If you do this with systemd, will it display the required information? Will it display the CLI output?

The --wsrep-recover is used in case of crash recovery. Therefor it is probably used in the middle of the night on a saturday evening. It should be easy to remember and impossible to do wrong. We should avoid the risk of somebody executing galera_new_cluster instead of galera_recovery_information as it would possible start up the wrong node first which makes you loose transactions.
I think galera_recovery_information script name would be easy to find and remember so I would prefer a separate command for this purpose.

Another idea would be to have the script output the way to manually set command-line parameters to teach the user how to do it. The same way as /etc/init.d/mysql start displays the systemd version of the command.

Thank you for thinking about this important detail as well!

Michaël, no, systemd won't show the output on stdout/stderr. But isn't that the same behavior you get when starting a service using the "service" command? In that case, when using --wsrep-recover, wouldn't you need to look in the error log to see the output?

Theoretically, if all config information is in .cnf files mysqld can find on its own, running mysqld --wsrep-recover alone should be enough, but there are so many possible gotchas....

There are a lot of ways to influence service behavior with systemd that would be difficult for an external script to handle, unless it also invoked systemd. Server options can be set in environment variables, unit files, and config files that might only be read when a service is started by systemd. Creating and maintaining a separate script that could reliably work in exactly the same way would be a heavy burden. I worry about your scenario in the middle of the night on a Saturday that some strange case of this kind could be very difficult to track down and could cause immense problems.

Duplicate of MDEV-10004.