MariaDB Config-Änderungen greifen nicht

Blutschlumpf

Fleet Admiral
Registriert
März 2001
Beiträge
20.801
Hallo,

ich habe ein Problem auf nem Debian 13 + MariaDB (10.11.18-MariaDB-0+deb12u1).
Die DB war mal mysql und ist dann über die Debian-Migrationslogik vor Jahren auf Maria-DB gewechselt.
Die Config ist afair komplett out-of the Box, da wurde also nichts gefrickelt.

Mir ist aufgefallen, dass mariadb/mysql auf allen Interfaces statt nur lo antwortet.
"bind-address" ist allerdings auf 127.0.0.1 gesetzt.

Ich habe dann testweise mal den TCP Port (/etc/mysql/mariadb.cnf) und bind-address (/etc/mysql/mariadb.conf.d/50-server.cnf) markant verändert.

Damit soll man prüfen können welche Config greift, die scheint also nicht anderwo her überschrieben zu werden:
Code:
web1:/etc/mysql# mysqld --verbose --help | grep port
...
port                                                         3307

web1:/etc/mysql# mysqld --verbose --help | grep bind
  --bind-address=name IP address to bind to. Several addresses may be
bind-address                                                 127.0.0.99
web1:/etc/mysql#

Allerdings ändert das nichts daran was der dann daraus macht.
Ich hätte ja jetzt zumindest nen Fehler erwartet weils die 127.0.0.99 nirgendwo gibt, aber meine Änderungen bewirken einfach gar nichts:
Code:
web1:/etc/mysql# service mysql status
● mariadb.service - MariaDB 10.11.18 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-09-07 23:43:45 CEST; 4s ago
TriggeredBy: ● mariadb.socket
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 550428 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && echo _WSREP_START_POSITION=$VAR > /run/mysqld/wsrep-start-position || exit 1 (code=exited, status=0/SUCCESS)
    Process: 550501 ExecStartPost=/bin/rm -f /run/mysqld/wsrep-start-position /run/mysqld/wsrep-new-cluster (code=exited, status=0/SUCCESS)
    Process: 550503 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
   Main PID: 550489 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 14 (limit: 30887)
     Memory: 111.6M
        CPU: 343ms
     CGroup: /system.slice/mariadb.service
             └─550489 /usr/sbin/mariadbd

Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated socket host :: port 3306
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated unix socket /run/mysqld/mysqld.sock
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated unix socket @mariadb
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] /usr/sbin/mariadbd: ready for connections.
Sep 07 23:43:45 web1 mariadbd[550489]: Version: '10.11.18-MariaDB-0+deb12u1'  socket: 'Systemd socket activated ports'  port: 3306  Debian 12
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] InnoDB: Buffer pool(s) load completed at 260907 23:43:45
Sep 07 23:43:45 web1 systemd[1]: Started mariadb.service - MariaDB 10.11.18 database server.
Sep 07 23:43:45 web1 /etc/mysql/debian-start[550505]: Upgrading MySQL tables if necessary.
Sep 07 23:43:45 web1 /etc/mysql/debian-start[550508]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Sep 07 23:43:45 web1 /etc/mysql/debian-start[550516]: Checking for insecure root accounts.

Muss ich da was beachten weil der systemd da mit reinspielt?
Code:
web1:~# lsof -i tcp -n
COMMAND  PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd    1        root   57u  IPv6  12853      0t0  TCP *:mysql (LISTEN)
mariadbd 645       mysql    5u  IPv6  12853      0t0  TCP *:mysql (LISTEN)

Unter /etc/systemd/ hab ich nichts hilfreiches gefunden.
Hab auch schon die ganze Kiste testweise restartet.
 
Welche Files hast du unter: /etc/mysql/ ? Gibt es hier vielleicht mehr config files? Kannst du mal die Inhalte der config Files posten? Oder Anhängen. Scheint als würdest du evtl. die falschen Dateien bearbeiten.
 
Was soll den das Ziel der Veränderung sein? Die Bindung an eine andere IP/Netzwerkkarte?
Ergänzung ()

