Hello!

On Debian 12, after the upgrade to 1:10.11.18-0+deb12u1, I find that
mariadb.socket has been activated without any input or consent from me.

This results in mariadb-server now suddenly being available to *:3306
(i.e. the Internet if no firewall is configured) instead of just
127.0.0.1:3306.

This is very unfortunate, as this potentially exposes the server to attacks.

Here is how the state of the socket looks before and after the upgrade:


Pre-Upgrade:
○ mariadb.socket - MariaDB 10.11.14 database server (socket activation)
     Loaded: loaded (/lib/systemd/system/mariadb.socket; static)
     Active: inactive (dead)
   Triggers: ● mariadb.service
       Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
     Listen: @mariadb (Stream)
             /run/mysqld/mysqld.sock (Stream)
             [::]:3306 (Stream)

Post-Upgrade:
○ mariadb.socket - MariaDB 10.11.18 database server (socket activation)
     Loaded: loaded (/lib/systemd/system/mariadb.socket; enabled; preset: enabled)
     Active: inactive (dead)
   Triggers: ● mariadb.service
       Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
     Listen: @mariadb (Stream)
             /run/mysqld/mysqld.sock (Stream)
             [::]:3306 (Stream)

After Reboot:

● mariadb.socket - MariaDB 10.11.18 database server (socket activation)
     Loaded: loaded (/lib/systemd/system/mariadb.socket; enabled; preset: enabled)
     Active: active (running) since Mon 2026-07-13 06:53:13 CEST; 6s ago
   Triggers: ● mariadb.service
       Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
     Listen: @mariadb (Stream)
             /run/mysqld/mysqld.sock (Stream)
             [::]:3306 (Stream)
      Tasks: 0 (limit: 9481)
     Memory: 4.0K
        CPU: 592us
     CGroup: /system.slice/mariadb.socket

Jul 13 06:53:13 ml systemd[1]: Starting mariadb.socket - MariaDB 10.11.18 database server (socket activation)...
Jul 13 06:53:13 ml systemd[1]: Listening on mariadb.socket - MariaDB 10.11.18 database server (socket activation).

No manual change has been done my me, just "apt full-upgrade".

Because mariadbd is running at the moment, this won't have an effect
until rebooting the system, which is an additional wrinkle, masking the
new unsafe situation even further, obscuring the reason for the change.

Grüße,
Sven!

Hi,

* Sven Hartge [Mon Jul 13, 2026 at 06:54:43AM +0200]:

[...]

I can confirm this behavior, which I also just noticed on one of my
systems.

regards
-mika-

Hello,

adding to my report:

The reason is that the mariadb.socket shipped with 10.11.18 now includes
an [Install] part, which then makes dh-installsystemd act upon it and
activating it.

The unit shipped in 10.11.14 did not include this and was therefor
marked as "static" and inert.

To me the sensible way forward is to quickly ship a new package in
Debian, reverting that change, restoring the old behavior.

And also be on the lookout for similar changes in Debian 13 and 14,
since it is _not_ obvious to the admin, that "bind_address" is no longer
respected when MariaDB is used via mariadb.socket.

Grüße,
Sven.

I have run into this issue as well. mariadb will not start after a
server restart because port 3306 is already in use.

  This fixed it for me:

systemctl disable mariadb.socket

Hello,

I have a galera cluster and this update makes any server not working if
rebooted, probably due to the socket activation bye the other nodes in
the cluster.

Disable the socket works also for me.

Thanks for the work.
E.

Hi!

Thanks for reporting this.

An itemized list of all changes in this release is visible at
https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/12-bookworm

This is probably a result of upstream commit
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f1aaa7518461c346c06d4ed0701b42552129cfc5
?

The commit for the change in behavior is this one here:

https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/9fa3f51f59f5b7a6d84c68a45e6a6579f55847b3

It adds the [Install] section to the socket unit, which then causes it
to be activated by debhelper, if I understand the mechanism correctly.

Reverting that commit is probably the correct way forward here.
I have no idea how to detect and revert the accidental activation in
systems that have installed the problematic mariadb-server package, as
there might be admins that do indeed have activated it manually before.

Apart from that, what I continue to see as a major problem here is the
lack of documentation about the fact that "bind-address" in your
mariadbd configuration will be silently ignored it you use the socket
activation.

This change is something that IMO needs a NEWS entry and big bold
letters plastered around that configuration item in the 50-server.cnf to
alert users to that fact.

And suddenly activating that feature also obviously needs to be avoided
to released version of Debian.

Grüße,
Sven.

I can confirm this regression on Debian 12 after upgrading:

mariadb-server 1:10.11.14-0+deb12u2
to
mariadb-server 1:10.11.18-0+deb12u1

My server configuration explicitly contains:

[mysqld]
bind-address = 0.0.0.0
port = 3307

MariaDB reads this configuration correctly:

$ mariadbd --print-defaults | tr ' ' '\n' | grep '^--port'
--port=3307

However, after the upgrade, the server was listening on port 3306:

$ ss -lntp | grep -E ':3306|:3307'
LISTEN 0 4096 *:3306
/:/users:(("mariadbd",pid=6193,fd=5),("systemd",pid=1,fd=52))

Disabling and masking mariadb.socket restored the configured behavior:

