ONLYOFFICE 7.0: online forms, password protection in sheets, collaboration improvements and much more
ONLYOFFICE 7.0 released

Cache files aren't cleared

Workspace
#1

Running onlyoffice/documentserver (version 6.3.1.32) in docker. Installation as described in Installing ONLYOFFICE Docs for Docker on a local server - ONLYOFFICE

As written there: running container with option

-v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice

So all cache files are stored outside container.

It looks like these cached files are not cleared/deleted (completely). There are a lot of files older than 1 day.

In default.json I use default settings under “expire”: for files: 86400 sec (=1 day)
See https://github.com/ONLYOFFICE/server/blob/bc6ea0318908373b750c4e7a328ebd41f92c5446/Common/config/default.json#L113

Meanwhile the old cache files are some GB.

How can I ensure or check that the “clearing job” is running regularly?
How can I check that there are no errors on clearing cache? I could not find any associated log file.

As I read it is note safe to remove these files in file system directly/manually.

edit: how is it possible to remove the old files safely?

Thanks for any hint.

#2

Hello @steka
V.6.3.1 is really old version. Is it possible to make an update to v.7.0 and check if the issue still persists? Of course, we strongly recommend to prepare whole server backup before update process.

#3

I will update in the next few days and report.

1 Like
#4

Basically the deletion of new cached files works with both versions (6.3.1 and 7.0.0). As it turns out, the problem belongs to “old” cached files.

Probably these old files were generated and still waiting for their deletion. On the day they were created might have been an update to nextcloud and/or onlyoffice. And the newer Version does not know about the old files?

I clarify my question:
Is it safe to delete the old cached files directly? Or do I have to clear some database entries to?

#5

Is it safe to delete the old cached files directly? Or do I have to clear some database entries to?

We do not recommend manual actions with cache or database.

I think the issue is not related to ‘how manually clean the cache’, but ‘why it wouldn’t clean’.

How it works:

  1. The document is downloaded from storage and assigned a key according to the editor initialization config: ONLYOFFICE Api Documentation - Config
  2. The Document Server converts the original document into a binary file called Editor.bin and places it into a folder in its cache. The folder is always named using the document’s key.
  3. When a user edits the document, the changes they make are sent to the database. If they are sent successfully, the user will see the “All changes saved” message at the bottom of the editor interface.
  4. After the user closes the editor window or presses the save button (if force saving is enabled), terminating the editing session, the saving process is initiated: ONLYOFFICE Api Documentation - Saving File.
  5. The Document Server then builds the final document by combining the original Editor.bin file and the changes in the database.
  6. The storage service then downloads the output file from the Document Server cache and saves it.
  7. If the previous step is successful, the corresponding folder in the cache is deleted in 24 hours (this is by default).

I assume we have an issue on step 7 in this case and for some reason cache isn’t clean.

Could you please check if any files persist in ‘forgotten’ folder?

#6

Thanks for step by step description of that workflow.

In folder “forgotten” are some files. From 4 to 14 month old. All of the keys (foldernames) are found in cache/files directory too. But there are a lot more old keys in cache/files directory. About 20% of all cache/files keys are found in forgotten.

If i check the change date of the old cache files: Mostly these are only 5 dates in last 14 month. On each of these 5 dates I changed nextcloud version and/or onlyoffice docker container to another version.

This make me think, that a onlyoffice version can only clean up “its own” cache files. Is it possible that something concerning key-assignment changes on updaets? So that a key for a file differs between oo-versions (I’m just guessing)?

Step 7: Who/What decides that step 6 was successfull? or: Which database or file value needs to be set for a folder to be deleted?

#7

Mostly these are only 5 dates in last 14 month. On each of these 5 dates I changed nextcloud version and/or onlyoffice docker container to another version.

Oh, now I got it. Did you use prepare4shutdown script before starting update process of DS or Nextcloud?
https://helpcenter.onlyoffice.com/installation/docs-community-update-linux.aspx
If not, this explains the situation with files in the cache that match the update dates.
Probably the issue scenario looked like this: some users were still working with files when update process was started. In this case the file was not built and remained in the cache.

Step 7: Who/What decides that step 6 was successfull? or: Which database or file value needs to be set for a folder to be deleted?

First of all, please do not change anything in database manually. The consequences can be unpredictable.
Please check it out: ONLYOFFICE Api Documentation - Callback handler
If the storage responds to the ‘status 2’ message from DS with error:0, then the save is successful.

#8

Thanks for the hint “prepare4shutdown”. I never used this before. I always stop old oo-Container and start new oo-container. And on Nextcloud-Updates I didn’t touch oo-container.

I’ll test some things in the next weeks, to check if there might be additional reasons/situations.

Background:
It seems unlikely to me that 135 files are opened over day (7 am to 8 pm) and still open at the evening (9 pm), when I updated OnlyOffice. On the other day it have been 92 files.

#9

Unfortunately, I have nothing to add at the moment. Probably, if you notice that issue is reproduced again, then it’s better to take a look at Document server logs. As far as I understand the situation, the files in the cache match the update dates. The described scenario is possible if you didn’t use prepare4shutdown script.
Nevertheless, please notify us if you face something similar again.