1. Please describe the problem: rubygem-mysql2 test suite started to fail [1] with update to MariaDB 10.5.18. This is short snippet of the log: ~~~ ... snip ... + TOP_DIR=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4 + MYSQL_TEST_PORT=13471 ++ id -un + MYSQL_TEST_USER=mockbuild + MYSQL_TEST_DATA_DIR=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data + MYSQL_TEST_SOCKET=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.sock + MYSQL_TEST_LOG=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log + MYSQL_TEST_PID_FILE=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.pid + mkdir /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data + mysql_install_db --datadir=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data --log-error=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Installing MariaDB/MySQL system tables in '/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data' ... /usr/libexec/mysqld: Can't create file '/var/log/mariadb/mariadb.log' (errno: 13 "Permission denied") 2022-11-17 11:20:47 0 [Warning] WSREP: Failed to guess base node address. Set it explicitly via wsrep_node_address. 2022-11-17 11:20:47 0 [Warning] WSREP: Failed to guess base node address. Set it explicitly via wsrep_node_address. 2022-11-17 11:20:47 0 [Warning] WSREP: Guessing address for incoming client connections failed. Try setting wsrep_node_incoming_address explicitly. OK To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system Two all-privilege accounts were created. One is root@localhost, it has no password, but you need to be system 'root' user to connect. Use, for example, sudo mysql The second is mockbuild@localhost, it has no password either, but you need to be the system 'mockbuild' user to connect. After connecting you can set the password, if you would need to be able to connect as any of these users with a password and without sudo See the MariaDB Knowledgebase at https://mariadb.com/kb You can start the MariaDB daemon with: cd '/usr' ; /usr/bin/mysqld_safe --datadir='/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data' You can test the MariaDB daemon with mysql-test-run.pl cd '/usr/mysql-test' ; perl mysql-test-run.pl Please report any problems at https://mariadb.org/jira The latest information about MariaDB is available at https://mariadb.org/. Consider joining MariaDB's strong and vibrant community: https://mariadb.org/get-involved/ + /usr/libexec/mysqld --datadir=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data --log-error=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log --socket=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.sock --pid-file=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.pid --port=13471 --ssl ++ seq 10 + for i in $(seq 10) + sleep 1 2022-11-17 11:20:48 0 [Note] /usr/libexec/mysqld (mysqld 10.5.18-MariaDB) starting as process 1297 ... + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log + echo 'Waiting connections... 1' + for i in $(seq 10) Waiting connections... 1 + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 2 + echo 'Waiting connections... 2' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 3 + echo 'Waiting connections... 3' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 4 + echo 'Waiting connections... 4' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 5 + echo 'Waiting connections... 5' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 6 + echo 'Waiting connections... 6' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 7 + echo 'Waiting connections... 7' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log Waiting connections... 8 + echo 'Waiting connections... 8' + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log + echo 'Waiting connections... 9' Waiting connections... 9 + for i in $(seq 10) + sleep 1 + grep -q 'ready for connections.' /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log + echo 'Waiting connections... 10' Waiting connections... 10 + mysql -u mockbuild -e 'ALTER USER '\''root'\''@'\''localhost'\'' IDENTIFIED VIA mysql_native_password USING PASSWORD('\'''\'')' -S /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.sock -P 13471 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.' (2) ... snip ... ~~~ While I have not investigate the issue in detail, this could be short reproducer: ~~~ $ /usr/libexec/mysqld --datadir=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/data --log-error=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.log --socket=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.sock --pid-file=/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.pid --port=13471 --ssl $ mysql -u mockbuild -e 'ALTER USER '\''root'\''@'\''localhost'\'' IDENTIFIED VIA mysql_native_password USING PASSWORD('\'''\'')' -S /builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.5.4/mysql.sock -P 13471 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/builddir/build/BUILD/mysql2-0.5.4/usr/share/gems/gems/mysql2-0.' (2) ~~~ [1]: https://koschei.fedoraproject.org/build/14086115
I wish this was not pushed into stable prior investigation. Now rubygem-mysql2 build fails everywhere :/
Alright, I've made a lot of digging. Wall of text warning. ----- (1) When 'mysql_install_db' script is called, https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_89 it shows the following error: /usr/libexec/mysqld: Can't create file '/var/log/mariadb/mariadb.log' (errno: 13 "Permission denied") Until today, you ignored it and it hadn't caused you any trouble. Lucky you - it is an actual bug in the MariaDB server (or rather the 'mysql_install_db' shell script, to be precise). The bug is that the '--log-error' argument and it's value aren't properly passed to the MariaDB server - as described in the documentation. Instead, a value from the default configuration files ( "/etc/my.cnf" and "/etc/my.cnf.d/*" ) is used (in this case the path "/var/log/mariadb/mariadb.log") and since the unprivileged user (the RPM build is done with) hasn't an access to that location (only 'root' and 'mysql' users have), you see the error. As a side effect, the server log is written to the console (stderr) instead of the file. This bug is being fixed by upstream as we speak: https://github.com/MariaDB/server/pull/2363 https://jira.mariadb.org/browse/MDEV-18591 ----- (2) Configuration you probably don't want The MariaDB server (and other packages around) own several configuration files ( "/etc/my.cnf" and "/etc/my.cnf.d/*" ) which are provided as a default configuration. The DB server ran with them works out-of-the-box, allowing quick experimenting, but practically every time you put a production workload on the server, you should tweak the configuration to match your needs. In fact, that is what you are doing https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_81 setting custom values to number of options, so the server could be run under an unprivileged account. In cases like these, when you have a clear idea of what you want to achieve, I suggest to make sure, only the intended configuration is ever passed to the DB server. You can do this by passing '--no-defaults' argument to the '/usr/libexec/mysqld' binary and '/usr/bin/mysql_install_db' script. This argument cause the DB server to ignore any configuration files. https://mariadb.com/kb/en/mysqld-options/#-no-defaults ----- (3) While waiting for the DB server to come online https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_101 you don't check for the DB server crashing or aborting. (and abort is what it does in this case) I suggest that if the DB server hasn't come online even on the last try, you should throw an error, print the whole error log and exit the RPM build. ----- (4) Disabling the 'unix_socket' authentication method https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_109 Not sure if it was always this way, or the documentation got updated after this ^ piece of code was created, but today there is much more easier and elegant way to deal with it - described at the same URL. Just pass '--auth-root-authentication-method=normal' to the 'mysql_install_db' script. https://mariadb.com/kb/en/mysql_install_db/#options Side note: Until explicitly disabled, the 'unix_socket' authentication method is still enabled and have precedence over the password. That might not bother you *in your case*, as you use unprivileged UNIX account to log to 'root' DB account, however if you would need the 'unix_socket' authentication really disabled, you have to configure the DB server that way, with either of these two configuration file options: | | [mariadb] | unix_socket=OFF | disable_unix_socket | ----- (5) The actual issue here - SSL In Fedora, the MariaDB 10.5.16 used downstream OpenSSL 3 patch. The MariaDB 10.5.18, started to use upstream OpenSSL 3 patch. And there were some differences between these two. In your case, it leads to the DB server aborting, as the SSL is not properly configured (SSL certificates missing). Before, the SSL won't work either, but the server didn't abort because of that (at least not during initialization) So, if you want to test SSL - configure the SSL properly. If you don't want it, remove the '--ssl' argument. https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_99 ----- (6) Do you even use the SSL ? I've checked last couple of productions builds in KOJI, spanning the last 3/4 of the year. It turns out that: (6.A) In module builds, you don't run '%check' phase at all. Is it worth that ? https://src.fedoraproject.org/modules/ruby/blob/3.1/f/ruby.yaml#_56 https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_71 https://koji.fedoraproject.org/koji/buildinfo?buildID=2058267 ^--> https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/2.module_f38+15392+0b99661f/data/logs/x86_64/build.log https://koji.fedoraproject.org/koji/buildinfo?buildID=2058257 ^--> https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/2.module_f37+15390+fb26f2c0/data/logs/x86_64/build.log (6.B) In classic builds, you run the testsuite, but the SSL test never actually passed. Every testsuite ends with: | | Pending: (Failures listed here are expected and do not affect your suite's status) | 1) Mysql2::Client should set default program_name in connect_attrs | # DON'T WORRY, THIS TEST PASSES - but PERFORMANCE SCHEMA is not enabled in your MySQL daemon. | # ./spec/mysql2/client_spec.rb:510 | 2) Mysql2::Client should set custom connect_attrs | # DON'T WORRY, THIS TEST PASSES - but PERFORMANCE SCHEMA is not enabled in your MySQL daemon. | # ./spec/mysql2/client_spec.rb:520 | 3) Mysql2::Client SSL should set ssl_mode option disabled | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:169 | 4) Mysql2::Client SSL should set ssl_mode option preferred | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:169 | 5) Mysql2::Client SSL should set ssl_mode option required | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:169 | 6) Mysql2::Client SSL should set ssl_mode option verify_ca | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:169 | 7) Mysql2::Client SSL should set ssl_mode option verify_identity | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:169 | 8) Mysql2::Client SSL should be able to connect via SSL options | # DON'T WORRY, THIS TEST PASSES - but /etc/mysql/client-key.pem does not exist. | # ./spec/mysql2/client_spec.rb:182 | Finished in 11.38 seconds (files took 0.22678 seconds to load) | 340 examples, 0 failures, 8 pending | https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/2.eln120/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/2.fc37/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/1.eln120/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/1.eln118/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.4/1.fc37/data/logs/x86_64/build.log (6.C) This is different from the previous release of 'rubygem-mysql2' package, in which the SSL either passed or wasn't present - I can't tell. https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.3/12.eln116/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/rubygem-mysql2/0.5.3/12.fc37/data/logs/x86_64/build.log This all leads to my conclusion in the preivous point (5). You can ditch the '--ssl' argument, the DB server won't abort, the tests would pass the same way as before (which means no SSL tests will pass) and the RPM build will succeed. Or you can fix it to actually run the SSL tests. ----- (7) While running a lot of different scratch builds, I noticed, that the *as far as I can tell*, the code here: https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_116 does not make any difference in the tests results. Might be obsolete, or useless - I tried to examine the code linked in comment, but I'm not any wiser. Maybe the commit 'a0c3c0e8' in the 'rubygem-mysql2' package - in which this code was introduced - will help you. ----- I hope I managed to explain everything in an understandable way. I'm updating the BZ to better reflect my findings.
Update prepared in: https://src.fedoraproject.org/rpms/rubygem-mysql2/pull-request/13
I was able to reproduce this issue on the upstream based on the Michal's investigation. Thanks! Here is the PR to fix this issue on the upstream. https://github.com/brianmario/mysql2/pull/1290 Here is the PR to fix this issue on the Fedora package. https://src.fedoraproject.org/rpms/rubygem-mysql2/pull-request/14
FEDORA-2023-62569d72f2 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-62569d72f2
FEDORA-2023-62569d72f2 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
> (1) When 'mysql_install_db' script is called, > https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/fd43948e4e58/f/rubygem-mysql2.spec#_89 it shows the following error: > /usr/libexec/mysqld: Can't create file '/var/log/mariadb/mariadb.log' (errno: 13 "Permission denied") > > This bug is being fixed by upstream as we speak: > https://github.com/MariaDB/server/pull/2363 > https://jira.mariadb.org/browse/MDEV-18591 Note the upstream ticket said that the bug is fixed in mariadb-server 10.5.19. The current mariadb-server on rawhide is 10.5.18 (mariadb-server-3:10.5.18-1.fc38.x86_64).