Communication problems between containers about seafile-containerized HOT 9 CLOSED

Does this issue occur for all libraries or just one?

If it's just one, try to repair it: https://manual.seafile.com/maintain/seafile_fsck/

Are you using the Python (default) or Golang fileserver? I experienced this kind of issue while I was testing the Golang fileserver some months ago.

from seafile-containerized.

It's the only library that exists on that server, I've set this server up last week for a relative, and it's having some issues. I run the official docker image on my personal server and I've never had any problems with it besides acme stuff, so I thought I'd just install that for them in the time being.

As for the db errors, it only happens on newer versions of mariadb, they don't show up in version 10.1. This could just be a silent error on previous versions though so idk if it solves anything.

I wasn't totally transparent on my previous comment, I've installed version 9.0.10 just to keep out of the beta 10.0.0, when this error happended I thought I could try upgrading to 10.0.1 to see if that would magically solve it, it didn't lol. From what I understand the golang fileserver is a new (10.0) feature right?

from seafile-containerized.

I can see on the screenshot that there are two libraries. Please check if the issue occurs with other libraries, too. If not then the library showing an error is probably corrupted and needs to be repaired, see my last comment.

The Golang file server was introduced in version 9.

As for MariaDB, are you sure that you are using version 10.1? It's six years old and deprecated for two and a half years. Please try to use version 10.6 or 10.7.

from seafile-containerized.

A note on mariadb versions.

According to Seafile, all recent versions should work: https://forum.seafile.com/t/what-are-officially-supported-versions-of-mariadb-mysql/13628/8

There is no version that is especially recommended.

I've successfully tested versions 10.6, 10.7, and 10.11.

So that you know, downgrading is not officially supported. It might just work but it also might cause unexpected issues. When upgrading, make sure to set the MARIADB_AUTO_UPGRADE=true environment variable. It will cause mariadb-upgrade to execute if necessary.

I've set the MariaDB version in the compose files to 10.11 and added the environment variable.

from seafile-containerized.

seafile-db-1              | 2023-04-18 14:51:56 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'root' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 4 [Warning] Aborted connection 4 to db: 'ccnet_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 5 [Warning] Aborted connection 5 to db: 'seafile_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 6 [Warning] Aborted connection 6 to db: 'seahub_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)

These connection interrupts are probably due to your seafile-server crashing after trying to access that library. So there is no general communication problem between your containers. My best guess is that the server experienced a sudden power loss of some sort and the library became corrupted.

Please try another library and/or try to repair the library with seafile fsck.

from seafile-containerized.

I wasn't aware that mariadb version was that old, given that it's only internal to seafile I didn't care to update it. Also the other library is the default one, it has only one file in it and it's fine. Besides that, did you ever see the logs lines? This is with version 10.7.8:

seafile-db-1              | 2023-04-18 14:51:56 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'root' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 4 [Warning] Aborted connection 4 to db: 'ccnet_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 5 [Warning] Aborted connection 5 to db: 'seafile_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)
seafile-db-1              | 2023-04-18 14:51:56 6 [Warning] Aborted connection 6 to db: 'seahub_db' user: 'seafile' host: '172.20.0.3' (Got an error reading communication packets)

I ran fsck and indeed there are some missing blocks. This is a week old server with an SSD for block storage running ZFS, zpool status reported no errors so far. The only thing I can see might have caused this is the new go fileserver.

Is the go fileserver enabled by default on 9.0.10? The server was running that version of the seafile server when the missing block error first appeared.

from seafile-containerized.

About the logs, I've just added a comment right before you posted yours.

The Golang fileserver is not enabled by default.

The only thing I can see might have caused this is the new go fileserver.

Or sudden power loss...

from seafile-containerized.

Or sudden power loss...

The server is connected to a UPS that signals a graceful shutdown every time there's a power loss. The only reason I could think something like that happened is if the server took too long to shut down.

These connection interrupts are probably due to your seafile-server crashing after trying to access that library. So there is no general communication problem between your containers. My best guess is that the server experienced a sudden power loss of some sort and the library became corrupted.

I've wiped out the server several times now, and this comes up every time on initialization, except on startups after the initial setup only the third line comes up. That's why I wanted to know if it was just me, it seems weird it would do that every time it starts, although I didn't give it much thought first as I thought it could be the containers all booting up and trying to connect to the db before things are ready.

So that you know, downgrading is not officially supported. It might just work but it also might cause unexpected issues. When upgrading, make sure to set the MARIADB_AUTO_UPGRADE=true environment variable. It will cause mariadb-upgrade to execute if necessary.

Thanks for the tip! I'll look into upgrading it.

from seafile-containerized.

I'll close this as I'm getting the same behaviour with the db logs on the official docker builds. The corruption issue seemed to have been caused by a service without a timeout taking too long to stop, causing an unexpected shutdown while the seafile server was still on. Thanks for all the help!

from seafile-containerized.