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
