Config.json resets itself to original if binary is run with root user starting from 5.30
We have seen several customers report that on upgrading to >5.30, using any mattermost commands via the binary with a root user resets the config.json to its default state.
I tried to reproduce it locally but was unable to.
But given that multiple customers and community users are experiencing it, it seems like this is worth investigating. Atleast, we should be able to understand why this is happening in the first place.
https://community-daily.mattermost.com/private-core/channels/sales-deployment - search "#zendesk15926", "#zendesk15664"
QA Test Steps
Have mattermost (v5.30 upwards) running on a brand new installation.
On a separate terminal go to the mattermost/bin folder and issue the following command:
`while ./mattermost version; do :; done`
Let the command run for a bit, a minute or so.
Verify that the mattermost config.json doesn't get reset to defaults.
It’s not related to the root user. The bug can happen any time you run a command with the CLI with any user.
I have a customer running this as sudo -u mattermost ./bin/mattermost and it’s experiencing the same problem. They’re upgrading to 5.32 this weekend. Just mentioning it because it seems like new behavior since it’s not the root user
Successfully tested and verified using release-5.32
Hence closing the ticket
Happy to help more just ping me on MM.
The behavior there is super not ideal. If I remember correctly, that behavior is not new, but I think I caused it to happen more frequently. It exists because of stuff like setting defaults and the fixConfig function: https://github.com/mattermost/mattermost-server/blob/d9a890e73fd90d09deed43fb7887ae529b16cc48/config/store.go#L220
I would much rather not have that stuff needing to happen. Maybe not writing back changes that the server makes? But then the config.json wouldn’t be the source of truth which wouldn’t be ideal. You could solve the underlying issue but that’s harder. You also might be able to get away with reducing the frequency that it needs to happen to hide the issue, or just prevent it from happening on CLI invocations.