MariaDB Config-Änderungen greifen nicht

[Marco01_809]

Die Frage ist ja was da rein muss.

Ich habs hiermit probiert:
/etc/systemd/system/mariadb.socket.d/override.conf

[Service]
PrivateNetwork=true

Ich frage mich ob es im Systemd überhaupt ne passende Option gibt.
Hier ist ein Issue seit 6 Jahren auf wo genau das angefragt wird
https://github.com/systemd/systemd/issues/15172

Das sind beides Optionen für service units. Du modifizierst aber die socket unit, da kann auf keinen Fall eine [Service]-Section rein!

Lies dich mal zu den verschiedenen Unit-Typen von systemd ein. Die wichtigste ist natürlich die service unit, die beschreibt wie ein Prozess/Daemon ausgeführt wird (Befehl, Nutzer, Arbeitsverzeichnis, Beschränkungen u.s.w.). Im einfachsten Fall kann man so einen service natürlich immer beim Booten mitstarten lassen, aber man kann den service auch durch eine gleichnamige socket oder timer unit (moderne Alternative zu cronjobs) starten lassen. Die haben ihren eigenen Satz an Optionen, die relevanten hat @foofoobar hier schon rausgesucht.

Mit systemctl cat mariadb.socket kannst du dir anschauen wie die vorinstallierte socket unit konfiguriert ist.

Wichtig ist außerdem noch zu wissen dass die Optionen für die Addressen Listen sind und wie Listen in systemd units funktionieren. Wenn du im override

ListenAddress=1.2.3.4:3306

reinschreibst, dann hast du nur eine ZUSÄTZLICHE ListenAddress angegeben, aber die aus der vorinstallierten socket unit sind immer noch drin. Um eine Liste im override zu leeren muss man der option erstmal den leeren String zuweisen, z.B.

ListenAddress=
ListenAddress=1.2.3.4:3306

 

[foofoobar]

Mit systemctl cat mariadb.socket kannst du dir anschauen wie die vorinstallierte socket unit konfiguriert ist.

Es gibt nicht nur "cat" sondern auch "show":

show [PATTERN...|JOB...]
Show properties of one or more units, jobs, or the manager
itself. If no argument is specified, properties of the manager
will be shown. If a unit name is specified, properties of the
unit are shown, and if a job ID is specified, properties of
the job are shown. By default, empty properties are
suppressed. Use --all to show those too. To select specific
properties to show, use --property=. This command is intended
to be used whenever computer-parsable output is required. Use
status if you are looking for formatted human-readable output.

Many properties shown by systemctl show map directly to
configuration settings of the system and service manager and
its unit files. Note that the properties shown by the command
are generally more low-level, normalized versions of the
original configuration settings and expose runtime state in
addition to configuration. For example, properties shown for
service units include the service's current main process
identifier as "MainPID" (which is runtime state), and time
settings are always exposed as properties ending in the
"...USec" suffix even if a matching configuration options end
in "...Sec", because microseconds is the normalized time unit
used internally by the system and service manager.

For details about many of these properties, see the
documentation of the D-Bus interface backing these properties,
see org.freedesktop.systemd1(5).

cat PATTERN...
Show backing files of one or more units. Prints the "fragment"
and "drop-ins" (source files) of units. Each file is preceded
by a comment which includes the file name. Note that this
shows the contents of the backing files on disk, which might
not match the system manager's understanding of these units if
any unit files were updated on disk and the daemon-reload
command was not issued since.

Added in version 209.

https://man7.org/linux/man-pages/man1/systemctl.1.html

 

[Blutschlumpf]

Ich hab jetzt ne Weile rumexperimentiert, aber ohne Erfolg.

Dann bin ich darauf gestoßen:

web1:~# journalctl -xe
...
Sep 14 22:43:24 web1 systemd[1]: mariadb.socket: Socket service mariadb.service already active, refusing.
Sep 14 22:43:24 web1 systemd[1]: Failed to listen on mariadb.socket - MariaDB 10.11.18 database server (socket activation).
...

