OnlyOffice is unresponsive after update to 1.18
-
The "Already exists" status is referring to layers of the app package image. That is expected and good.
"=> Healtheck error got response status 502" is showing some issue, although very limited insight.
Have you restarted the app? Does it maybe run out of memory? Instances here work fine, so shouldn't be a generic issue.
-
-
I had the same yesterday, didn’t have time to debug so restored backup.
-
@nebulon Yep, I did the usual: restarted, increased memory, and even restarted the redis. A reboot was due so I did that too for good measure.
This is the limit of what I know to do
I kicked the tires around a bit and peeked under the logs. Couldn't find anything. This is supposed to be a simple application, with no plugins or such to complicate stuff.
Maybe I will have to restore the backup and wait for a newer version to test.
-
@imc67 said in OnlyOffice is unresponsive after update to 1.18:
I had the same yesterday, didn’t have time to debug so restored backup.
Me too. But restoring previous backups didn't work. I had to go back to 1.17.2 which still didn't work until I restarted post restore. Now have 1.17.2 running again.
Here are some logs:
https://paste.uniteddiversity.coop/?9e0d71d64bec7812#5oM2ZdBDZLSqMm9oBGLpjUxYQWjzdeeuWTzZXW5KW3XF -
@nebulon said in OnlyOffice is unresponsive after update to 1.18:
Instances here work fine, so shouldn't be a generic issue.
At least 3 of us are here who are having this issue so I'd guess it's actually pretty widespread.
-
@jdaviescoates said in OnlyOffice is unresponsive after update to 1.18:
@nebulon said in OnlyOffice is unresponsive after update to 1.18:
Instances here work fine, so shouldn't be a generic issue.
At least 3 of us are here who are having this issue so I'd guess it's actually pretty widespread.
Although I just checked and fresh install works fine. So it's seemingly just updates from 1.17 - 1.18 that aren't working.
-
Depending how old your onlyoffice is:
PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql
PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev710.sql
In case the db schema upgrade is already up2date, the output looks like:
root@78d36e9e-8352-4cd1-a356-42fa5e22702f:/app/code# PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -f /var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE: column created_at already exists. psql:/var/www/onlyoffice/documentserver/server/schema/postgresql/upgrade/upgradev630.sql:15: NOTICE: column password already exists. DO
Based on the git history, cloudron only did the schema migration for 720.sql.
The Dockerfile should fail on docker build in case there new sql files and apply the sql files. atm rerunning the sql files does not exit with exit code > 0. But I believe it is better to store somewhere which sql-files was already applied, just for case sql file would break something on a rerun.
-
Re-install and config key solved it. Thanks!
-
-
@tobiasb This Greek and Latin is exactly why I am such a fan of Cloudron - users range from utterly computer challenged to gods of code and linux.
Thank you for solving the mystery for all of us.
We must reinstall with the same config key / secret then!
-
@jdaviescoates said in OnlyOffice is unresponsive after update to 1.18:
@imc67 said in OnlyOffice is unresponsive after update to 1.18:
config key
config key?
Secret (key) in the Config folder
-