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 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Ben Eastep
2019-04-28 00:39:50 UTC
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?
|