Mariadb startet nach Upgrade nicht mehr

[Mardor]

Hallo,

ich habe eine Nextcloud in einem Jail laufen. In diesem Jail läuft auch gleichzeitig eine Mariadb. Mein Problem ist, dass ich die Datenbank nach dem Update von mariadb 10.4.13 auf 10.4.13_2 nicht mehr starten kann.

service mysql-server restart
mysql not running? (check /var/db/mysql/clocklife.pid).
Starting mysql.

Auch ein Sockstat zeigt mir keine DB an

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS    
www      nginx      72133 6  tcp4   10.49.1.5:443         *:*
root     nginx      71196 6  tcp4   10.49.1.5:443         *:*
root     syslogd    64929 5  udp4   10.49.1.5:514         *:*

./mariadb-upgrade
Version check failed. Got the following error when calling the 'mysql' command line client
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (2)
FATAL ERROR: Upgrade failed

Leider sehe ich bei einem xtail auf das /usr/jail/<jailname>/var/log keinerlei Meldung, wenn ich mariadb über den genannten Befehl neustarten will.

Ich kann das Probleme auch immer wieder nachvollziehen, wenn ich einen Snapshot zurückspiele läuft alles wieder, wenn folgende Pakete upgrade läuft meine Nextcloud nicht mehr.

        ca_root_nss: 3.52 -> 3.53
        freetype2: 2.10.1 -> 2.10.2
        ghostscript9-agpl-base: 9.52_4 -> 9.52_5
        lcms2: 2.9 -> 2.10
        libnghttp2: 1.40.0 -> 1.41.0
        mariadb104-client: 10.4.13 -> 10.4.13_2
        mariadb104-server: 10.4.13 -> 10.4.13_2
        nginx: 1.18.0_2,2 -> 1.18.0_15,2
        oniguruma: 6.9.4 -> 6.9.5.r1_1
        perl5: 5.30.2 -> 5.30.3
        poppler-data: 0.4.9_2 -> 0.4.9_3
        vim-console: 8.2.0491_1 -> 8.2.0869

Hat jemand eine Idee wie ich das Problem am Besten entgegentreten kann ?

Gruß Mardor

 

[gadean]

Schau mal ins Error Log von mariadb.

 

[Mardor]

Hi,

danke für den Hinweis. Ich dachte der error log wäre per default an.

Allerdings bekomme ich auch beim Aktivieren in der my.cnf unter /usr/jail/<jailname>/usr/local/etc/my.cnf und einem Neustart keinen Log angelegt.

Der Inhalt der my.cnf ist:

[mariadb]
innodb_buffer_pool_size=1G
innodb_io_capacity=4000
log_error=/var/log/mariadb.err

Ich habe es auch mit [mysql] anstatt mariadb versucht.
Hast du irgend eine Idee ?

Gruß Mardor

 

[pchris]

Ich hatte ein ähnliches Problem vor Kurzem. Frag mich aber nicht, was es schlußendlich dann war.

Geholfen hat mir aber, das MariaDB executeable (mysqld) direkt zu starten. Das hat mir dann den lesbaren, relevanten Hinweis gegeben.

Nachtrag:

/usr/local/libexec/mysqld

 

[Mardor]

Danke für den Hinweis.

Ich hatte zumindest rausbekommen das die Berechtigung gefehlt hatte, den Log zu schreiben. Jetzt sehe ich beim direkten Starten:

/usr/local/libexec/mysqld
2020-06-12 15:45:58 0 [Note] /usr/local/libexec/mysqld (mysqld 10.4.13-MariaDB) starting as process 14635 ...