@Muffknutscher

Eigentlich sollten die cnf-Dateien unter /etc/mysql/mariadb.conf.d/ liegen.
 
Zuletzt bearbeitet:
@TomTDooley

Genau... Eigentlich... Und eigentlich sollte die config Änderung hätte greifen sollen.

Genau deshalb wäre gut zu wissen was da alles so Rum gammelt, auch in den Unterordnern.
 
Hi, geh mal ins Verzeichnis /etc/mysql/mariadb.conf.d/ und leg dir eine eigene Konfigurationsdatei (z. B. 90-meine_Einstellung.cnf) an. In die Datei schreib mal folgendes:

[server]

[mysqld]

bind-address = <deine IP Adresse>
port = <deine Portnummer>

Speichere die Datei und starte mariadb neu. Greifen die Parameter? Was zeigt die Ausgabe von ss -tln ?
 
@Muffknutscher

Wir warten einfach ab, was der TE zum "Ziel" schreibt?
Alternative eine Regel in der Firewall die Port und IP begrenzt.

für IP-Tables: (rules.v4)

-A INPUT -p tcp -m tcp -i lo --dport 3306 -j ACCEPT

oder

-A INPUT -p tcp -m tcp -i eth0 --dport 3306 -j DROP
(eth0, je nach Bezeichnung z.B. enp1s0, enp2s0 etc. pp.)
 
Zuletzt bearbeitet:
Blutschlumpf schrieb:
Code:
bind-address                                                 127.0.0.99
web1:/etc/mysql#
Ich hätte ja jetzt zumindest nen Fehler erwartet weils die 127.0.0.99 nirgendwo gibt, aber meine Änderungen bewirken einfach gar nichts:
Woher kommt diese IP? Habe ich so noch nirgends bei den zahlreichen MariaDB Installationen gesehen. Ich würde das auf 127.0.0.1 ändern.
 
foofoobar schrieb:
-p" funzt nur als root.
Korrekt, da Debian in der Standard Installation kein sudo kann habe ich es weg gelassen. Spätesten wenn nach Eingabe folgende Meldung kommt sollte es für "Linuxer" eigentlich klar sein.

No info could be read for "-p": geteuid()=1000 but you should be root.

Korrekt wäre es unter Ubuntu Standard
sudo netstat -lntup | grep mariadbd

und Debian Standard (ein Beispiel von mehreren!)
su -
netstat -lntup | grep mariadbd
 
ZFS schrieb:
[server]

[mysqld]

bind-address = <deine IP Adresse>
port = <deine Portnummer>
Ist an sich auch nicht korrekt, entweder kommt da localhost rein, oder die IP(s), die von zugreifen dürfen. Soll es für alles zugreifbar sein, kommt 0.0.0.0 rein.
https://mariadb.com/docs/server/mariadb-quickstart-guides/mariadb-remote-connection-guide
bind-address: This directive specifies the IP address the server listens on.


  • By default, for security, many MariaDB packages bind to 127.0.0.1 (localhost). This means the server will only accept connections originating from the server machine itself via the loopback interface. Remote connections will fail.

  • If bind-address is set to 127.0.0.1, attempting to connect from another host, or even from the same host using a non-loopback IP address, will result in errors like:


    Copy
    ERROR 2002 (HY000): Can't connect to MySQL server on 'myhost' (115)
    A telnet myhost 3306 test would likely show "Connection refused."

  • To allow connections from other hosts, you must either comment out the bind-address directive (making MariaDB listen on all available network interfaces, i.e., 0.0.0.0 for IPv4), or set it to a specific public IP address of the server.

  • MariaDB 10.11 and later: bind-address can accept multiple comma-separated IP addresses, allowing the server to listen on specific interfaces while excluding others.
 
@nutrix

Die 127.0.0.99 hat er manuell eingetragen.
Ergänzung ()

---

Zitat: " Mir ist aufgefallen, dass mariadb/mysql auf allen Interfaces statt nur lo antwortet."
 
  • Gefällt mir
