Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hi! I suggested in my mail on Feb 28th to have this in the MariaDB preinstall: pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd" It would safely shut down the Akonadi server before MariaDB goes into update and the binary it uses vanishes for a while. However I never got any confirmation/support for this, so I didn't proceed with it. If you want to contribute in the open source way to fix this or any other issue, see https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian on how to submit a Merge Request! The places you would want to modify are: https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.preinst#L31 https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.postrm#L17
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hey, can you explain, why this is now an issue and wasn't for several Debian versions? As I package Akonadi for a while now I never had issues with Mariadb upgrades. I know from Postgres that you need to have both version installed ( old+new) to make a successfully upgrade, wouldn't that be a possible solution for MariaDB too? So that you do not remove the old mariadb-server version when installing the new one? Than a user can re-login and everything is fine. > But I would expect that to end up as a severe policy violation; I don't have > a reference handy though. That is at least also in my head, that it is not allowed to start/stop user processes. Regards, hefee PS: sorry I'm not a lot on my PC the last weeks. signature.asc Description: This is a digitally signed message part.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
On Tuesday, March 7, 2023 8:37:31 AM CET Otto Kekäläinen wrote: > In this case the server is run automatically by the Akonadi package. > Thus the Akonadi package should do something about the server > stop/starts automatically. Surely the Akonadi package has some > facility that starts/stops the server? What is that facility? Can we > call it from the MariaDB server preinstall script to shut it down, and > from the postinstall script to start up again? It is a user process run in a user session, so it is not something the package maintainers should touch. But akonadictl stop for all users in question would do it. Then remember which users you did it for, and akonadictl start afterwards for those users But I would expect that to end up as a severe policy violation; I don't have a reference handy though. Also be aware that the users mail client, calendar app and similar will be greyed out and text on top : "Akonadi not running" and then a giant button in the middle that says "start akonadi" tempting users to press it. And it does what it says on the tin. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
> But this does not as such seem to be akonadi specific; it could also happen in > a case where a system administrator runs a custom mariadb instance managed as > a different instance than what the mariadb/mysql stop scripts handles. The difference is that if a sysadmin manually has built some custom thing and runs it, they will know about it and are likely able to fix it. In this case the server is run automatically by the Akonadi package. Thus the Akonadi package should do something about the server stop/starts automatically. Surely the Akonadi package has some facility that starts/stops the server? What is that facility? Can we call it from the MariaDB server preinstall script to shut it down, and from the postinstall script to start up again?
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
On Tuesday, March 7, 2023 7:59:04 AM CET Otto Kekäläinen wrote: > This is still waiting for input from Akonadi maintainers: I've been thinking trying to come up with some good solutions. But this does not as such seem to be akonadi specific; it could also happen in a case where a system administrator runs a custom mariadb instance managed as a different instance than what the mariadb/mysql stop scripts handles. I do though think that the akonadi instance is more likely. I think that - in order fix both; basically error out not only if the invoke- rc.d calls fail, but if there are any running mariadb instances left on the system and let the system administrator deal with it. That will probably cover most issues. Except the one I ran into* I think it is the best we can do for now. If I had a infinite wishlist, it would be to let newer mariadb's be able to also fix older setups, or a separate tool being able to do that. /Sune * I had a desktop system lockup for unknown reasons; rebooted and didn't login as me, but rather dropped into a VT and did a upgrade, then rebooted and logged in. I ended up debootstrapping a slightly older chroot with a slightly older mariadb, bindmounting the mariadb datadirs into it, launching and stopping mariadb inside it. unmounting and removing. -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
This is still waiting for input from Akonadi maintainers: On Thu, 2 Mar 2023 at 23:44, Otto Kekäläinen wrote: > > (Adding akonadi-backend-mysql maintainers as recipients) > > Hi! > > When MariaDB Server upgrades, it could trigger a restart in > akonadi-backend-mysql, or the maintainer scripts could directly stop > the akonadi-backend-mysql. I am open to any solution here. > > The main question is: what are the expectations from Akonadi on > MariaDB upgrades? > > If MariaDB completely ignores Akonadi, you might run into problems > because Akonadi/mysqld did not have a clean shutdown on MariaDB 10.5 > and then MariaDB 10.11 will fail to start because crash recovery > across major versions. Before going into major version upgrade the old > server needs to be stopped gracefully with for example `pkill mysqld` > (or a more elaborate version matching other binary names and checking > for process owning user etc). If MariaDB stops the server something > needs to exist to restart it. > > Merge Requests on Salsa against > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.preinst#L27-47 > are welcome! And side note: the libmariadb3 issue was reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031773, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031860 and forwarded upstream in https://lists.launchpad.net/maria-discuss/msg06508.html
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Small addendum: I'm running Debian testing.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
(Adding akonadi-backend-mysql maintainers as recipients) Hi! When MariaDB Server upgrades, it could trigger a restart in akonadi-backend-mysql, or the maintainer scripts could directly stop the akonadi-backend-mysql. I am open to any solution here. The main question is: what are the expectations from Akonadi on MariaDB upgrades? If MariaDB completely ignores Akonadi, you might run into problems because Akonadi/mysqld did not have a clean shutdown on MariaDB 10.5 and then MariaDB 10.11 will fail to start because crash recovery across major versions. Before going into major version upgrade the old server needs to be stopped gracefully with for example `pkill mysqld` (or a more elaborate version matching other binary names and checking for process owning user etc). If MariaDB stops the server something needs to exist to restart it. Merge Requests on Salsa against https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/mariadb-server.preinst#L27-47 are welcome!
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hi Otto, Sry, it was my error - I'm indeed on debian buster here and referring to the bug #1031770. I mixed it up. Regards Rai Am 01.03.2023 um 08:13 schrieb Otto Kekäläinen: > So Rai has /usr/sbin/mysqld-akonadi from package akonadi-backend-mysql: > > /usr/sbin/mysqld-akonadi > --defaults-file=/home/rai/.local/share/akonadi/mysql.conf > --datadir=/home/rai/.local/share/akonadi/db_data/ > --socket=/tmp/akonadi-rai.bxYrSB/mysql.socket > --pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid > > Rai was running Debian buster (=oldstable). > > Steven has another version (Bullseye/stable?) with: > > /usr/sbin/mysqld > --defaults-file=/home/username/.local/share/akonadi/mysql.conf > --datadir=/home/username/.local/share/akonadi/db_data/ > --socket=/run/user/1000/akonadi/mysql.socket > --pid-file=/run/user/1000/akonadi/mysql.pid > > The process detection indeed would be more robust if it checked for > owner 'mysql'. So we could switch it to run this instead? > > pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd" > > Just need to be careful that this is run only on systems where the > user 'mysql' already exist, otherwise pgrep will return an error. > > > The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770 > Rai mentioned is unrelated. Let's not mix the discussion about that > into this one about the preinstall script process check.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
So Rai has /usr/sbin/mysqld-akonadi from package akonadi-backend-mysql: /usr/sbin/mysqld-akonadi --defaults-file=/home/rai/.local/share/akonadi/mysql.conf --datadir=/home/rai/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-rai.bxYrSB/mysql.socket --pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid Rai was running Debian buster (=oldstable). Steven has another version (Bullseye/stable?) with: /usr/sbin/mysqld --defaults-file=/home/username/.local/share/akonadi/mysql.conf --datadir=/home/username/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid The process detection indeed would be more robust if it checked for owner 'mysql'. So we could switch it to run this instead? pgrep -u root,mysql -x --nslist pid --ns $$ "mysqld|mariadbd" Just need to be careful that this is run only on systems where the user 'mysql' already exist, otherwise pgrep will return an error. The issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770 Rai mentioned is unrelated. Let's not mix the discussion about that into this one about the preinstall script process check.
Bug#1032047: [debian-mysql] Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hi! Not sure if that helps but there is also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031860 that seems to be also relevant to that bug report. Cheers! -- Faustin GPG: F652 BCD1 1AA8 8975 F010 48A5 390A 2F27 832A 5C79 signature.asc Description: PGP signature
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hey Otto $ pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" 362286 $ pgrep -af "mysql|mariadb" 362286 /usr/sbin/mysqld --defaults-file=/home/username/.local/share/akonadi/mysql.conf --datadir=/home/username/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid The akonadiserver is controlled by app-org.kde.kalendarac@autostart.service, so that's what I stopped for the upgrade. I don't use the KDE calendar or the rest of the KDE PIM suite, so I don't know if it was really a good idea to just interrupt this service. I also have no clue how akonadi-backend-mysql would handle mysqld/mariadbd upgrades. Would it be a good idea to limit the search for running mysqlds/mariadbds to those run by the mysql user (and perhaps root)? Greetings -Steven On 27/02/2023 06:46, Otto Kekäläinen wrote: Hi! Thanks for reporting this. What does the exact process listing look like on a system that has the Akonadi server running? What do these commands below yield on your system? pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" pgrep -af "mysql|mariadb" Indeed, the preinst has a section where it tries to stop any existing servers. This section has been there for years and years, this is nothing new in 10.11. Maybe it should have an extra check for Akonadi in particular, or maybe some trigger for Akonadi to restart the embedded MariaDB it has.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hi Otto,
below the information you requested from my system:
pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
none
pgrep -af "mysql|mariadb"
1908 /usr/sbin/mysqld-akonadi
--defaults-file=/home/rai/.local/share/akonadi/mysql.conf
--datadir=/home/rai/.local/share/akonadi/db_data/
--socket=/tmp/akonadi-rai.bxYrSB/mysql.socket
--pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid
The problem has been described here first:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770
I will give an overview:
kontact (kmail, kalendar) does not work anymore
the akonadi error file shows:
org.kde.pim.akonadiserver: DATABASE ERROR:
org.kde.pim.akonadiserver: Error code: "1292"
org.kde.pim.akonadiserver: DB error: "Incorrect datetime value:
'2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1"
org.kde.pim.akonadiserver: Error text: "Incorrect datetime value:
'2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1
QMYSQL: Unable to execute query"
org.kde.pim.akonadiserver: Query: "INSERT INTO PimItemTable (rev, remoteId,
remoteRevision, gid, collectionId, mimeTypeId, datetime, atime, dirty, size)
VALUES (:0, :1, :2, :3, :4, :5, :6, :7, :8, :9)"
org.kde.pim.akonadiserver: Error during insertion into table "PimItemTable"
"Incorrect datetime value: '2023-02-22T12:00:36Z' for column
`akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query"
The culprit seems to be:
libmariadb3_1%3a10.3.38-0+deb10u1_amd64.deb
which has been updated on my system last Tuesday:
2023-02-21 07:30:26 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2
1:10.3.38-0+deb10u1
The next morning, kmail was broken.
If I understood it well, this was an upgrade from 10.3.36 to 10.3.38.
Paul did some research and it seems this commit to be the problem:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/773fb3e04ffae2b4868876be632fb7244329e7c3
Looking at the diff, I found the following change to
libmariadb/libmariadb/mariadb_lib.c:
@@ -3879,7 +3881,7 @@ int STDCALL mysql_set_server_option(MYSQL *mysql,
ulong STDCALL mysql_get_client_version(void)
{
- return MARIADB_VERSION_ID;
+ return MARIADB_PACKAGE_VERSION_ID;
}
BTW, I'm not using any oldstable stuff.
My sources.list looks like:
deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free
deb http://security.debian.org/debian-security buster/updates main contrib
non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib
non-free
deb http://ftp.de.debian.org/debian/ buster-updates main non-free
deb-src http://ftp.de.debian.org/debian/ buster-updates main non-free
So it looks to me that whith a security update a functional change came in.
If I can help more, let me know.
Regards
Rai
Am 27.02.2023 um 06:46 schrieb Otto Kekäläinen:
> Hi!
>
> Thanks for reporting this. What does the exact process listing look
> like on a system that has the Akonadi server running?
>
> What do these commands below yield on your system?
>
> pgrep -x --nslist pid --ns $$ "mysqld|mariadbd"
> pgrep -af "mysql|mariadb"
>
> Indeed, the preinst has a section where it tries to stop any existing
> servers. This section has been there for years and years, this is
> nothing new in 10.11. Maybe it should have an extra check for Akonadi
> in particular, or maybe some trigger for Akonadi to restart the
> embedded MariaDB it has.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Hi! Thanks for reporting this. What does the exact process listing look like on a system that has the Akonadi server running? What do these commands below yield on your system? pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" pgrep -af "mysql|mariadb" Indeed, the preinst has a section where it tries to stop any existing servers. This section has been there for years and years, this is nothing new in 10.11. Maybe it should have an extra check for Akonadi in particular, or maybe some trigger for Akonadi to restart the embedded MariaDB it has.
Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.
Package: mariadb-server Version: 1:10.11.2-1 Severity: normal X-Debbugs-Cc: steven.dehe...@gmail.com Dear Maintainer, I tried to upgrade mariadb-server-10.6 to mariadb-server 10.11.2-1, but it failed with these errors (part of aptitude's output): """ Preparing to unpack .../mysql-common_5.8+1.1.0_all.deb ... Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.8) ... Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ... Unpacking mariadb-common (1:10.11.2-1) over (1:10.6.11-2) ... Preparing to unpack .../default-mysql-server_1.1.0_all.deb ... Unpacking default-mysql-server (1.1.0) over (1.0.8) ... (Reading database ... 331692 files and directories currently installed.) Removing mariadb-server-10.6 (1:10.6.11-2) ... dpkg: mariadb-server-core-10.6: dependency problems, but removing anyway as you requested: akonadi-backend-mysql depends on default-mysql-server-core | virtual-mysql-server-core; however: Package default-mysql-server-core is not installed. Package virtual-mysql-server-core is not installed. Package mariadb-server-core-10.6 which provides virtual-mysql-server-core is to be removed. Removing mariadb-server-core-10.6 (1:10.6.11-2) ... dpkg: warning: while removing mariadb-server-core-10.6, directory '/usr/share/mysql' not empty so not removed Selecting previously unselected package mariadb-server-core. (Reading database ... 331482 files and directories currently installed.) Preparing to unpack .../mariadb-server-core_1%3a10.11.2-1_amd64.deb ... Unpacking mariadb-server-core (1:10.11.2-1) ... Preparing to unpack .../libmariadb3_1%3a10.11.2-1_amd64.deb ... Unpacking libmariadb3:amd64 (1:10.11.2-1) over (1:10.6.11-2) ... Preparing to unpack .../default-mysql-client_1.1.0_all.deb ... Unpacking default-mysql-client (1.1.0) over (1.0.8) ... dpkg: mariadb-client-10.6: dependency problems, but removing anyway as you requested: wordpress depends on default-mysql-client | virtual-mysql-client; however: Package default-mysql-client is not configured yet. Package virtual-mysql-client is not installed. Package mariadb-client-10.6 which provides virtual-mysql-client is to be removed. Package mariadb-client-10.5 which provides virtual-mysql-client is not installed. Package mariadb-client-10.3 which provides virtual-mysql-client is not installed. dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; however: Package default-mysql-client is not configured yet. Package virtual-mysql-client is not installed. Package mariadb-client-10.6 which provides virtual-mysql-client is to be removed. Package mariadb-client-10.5 which provides virtual-mysql-client is not installed. Package mariadb-client-10.3 which provides virtual-mysql-client is not installed. (Reading database ... 331590 files and directories currently installed.) Removing mariadb-client-10.6 (1:10.6.11-2) ... dpkg: mariadb-client-core-10.6: dependency problems, but removing anyway as you requested: default-mysql-client-core depends on mariadb-client-core-10.6. Removing mariadb-client-core-10.6 (1:10.6.11-2) ... Selecting previously unselected package mariadb-client-core. (Reading database ... 331476 files and directories currently installed.) Preparing to unpack .../mariadb-client-core_1%3a10.11.2-1_amd64.deb ... Unpacking mariadb-client-core (1:10.11.2-1) ... Preparing to unpack .../default-mysql-client-core_1.1.0_all.deb ... Unpacking default-mysql-client-core (1.1.0) over (1.0.8) ... Selecting previously unselected package mariadb-client. Preparing to unpack .../mariadb-client_1%3a10.11.2-1_amd64.deb ... Unpacking mariadb-client (1:10.11.2-1) ... Setting up mysql-common (5.8+1.1.0) ... Setting up mariadb-common (1:10.11.2-1) ... Selecting previously unselected package mariadb-server. (Reading database ... 331590 files and directories currently installed.) Preparing to unpack .../00-mariadb-server_1%3a10.11.2-1_amd64.deb ... /var/lib/mysql: found previous version 10.6 Failed to stop mariadb.service: Unit mariadb.service not loaded. invoke-rc.d: initscript mariadb, action "stop" failed. Failed to stop mysql.service: Unit mysql.service not loaded. invoke-rc.d: initscript mysql, action "stop" failed. Attempt to stop MariaDB/MySQL server returned exitcode 5 There is a MariaDB/MySQL server running, but we failed in our attempts to stop it. Stop it yourself and try again! dpkg: error processing archive /tmp/apt-dpkg-install-qINyMU/00-mariadb-server_1%3a10.11.2-1_amd64.deb (--unpack): new mariadb-server package pre-installation script subprocess returned error exit status 1 """ So if I understand correctly, at the moment of unpacking the new mariadb-server, there is no system-wide mariadb.service running or indeed any *.service file present, but I did have akonadiserver running which spawns its own mysqld process. Thus the stop_server function in preinst fails as it does detect a mysql process but 'invoke-rc.d mariadb stop' gives an error. When I manually stopped akonadi's mariadb
