Issues after upgrading to mariadb105-server from ports

F

freebsd number 1

When installing mariadb105-server-10.5.7 with S3 enabled, I get the following error during 'make install':

Code: 
===>  Installing for mariadb105-server-10.5.7
===>  Checking if mariadb105-server is already installed 
===>   Registering installation for mariadb105-server-10.5.
===>   Registering installation for mariadb105-server-10.5.7                                                          
pkg-static: Unable to access file /usr/pkg-build/usr/ports/databases/mariadb105-server/work/stage/usr/local/etc/mysql/conf.d/s3.cnf.sample:No such file or directory             
*** Error code 74
Stop.
make[1]: stopped in /usr/ports/databases/mariadb105-server
*** Error code 1

What to do?
 
After disabling S3, I was able to build and install mariadb105-server-10.5.7 successfully. However MariaDB won't start as a service. When i try to start it using
Code: 
# /usr/local/etc/rc.d/mysql-server start
Starting mysql
#
nothing happens. The mariadb error log doesn't contain any information.

I am, however, able to run it manually using 'mariadbd-safe --user=mysql'.

Previously, i had MariaDB 10.4.15 installed, and that was working fine, without any issues.

What could be the problem that prevents MariaDB 10.5 from being started as a service?
 
freebsd number 1 said:
What could be the problem that prevents MariaDB 10.5 from being started as a service?
Click to expand...
Look in the /var/log/mysql/mysqld.err why it failed to start. Also keep in mind things moved around a bit recently. Specifically the socket now gets created in /var/run/mysql/ instead of /tmp/.

This is for 10.4 but 10.5 has had the same changes:
Code: 
# pkg info -D mariadb104-server
mariadb104-server-10.4.15:
On install:
MariaDB respects hier(7) and doesn't check /etc and /etc/mysql for
my.cnf. Please move existing my.cnf files from those paths to
/usr/local/etc/mysql or /usr/local/etc. Sample
configuration files are provided in /usr/local/etc/mysql
and /usr/local/etc/mysql/conf.d.

This port does NOT include the mytop perl script, this is included in
the MariaDB tarball but the most recent version can be found in the
databases/mytop port

On upgrade:
The default MySQL socket location has moved from /tmp to /var/run/mysql
for both client and server packages. Make sure you update your configurations
in /var/db/mysql and /usr/local/etc.

Remember to run mariadb-upgrade (with the optional --datadir=<dbdir> flag)
the first time you start the MySQL server after an upgrade from an
earlier version.
 
The log file /var/log/mysql/mysqld.err contained the usual start / shutdown entries, when i ran mariadb manually, but nothing when i tried to start it as a service.

Anyway, i solved the problem by installing the base system and building mariadb in a newly created jail, followed by copying /var/db/mysql into that new jail. Everything is now working as expected.

The original issue that I had with installing mariadb with S3 enabled seems to have to do with an incorrect file name in the makefile. The script tries to copy a file 's3.cnf.sample' from the staging directory to '/usr/local/etc/mysql/conf.d', but there is only a file 's3.cnf' in the staging directory. I'm quite sure that this is a bug with the port. I don't know yet whether that has been fixed in mariadb 10.5.8.
 
freebsd number 1 said:
The script tries to copy a file 's3.cnf.sample' from the staging directory to '/usr/local/etc/mysql/conf.d', but there is only a file 's3.cnf' in the staging directory.
Click to expand...
Seems that's the issue. As this is a configuration file it should have that .sample extension. Configuration files are treated a little different in order to not overwrite existing settings.
freebsd number 1 said:
I'm quite sure that this is a bug with the port.
Click to expand...
Please submit a PR for this so the maintainer is aware and can fix the issue. Often non-standard option settings are overlooked when testing.
freebsd number 1 said:
I don't know yet whether that has been fixed in mariadb 10.5.8.
Click to expand...
Looks like that was a fix for something else.

[ports] Log of /head/databases/mariadb105-server/Makefile

svnweb.freebsd.org svnweb.freebsd.org
 
In the past I would always disable networking on mysql but now (MariaDB105-server it appears socket connectivity no longer behaves as in the past and the only way to connect is via 127.0.0.1.

Going to go back to 103 and rebuild dependent ports. ridiculous
 
Works fine with MariaDB 10.4, I suspect 10.5 isn't any different in this regard. Note that if you connect to localhost you are actually connecting to the socket, if you turn off DNS resolving (skip-name-resolve) then it doesn't work any more and you have to connect to 127.0.0.1.
 
After some mucking around, I believe I got hit by the new user scheme where db users need to configure how they connect to the db. I'll wait a bit for this to mature I suppose...
 
Make sure your socket settings are configured correctly in both the [client] and [server] sections.
 
going back to mariadb103-server required removing the following from /var/db/mysql/
aria_log_contro, ib_logfile0, ib_logfile1, ib_data1

also delete the "mysql" database as well and start afresh
make sure there is no entry referring to a file in a directory in /usr/local/etc/mysql in /usr/local/etc/my.cnf

otherwise the existing databases for your projects only require new users and permissions to access them again
Fortunately in my case it's a new fbsd install so rebuilding the data is not an issue, clearly downgrading to 103 most likely will destroy data
 
Default mysql socket file in /usr/local/etc/mysql/my.cnf is set to /var/run/mysql/ and the mysql deamon is running as mysql user so this user need to have write permission to /var/run/mysql in order to create the socket file. In the past this socket was in /tmp which was globally writable. Installation of mariadb via packages doesn't change the correct permissions of /var/run/mysql

Edit:
Ohh sorry i didn't see that SirDice already pointed that.
 
Instead of forcing to go back to 10.3 why not try 10.4? I have 10.4 running for quite some time now, and don't have any issues. Wanted to try 10.5 but it appears some of the applications I use don't support it yet, 10.5 is still very new.

Oclair said:
Fortunately in my case it's a new fbsd install so rebuilding the data is not an issue, clearly downgrading to 103 most likely will destroy data
Click to expand...
One typically makes a backup of the data before attempting to upgrade to a new version. And one generally tests this instead of just blindly upgrading a production database.
 
You must log in or register to reply here.
Back
Top