Do you mean the case when mysql_install_db script is invoked manually, or when it is run via server installation, or when it is run via service startup?

This is with mysql_install_db invoked manually on systemd.

What does it mean, "manually on systemd"? Could you provide the exact command line that is run, please?

Given the update on the description, apparently it means "on systemd-enabled distributions". But if mysql_install_db is started manually, why would it know anything about systemd configuration?

On systemd: Meaning on CentOS 7+, where systemd, and not upstart, manages services.

Command line:

~# mysql_install_db

"why would it know anything about systemd configuration?" - Shall I ask the customer why he expects the product's installation to respect the product's configuration?

As I understand it, the customer is having an issue because they are trying to use a scripted install and have a specific error caused by the lack of uniformity in the application of the UMASK_DIR.

The same as mysql_install_db is expected to crawl through the cnf files to find the datadir, and expected to read the environment variable UMASK_DIR, it should be able to see the same information when it is declared instead in /etc/systemd/system/mariadb.service.d/

It would be odd to expect mysql_install_db to know nothing about the mysql service, the service for which it is creating and populating a datadir.

It is not creating the datadir for the service. It creates the datadir for MariaDB server. It has nothing to do with the systemd service.
mysql_install_db is not expected to crawl through all config files on a machine, either. It is supposed to read very specific sections of a specific set of MariaDB cnf files.

Moreover, if you choose to invoke mysqld manually, without the service, it won't be reading systemd configuration either. It will only read its own config files, as it's supposed to.

I think we just need new script, let's say mysql_new_instance, that is aware of systemd configuration files, something like galera_new_cluster (maybe also based on mysqld --initialize feature like the one we see in upstream MySQL).

I see no point in any change of behavior for existing mysql_install_db.

Confirmed that mysql_install_db does not read the UMASK and UMASK_DIR definitions in upstart either (in /etc/init.d/mysql.server), so it's not a question of something that worked properly in prior versions.

Converted to a feature request based on valerii's comment above.

The fact that mysql_install_db isn't aware of an init script is irrelevant. It is not a regression, and neither is it a bug, that it is not aware of any wrappers that might or might not be optionally used to call it, as well as mysqld itself and any other MariaDB binaries.

Please note that there is also MDEV-17640, which is a separate but related matter.

I don't see it as something that needs fixing at all. Files in /etc/systemd/system/mariadb.service.d/ affect mariadb when started via systemd and do not affect mariadb when not started via systemd. This is what one would expect and this is what actually happens.

I can let the user know that engineering feels mysql_install_db does not need to support server UMASK settings, but it seems legitimate that a client would expect mysql_install_db to work in this scenario.
My take is that since the functional requirement to have the server use a specific permissions mask when managing files would obviously apply to a utility that creates those files for that server, maybe the service configuration is not the ideal place for UMASK. If it were a global variable, it would be a much more seamless management experience for the server administrator.

May be. Or may be mysqld --initialize mode could be implemented.

Juan: In review of the referenced page, https://mariadb.com/kb/en/library/specifying-permissions-for-schema-data-directories-and-tables/ whose parent is "Starting and Stopping MariaDB", it appears that this content is wholly about the MariaDB Server process and not about the installation process of MariaDB Server.

It is likely that some other page or pages need to incorporate information about file and directory permissions, but I believe the note added to this page two months ago is now covering a completely separate product step, and should be reverted. I don't believe that this specific page should be extended to cover these other cases, but that we should identify in the page specific to mysql_install_db how umask is set.

Does this approach raise concerns? If not, I will revert your change at bottom of page and add umask information on the pages for mysql_install_db