Und mir ist aufgefallen, dass der Socket nicht so wirklich ne Funktion hat, es ist augenscheinlich total belanglos ob der läuft

web1:~# lsof -i tcp -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 57u IPv6 12784 0t0 TCP *:mysql (LISTEN)
mariadbd 645 mysql 5u IPv6 12784 0t0 TCP *:mysql (LISTEN)
...

systemctl stop mariadb.socket

web1:~# lsof -i tcp -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mariadbd 645 mysql 5u IPv6 12784 0t0 TCP *:mysql (LISTEN)

MySQL auf localhost und von extern funktioniert in beiden Varianten.
/etc/systemd/system/mariadb.socket.d/override.conf war hier leer.

Setz ich da was rein, dann geht gar nichts mehr (zumindest wenn ich den socket zuerst starte):

/etc/systemd/system/mariadb.socket.d/override.conf:
[Socket]
ListenStream=
ListenStream=127.0.0.1:3306

Ergebnis:

web1:~# lsof -i tcp -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 55u IPv4 13657 0t0 TCP 127.0.0.1:mysql (LISTEN)
mariadbd 640 mysql 3u IPv4 13657 0t0 TCP 127.0.0.1:mysql (LISTEN)

web1:~# systemctl list-units --state=active | grep maria
mariadb.service loaded active running MariaDB 10.11.18 database server
mariadb.socket loaded active running MariaDB 10.11.18 database server (socket activation)
web1:~#

web1:~# mysql localhost
ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2)
web1:~#

web1:~# systemctl stop mariadb.service
web1:~# lsof -i tcp -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mariadbd 640 mysql 3u IPv4 13657 0t0 TCP 127.0.0.1:mysql (LISTEN)

web1:~# systemctl start mariadb.service

web1:~# lsof -i tcp -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mariadbd 1105 mysql 17u IPv4 16398 0t0 TCP *:mysql (LISTEN)
mariadbd 1105 mysql 18u IPv6 16399 0t0 TCP *:mysql (LISTEN)

Wenn ich den mariadb.socket nicht starte und mysql direkt konfiguriere (bind-address = 127.0.0.1), dann klappt es übrigens:

web1:~# lsof -i tcp -n
mariadbd 1255 mysql 17u IPv4 16861 0t0 TCP 127.0.0.1:mysql (LISTEN)

Das scheint mir aber nicht Sinn der Sache zu sein.
Ne Idee warum die Kombi nicht funktionieren könnte?

Abseist davon:
Spricht irgendwas dagegen den Socket nicht vom Systemd verwalten/starten zu lassen und MariaDB "klassisch" zu nutzen?
Was ich bis jetzt dazu gefunden habe (Bootdauer, Ressourcenverbrauch in konstruierten cases, kein Connectionabbruch bei Servioce-Neustart) ist hier belanglos.
Sprich muss ich damit rechnen, dass in 3 Wochen ein Update das wieder reinkonfiguriert, gibt es side-effects oder sowas in der Art?

 

[foofoobar]

Abseist davon:
Spricht irgendwas dagegen den Socket nicht vom Systemd verwalten/starten zu lassen und MariaDB "klassisch" zu nutzen?
Was ich bis jetzt dazu gefunden habe (Bootdauer, Ressourcenverbrauch in konstruierten cases, kein Connectionabbruch bei Servioce-Neustart) ist hier belanglos.

Sollte nix dagegen sprechen.
Vollständig verstehen was da abgeht wäre allerdings immer das Geilere.

Sprich muss ich damit rechnen, dass in 3 Wochen ein Update das wieder reinkonfiguriert, gibt es side-effects oder sowas in der Art?

Knips die unit vom OS aus, und bau dir eine mymaria unit.
Debian fragt IMHO bei Updates wenn Configs befummelt wurden.