** /usr/jails/clocklife/var/log//mariadb.err ***
2020-06-12 15:45:58 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-06-12 15:45:58 0 [Note] InnoDB: Uses event mutexes
2020-06-12 15:45:58 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-06-12 15:45:58 0 [Note] InnoDB: Number of pools: 1
2020-06-12 15:45:58 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-06-12 15:45:58 0 [Note] InnoDB: Initializing buffer pool, total size = 1G, instances = 8, chunk size = 128M
2020-06-12 15:45:58 0 [Note] InnoDB: Completed initialization of buffer pool
2020-06-12 15:45:58 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-06-12 15:45:58 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-06-12 15:45:58 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-06-12 15:45:58 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-06-12 15:45:58 0 [Note] InnoDB: Waiting for purge to start
2020-06-12 15:45:58 0 [Note] InnoDB: 10.4.13 started; log sequence number 3187994710; transaction id 160447226
2020-06-12 15:45:58 0 [Note] InnoDB: Loading buffer pool(s) from /var/db/mysql/ib_buffer_pool
2020-06-12 15:45:58 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-06-12 15:45:58 0 [Note] Server socket created on IP: '127.0.0.1'.
2020-06-12 15:45:58 0 [ERROR] Can't start server : Bind on unix socket: No such file or directory
2020-06-12 15:45:58 0 [ERROR] Do you already have another mysqld server running on socket: /var/run/mysql/mysql.sock ?
2020-06-12 15:45:58 0 [ERROR] Aborting

Die Fehlermeldung wundert mich. Ich hatte geschaut ob noch eventuell mariadb und mysql installiert sind aber ich habe nix gefunden.

pkg info | grep db
mariadb104-client-10.4.13_2    Multithreaded SQL database (client)
mariadb104-server-10.4.13_2    Multithreaded SQL database (server)

pkg info | grep my
php72-mysqli-7.2.31            The mysqli shared extension for php
php72-pdo_mysql-7.2.31         The pdo_mysql shared extension for php

pkg info | grep sql
php72-mysqli-7.2.31            The mysqli shared extension for php
php72-pdo_mysql-7.2.31         The pdo_mysql shared extension for php

