debian package restarts mariadb during schema upgrade

[white-haired-uncle]

First let me point out I may be doing something a little weird here. I probably am. This is MX Linux 25, no systemd, package built using pbuilder (per process at https://wiki.mythtv.org/wiki/Installing_MythTV_on_Debian -- but I wrote that so it's not like I'm just following directions). And because I'm looking to automate the install process (skip the "will other machines connect to this" question), I install like this:

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y mythtv

That said...

To test another issue, I'm uninstalling (drop mythconverg, apt remove mythtv-common, mythtv user access remains configured in mariadb, mythtv user/config.xml remains) and reinstalling repeatedly. The schema update keeps failing on me, and I only get about 20 tables (not always the same number). This last time I noticed the package add did something like:

stopping mariadb...
starting mariadb...

right near the end. My first thought was, of course, "and just who gave you permission to do that???" [perhaps I did with DEBIAN_FRONTEND=noninteractive?]. But it also gave me a clue.

2026-06-30T19:51:56.637687-04:00 mx25 mythbackend: mythbackend[49869]: C CoreContext dbcheckcommon.cpp:113 (performActualUpdate) Upgrading to MythTV schema version 1382
2026-06-30T19:52:33.972588-04:00 mx25 mythbackend: mythbackend[49869]: D CoreContext mythdbcon.cpp:975 (lostConnectionCheck) SQL Native Error Code: 2013
2026-06-30T19:52:33.972640-04:00 mx25 mythbackend: mythbackend[49869]: E CoreContext dbcheckcommon.cpp:89 (performUpdateSeries) DB Error (Performing MythTV database upgrade): #012Query was: CREATE TABLE `gallery_directories` (  `dir_id` int NOT NULL AUTO_INCREMENT,  `filename` varchar(255) NOT NULL,  `name` varchar(255) NOT NULL,  `path` varchar(255) NOT NULL,  `parent_id` int NOT NULL,  `dir_count` int NOT NULL DEFAULT '0',  `file_count` int NOT NULL DEFAULT '0',  `hidden` tinyint(1) NOT NULL DEFAULT '0',  PRIMARY KEY (`dir_id`)) ENGINE=MyISAM DEFAULT CHARSET=utf8; #012Error was: Driver error was [2/2013]:#012QMYSQL: Unable to execute query#012Database error was:#012Lost connection to server during query
2026-06-30T19:52:33.972656-04:00 mx25 mythbackend: mythbackend[49869]: E CoreContext dbcheck.cpp:449 (tryUpgradeTVDatabaseSchema) Database schema upgrade failed
2026-06-30T19:52:33.972706-04:00 mx25 mythbackend: mythbackend[49869]: I CoreContext mythdbcon.cpp:850 (prepare) MySQL server disconnected
2026-06-30T19:52:33.972720-04:00 mx25 mythbackend: mythbackend[49869]: I CoreContext mythdbcon.cpp:647 (exec) MySQL server disconnected

And look what happens at the same time over in syslog:

2026-06-30T19:52:33.904288-04:00 mx25 mysqld: 2026-06-30 19:52:33 0 [Note] /usr/sbin/mariadbd (initiated by: root[root] @ localhost []): Normal shutdown
2026-06-30T19:52:34.347080-04:00 mx25 mysqld: 2026-06-30 19:52:34 0 [Note] InnoDB: FTS optimize thread exiting.
2026-06-30T19:52:35.023458-04:00 mx25 mysqld: 2026-06-30 19:52:35 0 [Note] InnoDB: Starting shutdown...

It appears that the install process starts mythbackend and then restarts mariadb while the schema update is in progress.

2:36.0+fixes.20260620.a833aecd84-0debian0

P.S. Also noted that this happened shortly before mariadb got restarted. I guess that would explain why rsyslogd's pid changed. Doesn't explain where it got permission to restart syslog (a HUP I can live with, bouncing processes is no bueno).

2026-06-30T19:52:14.698061-04:00 mx25 rsyslogd: [origin software="rsyslogd" swVersion="8.2504.0" x-pid="49993" x-info="https://www.rsyslog.com"] start

[white-haired-uncle]

Setting up mythtv-backend (2:36.0+fixes.20260620.a833aecd84-0debian0) ...
Restarting MythTV server: mythbackend No /usr/bin/mythbackend found running; none killed.
.
.
Setting up mythtv-frontend (2:36.0+fixes.20260620.a833aecd84-0debian0) ...
Setting up mythtv-database (2:36.0+fixes.20260620.a833aecd84-0debian0) ...
Processing triggers for menu (2.1.51) ...
Processing triggers for mailcap (3.74) ...
Processing triggers for desktop-file-utils (0.28-1) ...
Processing triggers for gnome-menus (3.36.0-3) ...
Processing triggers for rsyslog (8.2504.0-1) ...
Stopping enhanced syslogd: rsyslogd.
Starting enhanced syslogd: rsyslogd.
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for mariadb-server (1:11.8.6-0+deb13u1) ...
Stopping MariaDB database server: mariadbd.
Starting MariaDB database server: mariadbd . ..
Setting up mythtv (2:36.0+fixes.20260620.a833aecd84-0debian0) ...

[white-haired-uncle]

Can't reproduce on ubuntu24, either mysql or mariadb. mariadb does not get restarted (rsyslog does, though no message during install).

DEBIAN_FRONTEND=noninteractive doesn't seem to make any difference (on mx).

The starting/stopping messages are identical to /etc/init.d/{mariadb,rsyslogd}, but I can't find anything in packaging that looks like it would call invoke/init.d. From the messages it kind of looks like it's coming from "Processing triggers for mariadb-server...". Who owns these "triggers", the package, or something provided by the OS? I suppose they're getting triggered because of the config files the mythtv packages install. I wonder why mx thinks maria needs a restart and ubuntu doesn't, and why no message from ubuntu when rsyslog is restarted (the latter I'll just blame on systemd). I think I need to try debian next.

No luck reproducing on Debian. It did make me notice something. To reproduce this, the mysql_tzinfo stuff will need to have been done already (this might have been why it worked on the initial install, but then fails when re-installing), otherwise the database schema update won't start.

I suppose next up would be MX w/systemd and then Devuan. I'm wondering if the triggers are handled differently (okay, they are, but differently in that it causes the issue). Update: Rebooted MX into systemd mode and mariadb was NOT restarted during (re)install.
Problem DOES occur on Devuan (no systemd).

The workaround for my specific case seems to be just let it fail, drop mythconverg, create mythconverg, restart mythbackend. Which is fine, for my specific case. What is concerning is upgrades where a schema update is required (possibly specifically upgrading from non-package older schema to current package with newer schema). I suppose drop mythconverg, create mythconverg, restore mythconverg, restart mythbackend is probably going to work, but intentionally breaking the database as part of an upgrade doesn't sound like much of a plan.

Actually, it's not that complicated to trigger (I think, haven't tested). Just do a clean install on a system that already has mariadb (or mysql?) with the timezone stuff loaded. That should fail too, it's effectively what I've been doing, I just got so wrapped up in what I was doing I couldn't see that. I think.

Can the package be changed such that it simply doesn't start mythbackend on install/upgrade, at least on non-systemd infected systems? Let the user start mythbackend AFTER the database has been restarted. That might also (if done for all systems, not just sd-free) help with mythtv starting before rsyslog, and possibly #215 as well (under certain circumstances, and not with mariadb atm).