Reaktionen: nutrix
nutrix schrieb:
Ist an sich auch nicht korrekt, entweder kommt da localhost rein, oder die IP(s), die von zugreifen dürfen. Soll es für alles zugreifbar sein, kommt 0.0.0.0 rein.
Da hast du natürlich recht. 0.0.0.0 eintragen, wenn es für alle Netzwerkverbindungen gelten soll. Kann es sein, dass nur eine IPV6 Verbindung konfiguriert wurde?
mariadbd 645 mysql 5u IPv6 12853 0t0 TCP *:mysql (LISTEN)
 
Blutschlumpf schrieb:
Die DB war mal mysql und ist dann über die Debian-Migrationslogik vor Jahren auf Maria-DB gewechselt.
Die Config ist afair komplett out-of the Box, da wurde also nichts gefrickelt.
Ist die Datenbank groß? Vielleicht mal die DB komplex exportieren, MariaDB bzw. MySQL mal komplett deinstallieren, und dann komplett neu installieren.
Ergänzung ()

TomTDooley schrieb:
Die 127.0.0.99 hat er manuell eingetragen.
Danke, jetzt ist der Groschen gefallen, noch kein Kaffee heute.
 
  • Gefällt mir
Reaktionen: TomTDooley
Melde dich mal am Datenbankserver an, und gib auf der Kommandzeile den Befehl

show global variables like '%bind%';

ein. Was wird hier angezeigt? Ich vermute :: oder *.
 
  • Gefällt mir
Reaktionen: dichter-karl
Es liegt an der socket activation:
Blutschlumpf schrieb:
Code:
# service mysql status
[...]
TriggeredBy: ● mariadb.socket
Dabei legt Systemd die Sockets für MariaDB an, startet MariaDB selbst aber noch nicht. Erst wenn eine Verbindung eingeht wird MariaDB schnell gestartet und die Sockets, samt der Verbindung, an MariaDB übergeben. Mehr zum Thema Socket Activation hier.

MariaDB schreibt auch in den Log dass es die Sockets nimmt, die Systemd angelegt hat:
Blutschlumpf schrieb:
Code:
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated socket host :: port 3306
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated unix socket /run/mysqld/mysqld.sock
Sep 07 23:43:45 web1 mariadbd[550489]: 2026-09-07 23:43:45 0 [Note] Using systemd activated unix socket @mariadb
Wenn MariaDB startet wurden die Sockets schon längst angelegt, ergo kann die mariadb conf keine Auswirkungen mehr auf die Adressen haben.

Siehe MariaDB Doku:
When MariaDB is run under systemd socket activation, the usual socket, port, and backlog system variables are ignored, as these settings are contained within the systemd socket definition file.

There is no configuration required in MariaDB to use MariaDB under socket activation.

The systemd options available are from the systemd documentation, however ListenStream and BackLog would be the most common configuration options.

As MariaDB isn't creating these sockets, the sockets don't need to be created with a mysql user. The sockets MariaDB may end up listening to under systemd socket activation, it may have not had the privileges to create itself.
Alle anderen Einstellungen in der mariadb conf sollten aber problemlos funktionieren.

Wenn du die Adressen anpassen willst dann eine drop-in config für die socket unit anlegen:
Changes to the default mariadb.socket can be made in the same way as services, systemctl edit mariadb.socket, or using /etc/systemd/system/mariadb.socket.d/someconfig.conf files.
 
  • Gefällt mir
Reaktionen: Piktogramm, Blutschlumpf, konkretor und eine weitere Person
Dann sollte aber nach einem Server-Neustart der Socket geändert werden.

----

Solange wir keine weiteren Infos vom TE bekommen, können wir nur "ins Blaue" hineinraten.

Bei einem Webserver macht das aber durchaus Sinn, dass MariaDB nicht über eine öffentliche IP erreichbar ist.
Ist der Server "öffentlich" oder ist das nur ein Projekt-Entwicklungsserver ohne Zugang zum Internet?

-----

