MariaDB-10.4 onwards included a pam_helper subprocess to help
with the pam authentication module.
If the user is running with Galera there are SST modules that could
be executing.
By dropping KillMode=process this reverts back to control-group to
cover all of these subprocesses. This is what upstream does.
https://jira.mariadb.org/browse/MDEV-25233 suggests moving to
KillMode=mixed, which is probably ok too, but has been tested less.
Use mariadbd rather than mysqld in package descriptions.
Changed community branch of MySQL to "fork from", since branch
implies far too many updates from or back to the original
which isn't true.
Updated server-galera package description as it didn't
reference Galera at all.
---
Until now, we remove "mysql*" named upstream service files from the datadir, but leave the others.
IMO we should either ship them all or remove them all.
I see no benefit in keeping upstream service files, since they use different logic, capabilities, and starts scripts as root; unlike our downstream Systemd service files.
The patch was originally a copy of an upstream commit fixing this issue
Now the commit is a part of the server codebase
https://jira.mariadb.org/browse/MDEV-18737ddce859076
I stopped applying the patch with 10.5.0 release
Upstream issue:
https://jira.mariadb.org/browse/MDEV-19755
Upstream commit:
5cc2096f93 (diff-8576e5effae0770fc984e35e6749c43a8946489a1b478ce54facb3b9086622bf)
Scripts that rely on a specific driver won't work with differently named driver
Following scripts are affected:
mysql_convert_table_format.sh
mysql_setpermission.sh
mysqlhotcopy.sh
mytop.sh
as well as several tests for various components
So changing the required package to match the needs of the scripts
Testing:
Following command:
mysql_setpermission --user=root --host=127.0.0.1 --port=3306
Would fail with:
install_driver(MariaDB) failed: Can't locate DBD/MariaDB.pm in @INC (you may need to install the DBD::MariaDB module)
Related: #1903659
RPMDiff issue says:
File opt/rh/rh-mariadb105/root/usr/share/mysql-test/var is a dangling symlink (to /dev/shm/var_64_BuRk) on x86_64
In the CMake "CONFIGURE_FILE(<input> <output>)" command, the <input> path is treated relative to SOURCE dir, however the <output> patch is relative to BUILD dir.
Since the file has been copied to a wrong location, instead in-place updated as originally intended, the file that was later installed was the original unchanged file.
Resolves: #1873999, #1874446
Fix mariadb-pcdir.patch hunk