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.

The fix seems to have been included in 1:10.11.19+deb12u1
but for some reason this bug is still open.

I did a few upgrades from 1:10.11.18+deb12u1 to 1:10.11.19+deb12u1.

Most of these worked fine, but in one case, mariadb failed to stop.
I think this was because mariadb was running under socket activation
but there must have been other factors at play; the couple of other
machines I checked were running under socket activation.

I have not been able to determine what the critical factor was.
Things I did check:
 - mysql not busy with a long query

 - /var/run paths to the socket in the config,
this was only found in my.cnf.fallback.

 - debian.cnf contains no socket path

[client]
host     = localhost
user     = root
protocol = socket
[mysql_upgrade]
host     = localhost
user     = root
protocol = socket

The upgrade started normally enough

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  mariadb-backup mariadb-client mariadb-client-core mariadb-server mariadb-server-core
5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.5 MB of archives.
After this operation, 636 kB of additional disk space will be used.
Do you want to continue? [Y/n]
...
Fetched 21.5 MB in 3s (8,258 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 86799 files and directories currently installed.)
Preparing to unpack .../mariadb-backup_1%3a10.11.19-0+deb12u1_amd64.deb ...
Unpacking mariadb-backup (1:10.11.19-0+deb12u1) over (1:10.11.18-0+deb12u1) ...
Preparing to unpack .../mariadb-server_1%3a10.11.19-0+deb12u1_amd64.deb ...
Warning: Stopping mariadb.service, but it can still be activated by:
  mariadb.socket
/var/lib/mysql: found previous version 10.11

at this point dpkg was stuck:

# ps -fade|grep maria
root      536865  536570  0 11:13 pts/4    00:00:00 /usr/bin/dpkg --status-fd 45 --no-triggers --unpack --auto-deconfigure
  /var/cache/apt/archives/mariadb-backup_1%3a10.11.19-0+deb12u1_amd64.deb
  /var/cache/apt/archives/mariadb-server_1%3a10.11.19-0+deb12u1_amd64.deb
  /var/cache/apt/archives/mariadb-server-core_1%3a10.11.19-0+deb12u1_amd64.deb
  /var/cache/apt/archives/mariadb-client-core_1%3a10.11.19-0+deb12u1_amd64.deb
  /var/cache/apt/archives/mariadb-client_1%3a10.11.19-0+deb12u1_amd64.
mysql     537002       1  0 11:13 ?        00:00:01 /usr/sbin/mariadbd
root      537018  537007  0 11:13 pts/4    00:00:00 /bin/sh /usr/sbin/invoke-rc.d mariadb stop
root      537021  537018  0 11:13 pts/4    00:00:00 systemctl stop mariadb.service


'systemctl status mariadb' was showing

Active: deactivating (final-sigterm) (Result: timeout)
TriggeredBy: * mariadb.socket

Eventually I killed the shell doing the restart (537018) and then dpkg (536570).

/var/lib/dpkg/tmp.ci/preinst: line 36: 537018 Killed                  invoke-rc.d mariadb stop
E: Sub-process /usr/bin/dpkg exited unexpectedly
W: Operation was interrupted before it could finish

The mariadb process sailed on, I could not access mysql.
# /usr/bin/mysql
<crickets>


After reading this bug, I ran these commands

# systemctl stop mariadb.socket.         #no impact?
# systemctl disable --now mariadb.socket
# systemctl mask mariadb.socket


'systemctl status mariadb' then showed:

Active: activating (auto-restart) (Result: resources)


but was not properly restarting because a mariadb process
was left running (this is why Result: was 'resources').

I waited for several minutes, then 'kill -9 <that process>'


At this point I was able to start the service normally.
# systemctl stop mariadb
Active: inactive (dead) since ...

# systemctl start mariadb

# systemct status mariadb

Active: active (running)
<no TriggeredBy line>

Kind regards

Hi!

Thanks for reporting
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1151058 and
following up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141976.

The regression was in 1:10.11.18+deb12u1 that included upstream commit
https://github.com/MariaDB/server/commit/9fa3f51f59f5b7a6d84c68a45e6a6579f55847b3
that lead to Debhelper (version 10) injecting extra lines as listed in
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/171#note_817952.

Initially 1:10.11.18-0+deb12u1 was only in bookworm-proposed-updates
and wasn't let into Bookworm itself due to the regression. However,
once Bookworm went into LTS, all pending proposed updates were
released, so unfortunately all users who upgraded .17->.18 potentially
hit this.

The fix in .19 does not have this regression anymore. Upgrades from
.17 to .19 skip this issue.

The fix does however not include any workaround to shut down
potentially existing socket activated instances. If you want to spend
time developing such a fix, you are welcome to do so and submit your
contribution in the open source spirit at
https://salsa.debian.org/mariadb-team/mariadb-server. Alternatively,
if you have a support contract with some provider, you can request
them to engineer the fix for you (and potentially also submit it to
Debian).

For anyone who ran into this issue and wanted to manually fix it,
simply run `pgrep -ef mariadbd` and/or `pgrep -ef mysqld` and look at
your process listings to see that all instances have shut down. After
that you can restart your system or just restart the systemd service
to let systemd manage starting the service.

Hi Otto,

Thanks for the reply and for explaining the .18 regression.

I'd like to clarify one point, because I think it is separate from
#1141976. The incident happened during the .18 -> .19 upgrade. The
socket being enabled by .18 is what made it possible, but the failure
itself comes from the maintainer scripts stopping mariadb.service while
mariadb.socket stays active. dpkg warned about exactly that:

   Warning: Stopping mariadb.service, but it can still be activated by:
     mariadb.socket

As I understand it, this leaves two open issues:

1. Hosts that went through .18 still have mariadb.socket enabled after
upgrading to .19, unless the admin noticed and disabled it. On those
hosts, the next security update can hit the same race. Since these
updates are usually applied by unattended-upgrades, that may happen with
nobody watching.

2. The same race applies to anyone who enables socket activation
deliberately, regardless of .18.

SendSIGKILL=no makes the outcome much worse. The stalled instance cannot
be stopped, systemd refuses to start the service while it exists, and
the socket keeps accepting connections that are never served. Clients
hang instead of failing.

Could you confirm whether the .19 maintainer scripts stop mariadb.socket
during upgrades? If they don't, would you accept a change that stops
mariadb.socket together with mariadb.service before unpacking and starts
both again in postinst (only if the socket was active before)?

Regards,
José Gonçalves