OS: Wndows Server 2016
MYSQL 8.0.31
Mattermost enterprise Edition with a professional LIC
When upgrading from 7.2.1 to 7.5.1 the server will not start up. get the following error
C:\mattermost\bin>mattermost.exe
{“timestamp”:“2022-12-15 15:19:41.369 -06:00”,“level”:“info”,“msg”:“Server is initializing…”,“caller”:“platform/service.go:157”,“go_version”:“go1.18.1”}
{“timestamp”:“2022-12-15 15:19:41.370 -06:00”,“level”:“info”,“msg”:“Pinging SQL”,“caller”:“sqlstore/store.go:230”,“database”:“master”}
{“timestamp”:“2022-12-15 15:19:41.405 -06:00”,“level”:“fatal”,“msg”:“Failed to apply database migrations.”,“caller”:“sqlstore/store.go:166”,“error”:“open migrations\mysql: file does not exist”}
Not sure what is is checking to see if it has to run migrations, but I have noticed even with the current 7.2.1 it thinks it needs to run migrations but the schema is already at 90.
Here is the DB tSchema
unfortunately I have to say that Mattermost is not supported to be run on a Windows server and the bug you’re posting here is biting everyone using this unsupported configuration with a recent version. There’s probably nothing Mattermost is going to do about that and it seems as if also running the upgrades manually does not fix it (as you can see).
Are you able to migrate to a supported (Linux) platform?
So it did seem to take care of the db migrattions issue but there still seems to be an issue parsing out the log file path from the config file. the only value that seems to work is a “.”, if I do a path like “.\logs” it will blow chunks saying l is not valid
Greetings. So I took a look at how the server processes log paths. If FileLocation is not specified the server tries to find a logs folder in one of the parent directories of the working directory and then join it with mattermost.log.
I found an issue with how we configure the logger. Since \ needs to be escaped (but isn’t in that case), the logger config becomes invalid. The only working option would be to provide a simple filename (like mattermost.log), which will create the log file in the current working directory. Double-escaping doesn’t help in this case because the paths are “cleaned” from duplicate path separators.
Alright, thanks - I guess that’s a good compromise anyways, since the db migrations are now running the only issue left is the logfile location which cannot be specified; is that something you can live with, @tbielejeski ?
Mattermost on Windows is not officially supported and according to @plusmid it’s not an easy fix to get it working here, so I think it will stay like this for the time being.
)