Originally requested to be infinity, but rolled back to 99%
to allow for a remote ssh connection or the odd needed system
job. This is up from 15% which is the effective default of
DefaultTasksMax.
Thanks Rick Pizzi for the bug report.
We used to run `systemctl set-environment` to pass
_WSREP_START_POSITION. This is bad because:
* it clutter systemd's environment (yes, pid 1)
* it requires root privileges
* options (like LimitNOFILE=) are not applied
Let's just create an environment file in ExecStartPre=, that is read
before ExecStart= kicks in. We have _WSREP_START_POSITION around for the
main process without any downsides.
This commit fixes the test system hanging due to
the galera_var_notify_ssl_ipv6 test and also brings
the wsrep_notify[_ssl].sh files in line with each other
between the user template and the mtr suite.
Quotes are also added here to avoid problems if the
user specifies the value of one of the variables at the
beginning of the file containing shell-specific characters,
for example, if the password or username specified in the
PSWD and USER variables will contain the "$" character.
Also fixed an issue with automatic --ssl-verify-server-cert
option substitution when the corresponding value is set
by the user to "1" or "on".
Also fixed some tests here to avoid joining one of the nodes
to another cluster when the nodes are restarted from the mtr
side, which can lead to random failures when testing with
buildbot.
This commit adds automation that will reduce the possibility
of user errors when customizing wsrep_notify.sh (in particular
caused by user-specified parameters). Now all leading and trailing
spaces are removed from the user-specified parameters and automatic
port and host address substitution has been added to scripts, as
well as automatic password substitution to the client command line,
only if it is specified in the wsrep_notify.sh and not as empty
strings. Also added support for automatic substitution of the all
SSL-related parameters and improved parsing for ipv6 addresses
(to allow "[...]" notation for ipv6 addresses). Also added a
test to check if the wsrep notify script will works with SSL.
The else condition is meant to be here to define the functions
if the Red Hat include file isn't there.
Fixes: commit 467011bcac / MDEV-26614
RedHat -> Red Hat by Daniel Black
Prevent the error:
setroubleshoot[23678]: SELinux is preventing /usr/libexec/mysqld from read access on the file core_pattern.
Reading of the core pattern occurs on crash as added in MDEV-15051
RHEL-7.7
$ ls -laZ /proc/sys/kernel/core_pattern
-rw-r--r--. root root system_u:object_r:usermodehelper_t:s0 /proc/sys/kernel/core_pattern
Add SYSTEMD_READWRITEPATH-variable to mariadb{@,}.service.in to make sure that
if one is not building RPM or DEB packages then make sure there is ReadWritePaths
directive is defined in systemd service file.
This ensures that tar-ball installation has permissions to write database default
installation path (default: /usr/local/mysql/data) even if it's located
under /usr. Writing to that location is prevented by 'ProtectSystem=full'
systemd directive by default.
Prefixing the path with "-" in systemd causes there to not be an error if the
path doesn't exist. This may occur if the user has configured a datadir
elsewhere.
Reviewer: Daniel Black
... when two packages are installed.
(fc35 with i686 and x86_64 packages of libsepol installed).
$ rpm -q --qf "%{VERSION}" libsepol
3.33.3
Restricting the version to the current achitecture generates
a much more obtainable version dependency.
$ rpm -q --qf "%{VERSION}" libsepol.x86_64
3.3
This make dependency resolution easier preventing:
$ sudo dnf localinstall MariaDB-server-10.8.0-1.fc35.x86_64.rpm ...
Last metadata expiration check: 2:06:49 ago on Thu 30 Dec 2021 14:02:32.
Error:
Problem 1: conflicting requests
- nothing provides libsepol >= 3.33.3 needed by MariaDB-server-10.8.0-1.fc35.x86_64
The CMAKE_SYSTEM_PROCESSOR is used in the generation of architecture
filenames so its preduent to just use the same version.
RedHat systems have both files for lsb and init functions.
Old code was written as if/else, so second file (RedHat-specific) was not processed.
So, systemd redirect didn't work, because its logic is described in
RedHat-specific functions file
Quoting MDEV reporter Daniel Lewart:
Starting MariaDB with default configuration causes the following problems:
"[Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)"
silently reduces table_open_cache_instances from 8 (default) to 4
Default Server System Variables:
extra_max_connections = 1
max_connections = 151
table_open_cache = 2000
table_open_cache_instances = 8
thread_pool_size = 4
LimitNOFILE=16834 is in the following files:
support-files/mariadb.service.in
support-files/mariadb@.service.in
Looking at sql/mysqld.cc lines 3837-3917:
wanted_files= (extra_files + max_connections + extra_max_connections +
tc_size * 2 * tc_instances);
wanted_files+= threadpool_size;
Plugging in the default values:
wanted_files = (30 + 151 + 1 + 2000 * 2 * 8 + 4) = 32186
However, systemd configuration has LimitNOFILE = 16384, which is far smaller.
I suggest increasing LimitNOFILE to 32768.
we need to stop server instance on upgrade, but it may be started either by SysV init script or by SystemD.
this commit adds `mysql` target to `systemctl stop` call.
`mysql` may be the name of initscript or an alias while `mariadb` is
a systemd unit file.
This is just to make sure no ExecStartPre/Post actions from the
multi-instance MariaDB service definition are executed
when a user attempts to start mariadb@bootstrap.
Fixes: 3723c70a30