$ systemctl disable --now mariadb.socket
$ systemctl mask mariadb.socket
$ systemctl restart mariadb.service

Afterward, MariaDB correctly listened on the configured port:

$ netstat -lpn | grep 330
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 9290/mariadbd

This appears to be a security-sensitive stable-release regression
because a routine package upgrade can cause MariaDB to listen on a
different TCP port than the one explicitly configured by the administrator.

Please consider ensuring that existing installations retain their
previous listener configuration unless socket activation is explicitly
enabled by the administrator.

FYI, I filed this now upstream for tracking and visibility.

The MariaDB update 10.11.18-0+deb12u1 shipped intentionally the new
file /usr/lib/tmpfiles.d/mariadb.conf. The
/lib/systemd/system/mariadb.socket and other *.socket files were
already shipped in previous .14 version.

What is different is the change in maintainer scripts that activate
the socket files. The maintainer scripts are tracked by my build
system and I should have spotted this change before the upload, but I
only noticed it now:
--- /home/otto/.cache/debcraft/debcraft-build-mariadb-1782468123.10d4c8b1102+debian.12.bookworm/maintainer-scripts.log
2026-06-26 16:03:45.434503826 +0300
+++ /home/otto/.cache/debcraft/debcraft-build-mariadb-1782843142.b8ac6607961+debian.12.bookworm/maintainer-scripts.log
2026-06-30 21:41:38.299654301 +0300
@@ -822,6 +822,23 @@
 # End automatically added section
 # Automatically added by dh_systemd_enable/13.11.4
 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
+ # The following line should be removed in trixie or trixie+1
+ deb-systemd-helper unmask 'mariadb.socket' >/dev/null || true
+
+ # was-enabled defaults to true, so new installations run enable.
+ if deb-systemd-helper --quiet was-enabled 'mariadb.socket'; then
+ # Enables the unit on first installation, creates new
+ # symlinks on upgrades if the unit file has changed.
+ deb-systemd-helper enable 'mariadb.socket' >/dev/null || true
+ else
+ # Update the statefile to add new symlinks (if any), which need to be
+ # cleaned up on purge. Also remove old symlinks.
+ deb-systemd-helper update-state 'mariadb.socket' >/dev/null || true
+ fi
+fi
+# End automatically added section
+# Automatically added by dh_systemd_enable/13.11.4
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
  if deb-systemd-helper debian-installed 'mariadb.service'; then
  # The following line should be removed in trixie or trixie+1
  deb-systemd-helper unmask 'mariadb.service' >/dev/null || true
@@ -837,6 +854,30 @@
  deb-systemd-helper update-state 'mariadb.service' >/dev/null || true
 fi
 # End automatically added section
+# Automatically added by dh_systemd_enable/13.11.4
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
+ if deb-systemd-helper debian-installed 'mariadb.socket'; then
+ # The following line should be removed in trixie or trixie+1
+ deb-systemd-helper unmask 'mariadb.socket' >/dev/null || true
+
+ if deb-systemd-helper --quiet was-enabled 'mariadb.socket'; then
+ # Create new symlinks, if any.
+ deb-systemd-helper enable 'mariadb.socket' >/dev/null || true
+ fi
+ fi
+
+ # Update the statefile to add new symlinks (if any), which need to be cleaned
+ # up on purge. Also remove old symlinks.
+ deb-systemd-helper update-state 'mariadb.socket' >/dev/null || true
+fi
+# End automatically added section
+# Automatically added by dh_installinit/13.11.4
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
+ if [ -x "$(command -v systemd-tmpfiles)" ]; then
+ systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create
mariadb.conf >/dev/null || true
+ fi
+fi
+# End automatically added section
 # Automatically added by dh_installinit/13.11.4
 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
  if [ -x "/etc/init.d/mariadb" ]; then
@@ -967,14 +1008,14 @@
 # Automatically added by dh_systemd_enable/13.11.4
 if [ "$1" = "purge" ]; then
  if [ -x "/usr/bin/deb-systemd-helper" ]; then
- deb-systemd-helper purge 'mariadb.service' >/dev/null || true
+ deb-systemd-helper purge 'mariadb.service' 'mariadb.socket' >/dev/null || true
  fi
 fi
 # End automatically added section
 # Automatically added by dh_systemd_enable/13.11.4
 if [ "$1" = "purge" ]; then
  if [ -x "/usr/bin/deb-systemd-helper" ]; then
- deb-systemd-helper purge 'mariadb.service' >/dev/null || true
+ deb-systemd-helper purge 'mariadb.service' 'mariadb.socket' >/dev/null || true
  fi
 fi
 # End automatically added section

These sections were added by
https://manpages.debian.org/unstable/debhelper/dh_systemd_enable.1.en.html
but the man page does now explain *why*. Somehow it reacted to the
[Install] part added in
https://github.com/MariaDB/server/commit/9fa3f51f59f5b7a6d84c68a45e6a6579f55847b3

As someone who runs a dozen mariadb-server instances at home: I think
the new behavior is too disruptive for servers in production. People who
are following
[#1141976](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141976)
probably would agree with me. It's unpleasant for sysadmins to have to
deal with a non-working mariadb server after a reboot.

Also this bug is not reproduced on trixie or unstable. This is bookworm
specific, which is good news.

A fix is ready here:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/171

Pending review.