Upgrade from MMonit 3.x to 4.0 does not work

[sseide]

i tried to upgrade my 3.5 version of the MMonit system to the current 4.0 version.
During the upgrade the necessary database upgrade is not running therefor MMonit does no start up.

I think the problem is due to the order of the startup steps done. It seems the database upgrade is tried first and afterwards the new configuration files are created. Due to this the new MMonit 4.x upgrade script is executed with an invalid (old 3.x) license and does not run.

The second start up MMonit (after config file upgrade) is correctly using the new 4.x license and logs error messages only for having the wrong db table versions.

Full Log output of the startup:

[migrations] started
[migrations] no migrations found
usermod: no changes
───────────────────────────────────────
  _____ __ __ _____ _____ _____ _____ 
 |     |  |  |   __|_   _|     |     |
 |   --|  |  |__   | | | |  |  | | | |
 |_____|_____|_____| |_| |_____|_|_|_|
       _____ __ __ _ __    ____  
      | __  |  |  | |  |  |    \ 
      | __ -|  |  | |  |__|  |  |
      |_____|_____|_|_____|____/ 

  Based on images from linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    911
User GID:    911
───────────────────────────────────────

Environment init-mmonit-upgrade:
    PUID=
    PGID=
    TZ=UTC
    MMONIT_LIMIT_FD=4096
    MMONIT_OS=alpine
    MMONIT_VERSION=4.0.0
[custom-init] No custom files found, skipping...
crond[148]: crond (busybox 1.36.1) started, log level 7
Upgrading from 3.7.15-alpine to 4.0.0
Upgrading M/Monit from /config/mmonit-3.7.15-alpine to /config/mmonit-4.0.0 ...

***WARNING*** please wait and DO NOT INTERRUPT the process (the upgrade can take some time if your database is large)

Reading license in '/config/mmonit-3.7.15-alpine/conf/server.xml'
Starting Reactor using epoll (max concurrent connections = 1048476)
Copying configuration files from /config/mmonit-3.7.15-alpine/conf/ to /config/mmonit-4.0.0/conf/ ... done
Copying uploaded files from /config/mmonit-3.7.15-alpine/docroot/uploads/ to /config/mmonit-4.0.0/docroot/uploads/ ... done
Reactor stopped
+------------------------------------------------------------------------------+
| LICENSE EXPIRED                                                              |
|                                                                              |
| This is M/Monit version 4.0.0, released, November 17, 2023. Your license was |
| registred on April 15, 2015. Please renew your license to upgrade to this    |
| version of M/Monit.                                                          |
|                                                                              |
| When you renew your license, you'll get a year of updates for M/Monit. Once  |
| that year is up, you can renew again or continue forever using the last      |
| version of M/Monit you updated to.                                           |
|                                                                              |
| Please go to https://mmonit.com/user to renew your M/Monit license and       |
| paste your renewed license below or enter q to abort this upgrade process.   |
+------------------------------------------------------------------------------+

New License key>
crond[148]: USER root pid 161 cmd run-parts /etc/periodic/15min


Please enter a valid M/Monit license to upgrade.
init-mmonit-upgrade done
Environment init-mmonit:
    PUID=
    PGID=
    TZ=UTC
    MMONIT_LIMIT_FD=4096
    MMONIT_OS=alpine
    MMONIT_VERSION=4.0.0
Unsetting TLS version

init-mmonit done
Starting mmonit 4.0.0
mmonit    | AssertException: Unsupported database schema version: 16 -- please run database upgrade script(s) to update M/Monit to version 4.0.0 (database schema version 19)
...

[sseide]

had a talk with Tildeslash about some problems around the migration from 3 to 4.

This problem here is rooted in the way MMonit does its update. For the update process the old configuration files from the 3.x directory are copied into the new (current 4.x) directory and the migration process starts than.
Running interactive the "upgrade" program asks for a new license.

upgrade -p /config/mmonit-3.7.15-alpine/
Upgrading M/Monit from /config/mmonit-3.7.15-alpine to /opt/mmonit-4.0.0 ...

***WARNING*** please wait and DO NOT INTERRUPT the process (the upgrade can take some time if your database is large)

Reading license in '/config/mmonit-3.7.15-alpine/conf/server.xml'
Copying configuration files from /config/mmonit-3.7.15-alpine/conf/ to /opt/mmonit-4.0.0/conf/ ... done
Copying uploaded files from /config/mmonit-3.7.15-alpine/docroot/uploads/ to /opt/mmonit-4.0.0/docroot/uploads/ ... done
+------------------------------------------------------------------------------+
| LICENSE EXPIRED                                                              |
|                                                                              |
| This is M/Monit version 4.0.0, released, November 17, 2023. Your license was |
| registred on April 15, 2015. Please renew your license to upgrade to this    |
| version of M/Monit.                                                          |
|                                                                              |
| When you renew your license, you'll get a year of updates for M/Monit. Once  |
| that year is up, you can renew again or continue forever using the last      |
| version of M/Monit you updated to.                                           |
|                                                                              |
| Please go to https://mmonit.com/user to renew your M/Monit license and       |
| paste your renewed license below or enter q to abort this upgrade process.   |
+------------------------------------------------------------------------------+

New License key>

Running manually you can enter your new license and the process goes on without problems.
Manually replacing the license inside the old server.xml before starting the container / upgrade process solves this.

But with your automation the old 3.x license remains in the server.xml of the old 3.x directory and is replaced after the (failed) upgrade process only inside the new 4.0 directory.

As this is a new case that did not happen for years i do not know how much to automate here or publish some workarounds in the README to do the update process manually...