Summary
When I use sudo apt upgrade and mattermost is to be upgraded I usually get something like this:
Setting up mattermost (9.5.2-0) ...
dpkg: error processing package mattermost (--configure):
installed mattermost package post-installation script subprocess returned error exit status 1
and have to sudo apt upgrade second time, and then it just does the mattermost configuration second time and end successfully. Why did it fail first time? Everything seems to work fine, but how can I be sure – is there some way run mattermost health check?
For reference previously was installed mattermost 9.3.0-0 and system is Ubuntu 20.04 server.
Also just in case before apt upgrade did this time systemctl stop mattermost, which didn’t help either.
from /var/log/dpkg.log
2024-03-20 09:24:26 upgrade mattermost:amd64 9.3.0-0 9.5.2-0
2024-03-20 09:24:26 status half-configured mattermost:amd64 9.3.0-0
2024-03-20 09:24:26 status unpacked mattermost:amd64 9.3.0-0
2024-03-20 09:24:26 status half-installed mattermost:amd64 9.3.0-0
2024-03-20 09:24:45 status unpacked mattermost:amd64 9.5.2-0
…
2024-03-20 09:25:48 configure mattermost:amd64 9.5.2-0
2024-03-20 09:25:48 status unpacked mattermost:amd64 9.5.2-0
2024-03-20 09:25:48 status half-configured mattermost:amd64 9.5.2-0 => which ended with “error 1” after 43 seconds doing something.
2024-03-20 09:26:31 configure python3-update-manager:all 1:20.04.10.20
and then second attempt did it in 1 second successfully:
2024-03-20 09:36:38 configure mattermost:amd64 9.5.2-0
2024-03-20 09:36:38 status half-configured mattermost:amd64 9.5.2-0
2024-03-20 09:36:39 status installed mattermost:amd64 9.5.2-0
Steps to reproduce
just run sudo apt update and sudo apt upgrade…
Expected behavior
no errors and everything works on first try.
Observed behavior
had to run sudo apt upgrade again.
Everything seems to be “normal”. Time will tell if the next actual upgrade goes without any errors.
$ sudo apt install --reinstall mattermost
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/430 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 117145 files and directories currently installed.)
Preparing to unpack .../mattermost_9.5.2-0_amd64.deb ...
Unpacking mattermost (9.5.2-0) over (9.5.2-0) ...
Setting up mattermost (9.5.2-0) ...
However I still see one “leftover” link /usr/bin/platform:
$ cat /var/lib/dpkg/info/mattermost.list | grep "bin"
/opt/mattermost/bin
/opt/mattermost/bin/mattermost
/opt/mattermost/bin/mmctl
/usr/bin
/usr/bin/mattermost
/usr/bin/mmctl
/usr/bin/platform
$ ls -lah /usr/bin/platform
lrwxrwxrwx 1 root root 28 Mar 1 22:15 /usr/bin/platform -> /opt/mattermost/bin/platform
$ ls -lah /opt/mattermost/bin/
total 190M
drwxr-xr-x 2 mattermost mattermost 4.0K Mar 20 15:52 .
drwxr-xr-x 12 mattermost mattermost 4.0K Mar 20 15:52 ..
-rwxr-xr-x 1 mattermost mattermost 104M Mar 1 21:03 mattermost
-rwxr-xr-x 1 mattermost mattermost 86M Mar 1 21:03 mmctl
You could manually (re)add to /etc/systemd/system/mattermost.service I don’t think we control the systemd unit file. I know we do not presuppose what database or where it’s located.
