| Summary: | koha-common and mariadb start in the wrong order | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Ben Eastep <shifting-koha> |
| Component: | Packaging | Assignee: | Bugs List <koha-bugs> |
| Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | dcook, joonas.kylmala, josef.moravec, mirko |
| Version: | 18.11 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Crowdfunding goal: | 0 |
| Patch complexity: | --- | Documentation contact: | |
| Documentation submission: | Text to go in the release notes: | ||
| Version(s) released in: | Circulation function: | ||
I couldn't come up with any way to fix this issue in Koha Debian packages. The database could as well be in a remote server so it looks like it is up to the person upgrading koha-common package to make sure database is accepting connections during the upgrade. What we could probably do is recommend users to upgrade first koha-common and then the database separately, although one might want to coordinate the upgrade so that when the database is down some nice maintenance page is shown or use a database cluster to keep koha running all the time. Some might suggest adding a retry time (for example 10 seconds) but who knows how long a give DB server upgrade might take. I suggest closing this issue and editing the instructions in wiki. Ben, does this sound good? Well, maybe creating a new debian package for one server installations we could add mysql-server as dependency and then this would work but I have not seen this done anywhere with other debian packages so not sure it's worth the extra packaging work and would even work. This is a really interesting point. I've been thinking a lot about database upgrades lately. Kong Gateway can be installed by a Debian package, but it requires a person running "kong migrations up" to trigger an actual database upgrade. Keycloak will apply database migrations/upgrades automatically when you start the application. I'd suggest moving a lot of the code from koha-common.postinst into the koha-common service (ie /etc/init.d/koha-common). Then koha-common.postinst could just restart the koha-common service. An optional dependency on Mariadb could be added, so koha-common would wait to restart until after Mariadb is available. If the Mariadb service isn't available on that server, it'll just ignore the dependency.
> I suggest closing this issue and editing the instructions in wiki. Ben, does
> this sound good?
Could someone help with the instructions on the wiki?
|
when running my last apt-upgrade, koha-common and mariadb both updated. Unfortunately, koha tried to configure before mariadb did, meaning that the database server was still stopped when koha tried to run it's configuration: Setting up linux-image-amd64 (4.9+80+deb9u7) ... Setting up koha-common (18.11.04-1) ... Upgrading database schema for library DBI connect('database=koha_theatrealberta;host=localhost;port=3306','koha_theatrealberta',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory") at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1517. DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory") at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1520. at /usr/share/koha/lib/Koha/Database.pm line 107 dpkg: error processing package koha-common (--configure): subprocess installed post-installation script returned error exit status 255 Setting up mariadb-server-10.1 (10.1.38-0+deb9u1) ... of course, this was easy to fix by running "dpkg-configure -a" again. But it would be nice if these packages configured themselves in the right order.