Ich mag diese halben Fragen nicht, auf die man das "ganze" Antworten geben soll.
 
Auch wenn es für die Thematik im Grunde vollkommen irrelevant ist wie und warum ich das möchte:
Das Teil hängt im Internet und da soll halt nur der Webserver auf der Public IP lauschen.
Das hat afair (vor Jahren als der initial aufgesetzt wurde) auch mit der obigen Config funktioniert.
Soweit ich das sehe hat Debian Systemd mit Debian 8 eingeführt, es kann durchaus sein, dass da initial Debian 6 oder 7 drauf lief.
Und ja, man kann das Problem mit iptables/nftables beheben/umgehen/kaschieren, ich wollte aber wissen warum es auftritt.

Die anderen Fragen zum Config-Inhalt überspringe ich mal weil es ja offenkundig wie befürchtet am Systemd liegt.

Marco01_809 schrieb:
Wenn du die Adressen anpassen willst dann eine drop-in config für die socket unit anlegen:
Die Frage ist ja was da rein muss.

Ich habs hiermit probiert:
/etc/systemd/system/mariadb.socket.d/override.conf
Code:
[Service]
PrivateNetwork=true

Der Beschreibung nach müsste das die Netzwerkanbindung entweder ganz unterbinden oder auf lo beschränken.
Ändert aber augenscheinlich gar nichts.
Habs auch mit der gleichen Config unter /etc/systemd/system/mariadb.service.d/override.conf versucht

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
 
Es wäre durchaus schick gewesen wenn du den Output der hier vorgeschlagenen Diagnosen oder auch das unit-file hergezeigt hättest. Diese immer wieder vorkommende Geheimniskrämerei ist seltenst zielführend.

Ansonsten:
ListenStream=, ListenDatagram=, ListenSequentialPacket=
Specifies an address to listen on for a stream (SOCK_STREAM), datagram (SOCK_DGRAM), or sequential packet (SOCK_SEQPACKET) socket, respectively. The address can be written in various formats:

If the address starts with a slash ("/"), it is read as file system socket in the AF_UNIX socket family.

If the address starts with an at symbol ("@"), it is read as abstract namespace socket in the AF_UNIX family. The "@" is replaced with a NUL character before binding. For details, see unix(7).

If the address string is a single number, it is read as port number to listen on via IPv6. Depending on the value of BindIPv6Only= (see below) this might result in the service being available via both IPv6 and IPv4 (default) or just via IPv6.

If the address string is a string in the format "v.w.x.y:z", it is interpreted as IPv4 address v.w.x.y and port z.

If the address string is a string in the format "[x]:y", it is interpreted as IPv6 address x and port y. An optional interface scope (interface name or number) may be specified after a "%" symbol: "[x]:y%dev". Interface scopes are only useful with link-local addresses, because the kernel ignores them in other cases. Note that if an address is specified as IPv6, it might still make the service available via IPv4 too, depending on the BindIPv6Only= setting (see below).

If the address string is a string in the format "vsock:x:y", it is read as CID x on a port y address in the AF_VSOCK family. The CID is a unique 32-bit integer identifier in AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may be set to the empty string. "vsock" may be replaced with "vsock-stream", "vsock-dgram" or "vsock-seqpacket" to force usage of the corresponding socket type.

Note that SOCK_SEQPACKET (i.e. ListenSequentialPacket=) is only available for AF_UNIX sockets. SOCK_STREAM (i.e. ListenStream=) when used for IP sockets refers to TCP sockets, SOCK_DGRAM (i.e. ListenDatagram=) to UDP.

These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses of any of these options will have no effect.

It is also possible to have more than one socket unit for the same service when using Service=, and the service will receive all the sockets configured in all the socket units. Sockets configured in one unit are passed in the order of configuration, but no ordering between socket units is specified.

If an IP address is used here, it is often desirable to listen on it before the interface it is configured on is up and running, and even regardless of whether it will be up and running at any point. To deal with this, it is recommended to set the FreeBind= option described below.
https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html
 

Ähnliche Themen

Zurück
Oben