Ich hatte gesehen, dass ich in der rc.conf sowohl eine mysql als auch eine maria mit einem enable=YES versehen hatte. Jetzt habe ich aber mariadb auskommentiert damit nur noch mariadb gestartet wird. (Ich gehe davon aus das mariadb_enable="YES" sowieso überflüssig war. Aber trotz restart des Jail bekomme ich die Mariadb nicht ans laufen.

 

[Yamagi]

Existiert /var/run/mysql/ und hat MariaDB Schreibrechte darauf? Wenn ja, existiert vielleicht bereits ein /var/run/mysql/mysql.sock, den MariaDB nicht schreiben darf?

 

[Mardor]

Hallo Yamagi,

leider nicht

ls
clean_var         ld-elf.so.hints   libuuid           logpriv           php-fpm.pid       ppp               syslogd.sockets   wpa_supplicant
cron.pid          ld-elf32.so.hints log               nginx.pid         php72-fpm.sock    syslog.pid        utx.active

 

[Mardor]

Aber was ich eben gesehen habe ist:

service mysql-server restart
mysql not running? (check /var/db/mysql/<jailname>.pid).

Starting mysql.

/var/db/mysql: ls -alh
total 75
drwxr-xr-x   5 mysql  mysql    14B 12 Juni 15:46 .
drwxr-xr-x  14 root   wheel    18B 29 Mai  03:01 ..
-rw-rw----   1 mysql  mysql    52B 12 Juni 15:46 aria_log_control
-rw-rw----   1 mysql  mysql    80K 12 Juni 15:46 aria_log.00000001
-rw-rw----   1 mysql  mysql   181K 11 Juni 23:48 <jailname>.err
-rw-r-----   1 mysql  mysql    13K 11 Juni 23:48 ib_buffer_pool
-rw-rw----   1 mysql  mysql    48M 12 Juni 15:45 ib_logfile0
-rw-rw----   1 mysql  mysql    48M 27 Mai  09:26 ib_logfile1
-rw-rw----   1 mysql  mysql   114M 12 Juni 15:45 ibdata1
-rw-rw----   1 mysql  mysql     0B 17 Apr. 21:48 multi-master.info
drwx------   2 mysql  mysql    90B 17 Apr. 21:50 mysql
-rw-r-----   1 root   mysql    16B 17 Apr. 21:50 mysql_upgrade_info
drwx------   2 mysql  mysql    87B 17 Apr. 22:05 nextcloud
drwx------   2 mysql  mysql     3B 17 Apr. 21:50 performance_schema

Aber ein pid file habe ich nicht gefunden.

 

[gadean]

Wenn der Ordner /var/run/mysql nicht existiert, dann erstelle ihn und schau das mariadb dort Schreibrechte hat.

 

[Mardor]

Hallo gadean,

vielen Dank für deinen Tipp. Jetzt läuft mariadb wieder.

Allerdings existiert mein eigentliches Problem immer noch. Ich hatte gehofft, dass dies das eigentliche Problem gewesen wäre aber ich bekomme den Login Screen meiner Nextcloud leider nicht angezeigt.

Ist es denn üblich, dass ich zwei mysql Prozesse habe oder ist da noch ein Problem ?

ps aux
USER    PID %CPU %MEM    VSZ    RSS TT  STAT STARTED    TIME COMMAND
www   54236  0,3  0,1 182684  34836  -  SJ   20:23   0:00,10 php-fpm: pool www (php-fpm)
root  51302  0,3  0,0   7468   4232  4  SJ   20:24   0:00,03 -tcsh (tcsh)
www   40649  0,1  0,0  11472   8036  -  SJ   20:23   0:00,09 nginx: worker process (nginx)
www     398  0,0  0,1 182556  28836  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www    6175  0,0  0,1 182556  28836  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www    6681  0,0  0,1 182556  28840  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
root  14333  0,0  0,0   6420   2464  -  SsJ  20:23   0:00,00 /usr/sbin/syslogd -s
www   15638  0,0  0,1 182556  28844  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
root  35038  0,0  0,0  11472   7456  -  SsJ  20:23   0:00,00 nginx: master process /usr/local/sbin/nginx
mysql 42034  0,0  0,4 583512 124068  -  SJ   20:23   0:00,19 /usr/local/libexec/mysqld --defaults-extra-file=/var/db/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --plugin-dir=/usr/
root  49946  0,0  0,1 182556  28828  -  SsJ  20:23   0:00,01 php-fpm: master process (/usr/local/etc/php-fpm.conf) (php-fpm)
www   59332  0,0  0,1 182556  28828  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www   68938  0,0  0,1 182556  28828  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
mysql 70653  0,0  0,0   7096   2816  -  SsJ  20:23   0:00,01 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --pid-file=/var/d
www   74335  0,0  0,1 182556  28832  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
root  76327  0,0  0,0   6460   2336  -  SsJ  20:23   0:00,00 /usr/sbin/cron -s
www   81021  0,0  0,1 182556  28832  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www   89941  0,0  0,1 182556  28832  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www   92628  0,0  0,1 182556  28832  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
www   94920  0,0  0,1 182556  28836  -  SJ   20:23   0:00,00 php-fpm: pool www (php-fpm)
root  47806  0,0  0,0   6948   2852  4  SJ   20:24   0:00,01 login [pam] (login)
root  66826  0,0  0,0   6948   2704  4  R+J  20:24   0:00,00 ps aux

 

[gadean]

Von deinem "eigentlichen" Problem können wir nichts wissen, das hast du nicht erwähnt.
Aber auch hier gilt wieder, schau in das Error Log von php und nginx.

Bezüglich den mehreren Prozessen: Keine Ahnung, aber unüblich ist es nicht.

Edit: Noch dazu sind es zwei unterschiedliche Prozesse mysqld_safe & mysqld

 

[Mardor]

Hi,

definitiv konntet Ihr das nicht wissen, weil ich es nie erwähnt hatte. Ich war ja davon ausgegangen, dass nachdem das Mysql Issue gefixt ist auch die Nextcloud wieder funktioniert.

Aber auch hier gilt wieder, schau in das Error Log von php und nginx.

Ja, das hatte ich auch als aller erstes getan, aber auch hier sehe ich nix zielführendes, aber diesmal ist wenigstens ein Log vorhanden:

[12-Jun-2020 20:16:34] NOTICE: fpm is running, pid 13904
[12-Jun-2020 20:16:34] NOTICE: ready to handle connections
[12-Jun-2020 20:23:46] NOTICE: Finishing ...
[12-Jun-2020 20:23:46] NOTICE: exiting, bye-bye!
[12-Jun-2020 20:23:47] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful

[12-Jun-2020 20:23:47] NOTICE: fpm is running, pid 49946
[12-Jun-2020 20:23:47] NOTICE: ready to handle connections

... und der nginx error log zeigt als letzten Eintrag das Datum des 29.5.2020.

Kurz noch zur Beschreibung meiner Umgebung. Da ich bei hetzner ja nur eine IPv4 IP erhalte habe ich vor meiner Nextcloud Kiste einen NGINX als reverse Proxy stehen (eine simple Ubuntu Cloud Kiste). Dieser leitet die Anfragen direkt auf den eigentlichen Server um.

Lege ich im nextcloud Verzeichnis ein simples Testfile ala "Hallo dies ist ein Test" testfile.html an, so kann ich dieses File ohne Probleme erreichen. Lege ich eine phpinfo.php Datei an kann ich diese nicht angezeigt bekommen.

Der Nextcloud log zeigt mir folgende Meldung an, aber diese Meldung habe ich auch schon vor dem Update erhalten.:

{"reqId":"FKyGJkyDHGkwl6e7oZeu","level":3,"time":"2020-06-11T21:00:00+00:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"Version warning: Imagick was compiled against ImageMagick version 1801 but version 1802 is loaded. Imagick will run but may behave surprisingly at Unknown#0","userAgent":"--","version":"18.0.3.0"}

Edit: Der letzte Eintrag im Nextcloud Log ist bereits von gestern.
Edit: Der Access.log gibt mir nur aus, dass mein Server einen Status Code 500 zurück gibt, wenn die die Nextcloud anspreche.

 

[CommanderZed]

Hast du nurr mysql aktualisiert?

 

[Yamagi]

Edit: Noch dazu sind es zwei unterschiedliche Prozesse mysqld_safe & mysqld

mysqld ist die Datenbank an sich und mysqld_safe ist das Wrapperscript um sie herum. Das Wrapperscript stellt in erster Linie sicher, dass die Datenbank im Fall von Problemen nicht unendlich oft automatisch neu gestartet wird und sich durch wiederholtes Recovery selbst zerlegt.

Zum Thema Upgrade und NextCloud noch mal: Hast du mysql_upgrade durchlaufen lassen? Ohne können einige Tabellen eventuell nicht gelesen werden und das kann zu diversen Folgefehlern führen.

 

[Mardor]

Hallo,

danke für die Hinweise

Hast du nurr mysql aktualisiert?

Nein ich hatte folgende Pakete upgedatet.

        ca_root_nss: 3.52 -> 3.53
        freetype2: 2.10.1 -> 2.10.2
        ghostscript9-agpl-base: 9.52_4 -> 9.52_5
        lcms2: 2.9 -> 2.10
        libnghttp2: 1.40.0 -> 1.41.0
        mariadb104-client: 10.4.13 -> 10.4.13_2
        mariadb104-server: 10.4.13 -> 10.4.13_2
        nginx: 1.18.0_2,2 -> 1.18.0_15,2
        oniguruma: 6.9.4 -> 6.9.5.r1_1
        perl5: 5.30.2 -> 5.30.3
        poppler-data: 0.4.9_2 -> 0.4.9_3
        vim-console: 8.2.0491_1 -> 8.2.0869

Zum Thema Upgrade und NextCloud noch mal: Hast du mysql_upgrade durchlaufen lassen?

Ja, hatte ich gleich nachdem Mariadb liegt getan.

 

[CommanderZed]

Da du ja offensichtlich gar kein php aufrufen kannst, hat sich da an dem teil der webserverconfig etwas verändert die das php aktiviert?

(Ich kenn ngnix nicht, nutze nur openbsd-httpd intensiver und kenn aus ein paar kleinen beruflichen Projekten ein bisschen den apache2)

 

[SolarCatcher]

Ich bin auch gerade auf einige ernste Probleme mit dem mariadb104-server Upgrade gestoßen. Die Tipps hier waren gut. Wichtiger gewesen wäre für mich allerdings: UPDATING lesen!!! Da steht nämlich am 26. Mai 2020 drin:

Affects: users of databases/mariadb104-client, databases/mariadb104-server
Author: brnrd@FreeBSD.org
Reason:
  The ports now add sample configuration files to /usr/local/etc/mysql. You
  must merge your client configation with the conf.d/client.cnf and your
  server configuration with conf.d/server.cnf.

Da ist z.B. der neue Pfad zum Socket definiert (war früher standardmäßig /tmp/mysql.sock; ist jetzt /var/run/mysql/mysql.sock... ohne dass sichergestellt ist, dass dieser Pfad existiert und mysql die Berechtigung dafür hat). Außerdem - und das hat mich total verwirrt - war der Server auf einmal an 127.0.0.1 gebunden. Auch eine Änderung in /usr/local/etc/my.cnf auf bind-address = 0.0.0.0 brachte nix, weil - wie ich dann endlich herausfand - das in /usr/local/etc/mysql/conf.d/server.cnf wieder überschrieben wird...

Jetzt läuft alles wieder, aber ich muss nochmal im einzelnen durchgehen, ob ich ich die Server-Konfig noch anpassen muss.

 

[Mardor]

Ihr seit alle so unglaublich ! Danke für die vielen Tipps.

An den Update Logs hatte ich nicht gedacht und wie bei Dir hat es nix gebracht die "bind-Address" einzutragen.

cat /usr/local/etc/mysql/my.cnf
#
# This group is read both by the client and the server
# use it for options that affect everything, see
# https://mariadb.com/kb/en/configuring-mariadb-with-option-files/#option-groups
#
[client-server]
port   = 3306
socket = /var/run/mysql/mysql.sock

#
# include *.cnf from the config directory
#
!includedir /usr/local/etc/mysql/conf.d/

Gibt es eigentlich eine Option in der ich die altuell gültige Konfig einsehen kann ohne lange mehrere Dateien zu vergleichen ?
Das wäre dann einfacher die sample Konfiguration abzugleichen/mergen.

 

[Mardor]

Hi,

ich habe mir jetzt mehrfach den Changelog durchgelesen.

The ports now add sample configuration files to /usr/local/etc/mysql. You
must merge your client configation with the conf.d/client.cnf and your
server configuration with conf.d/server.cnf.

Ich verstehe nicht warum ich die server.cnf und die server.cnf.sample unter /usr/local/etc/mysql mergen sollte. Die Konfigurationsdatei ist doch /usr/local/etc/my.cnf /usr/local/etc/mysql/my.cnf ~/.my.cnf oder missinterpetiere ich die Information ?

Gibt es eigentlich eine Option in der ich die altuell gültige Konfig einsehen kann ohne lange mehrere Dateien zu vergleichen ?

Hier habe ich rausgefunden, dass ich in mariadb nach "SHOW VARIABLES LIKE" nach den aktuellen Settings suchen muss.


Gruß Mardor

 

[-Nuke-]

Hab gerade auch mal das Update gemacht. Ging natürlich auch bei mir schief, hauptsächlich weil vom Paket /var/run/mysql nicht angelegt wird.

Kann es aber sein, dass das mitgelieferte Init-Skript das Datenbank-Verzeichnis Setting komplett ignoriert und _immer_ /var/db/mysql benutzt wird, egal was in der server.cnf definiert wird?

 

[marmorkuchen]

Hab gerade auch mal das Update gemacht. Ging natürlich auch bei mir schief, hauptsächlich weil vom Paket /var/run/mysql nicht angelegt wird.

Kann es aber sein, dass das mitgelieferte Init-Skript das Datenbank-Verzeichnis Setting komplett ignoriert und _immer_ /var/db/mysql benutzt wird, egal was in der server.cnf definiert wird?

wird die server.cnf denn überhaupt von mysql gelesen?

 

[-Nuke-]

In der my.cnf steht zumindest includedir conf.d. Und das MySQL nicht nur auf 127.0.0.1 lauschen soll hat er ja zumindest übernommen.

 

[SolarCatcher]

Kleine Vorwarnung für MariaDB 10.5: Da gibt es lt. einem Tweet des Maintainers Bernard Spil nochmals einige wichtige Änderungen. Also vor einem Upgrade zu 10.5 gut durchlesen, was sich ändert.

PSA: The MariaDB 10.5 port for FreeBSD will use hier(7), so config in /usr/local/etc/mysql, socket in /var/run/mysql, logs in /var/log/mysql, ... Merge your configs ahead of time and define in rc.conf: mysql_optfile=/usr/local/etc/mysql/my.cnf

 

[Yamagi]

Ich habe die PostgreSQL-Diskussion herausgelöst: https://www.bsdforen.de/threads/postgresql-unter-wsl.35687/

 

[Mardor]

Hi,

irgendwie gehen mir die Änderungen und vielen Configfiles ja schon auf den Zeiger. Für jemanden der sich Vollzeit mit FreeBSD beschäftig mag das ja kein Problem sein, aber ich verbringe hier immer Stunden und schaffe es nicht weil ich wahrscheinlich wieder an 5000 falschen Stellen teste/Änderungen vornehme Danach lande ich doch wieder hier im Forum weil ich dann total verzweifelt aufgeben muss: Ich bin so froh das es dieses tolle Forum gibt ... ohne euch hätte ich glaube ich schon 1000fach aufgegeben.

Eigentlich sieht bei mir sockstat -4l gut aus aber ich bekomme meine nextcloud trotzdem nicht mehr ans laufen. Im mysql log sehe ich folgende Meldung:

020-07-05 16:59:11 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-07-05 16:59:11 0 [Note] InnoDB: Uses event mutexes
2020-07-05 16:59:11 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-07-05 16:59:11 0 [Note] InnoDB: Number of pools: 1
2020-07-05 16:59:11 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-07-05 16:59:11 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-07-05 16:59:11 0 [Note] InnoDB: Completed initialization of buffer pool
2020-07-05 16:59:11 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-07-05 16:59:11 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-07-05 16:59:11 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-07-05 16:59:11 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-07-05 16:59:11 0 [Note] InnoDB: Waiting for purge to start
2020-07-05 16:59:11 0 [Note] InnoDB: 10.4.13 started; log sequence number 3343406903; transaction id 161050645
2020-07-05 16:59:11 0 [Note] InnoDB: Loading buffer pool(s) from /var/db/mysql/ib_buffer_pool
2020-07-05 16:59:11 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-07-05 16:59:11 0 [Note] Server socket created on IP: '127.0.0.1'.
2020-07-05 16:59:11 0 [Note] Reading of all Master_info entries succeeded
2020-07-05 16:59:11 0 [Note] Added new Master_info '' to hash table
2020-07-05 16:59:11 0 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '10.4.13-MariaDB'  socket: '/var/run/mysql/mysql.sock'  port: 3306  FreeBSD Ports
2020-07-05 16:59:11 0 [Note] InnoDB: Buffer pool(s) load completed at 200705 16:59:11

cat /etc/rc.conf
..
mysql_enable="YES"
mysql_optfile=/usr/local/etc/mysql/my.cnf

cat /usr/local/etc/mysql/my.cnf
...
[client-server]
port    = 3306
socket  = /var/run/mysql/mysql.sock

Mein mariadb-upgrade sieht auch gut aus:

/usr/local/bin/mariadb-upgrade -u root -p
Enter password:
This installation of MariaDB is already upgraded to 10.4.13-MariaDB, use --force if you still need to run mysql_upgrade

Auch der socket ist listen am richtigen Port

sockstat -4l

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
mysql    mysqld     79080 16 tcp4   10.49.1.5:3306        *:*
...

cat /usr/local/etc/mysql/my.cnf

[client-server]
port    = 3306
socket  = /var/run/mysql/mysql.sock

Schlußendlich ist der Inhalt von /usr/local/etc/mysql/conf.d/sserver.cnf folgender:

[mysqld]
user                            = mysql
# port                          = 3306 # inherited from /usr/local/etc/mysql/my.cnf
# socket                        = /var/run/mysql/mysql.sock # inherited from /usr/local/etc/mysql/my.cnf
bind-address                    = 127.0.0.1
basedir                         = /usr/local
datadir                         = /var/db/mysql
net_retry_count                 = 16384
log_error                       = /var/log/mysql/${hostname}.err

Hättet Ihr einen Tipp ?