Seafile server 6.2.3 is ready! OAuth support and other improvements

That’s what I said.

I think it’s not best practice generate every 5 minutes into file message which saying “everything is ok”. “Everything is OK” is default state and everyone expecting that, so they don’t have to be informed.

1 Like

I know :wink:

What numbers are good and which aren’t ? :wink: That depends on the system and if you have issues it’s good to see it. Of course there maybe should be an option to disable it.

I have isolated it a bit more for you, it seem that the “new” way of writing cache config in don’t work with 6.2 Pro or 6.2.3 CE, you need to write it in the old way.
Se in the bottom of this thread:

That’s not any good I guess as the new way to write is the right way to call memcached if I’m understand it correctly.

Old way that works in 6.2 Pro and 6.2.3:

> CACHES = {
> 'default': {
> 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
> # 'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
> 'LOCATION': 'unix:/var/run/memcached.sock',
> }
> }


using this configuration, I no longer have an error in the seahub.log file

‘default’: {
‘BACKEND’: ‘django.core.cache.backends.memcached.MemcachedCache’,
‘LOCATION’: ‘unix:/var/run/memcached.sock’,

1 Like

Do you have any errors in seahub_django_request.log that are related to memcache?

no, there are no errors in seahub_django_request.log and seahub.log
seafile has been in service for more than 12 hours

@daniel.pan any news on this?

I’ll clean everything up so it’s easier to understand.

Memcached with socket and HTTP are working in 6.2.2 without any issues.
When you update to 6.2.3 it start to log issues in seahub.log (Se log above)
This also happens in 6.2 Pro.

It seem that it only log errors when you write the Memcached settings in in the “new way” but if you write it in the “old way” everything seem to work.

To reproduce:
Have the new settings of memcached in
Upgrade from 6.2.2 to 6.2.3.
Open your browser trough either NGINX or Apache2 and open a folder in the browser with thumbnails or something that triggers memecached.
Then you will have a error in seahub.log.

1 Like

After a few more test, we can reproduce this error.

But we found that this error msg ONLY showed in the first few HTTP requests after your rebooting Seahub, after you have used Seahub GUI for a little time, this error This error no longer appears any more.

Is that the case for you?

I don’t know if it disaper over time or not, I did only notice it directly and it did pop-up during my tests.
I can however run the server again for a test-run if you want me to do that over the weekend.

But I do remember that after every reboot or restart the error did happen again.

I think we found what caused this problem.

Can you add this config to seafile-server-latest/runtime/seahub.conf

threads = 5

and test it again ?

In 6.2.2, there is such config there in seafile-server-latest/runtime/seahub.conf, but we removed it from 6.2.3.


Does it metter where in the file I add the line?

No, I think not.

It did work! I have tried it brefly and I did try to reproduce the issue but I can’t I’ll let 6.2.3 run a while now I’ll report back later.

1 Like

Happy to hear that.:grin:


Greate :slight_smile: Then I guess the issue are the same at 6.2 Pro also.
@Cisco take a look in this thread you have the fix here for the Memcached issue :slight_smile: Just five posts up.


Using the following configuration in the file:

‘default’: {
‘BACKEND’: ‘django_pylibmc.memcached.PyLibMCCache’,
‘LOCATION’: ‘/var/run/memcached.sock’,

and adding the following line in the file seafile-server-latest/runtime/seahub.conf

threads = 5

all errors disappeared , thanks to @lian , @Calby , @gauburtin

Seafile Pro 6.2.0
Debian Stretch

Why did this line cause this issue? What’s that line for? And why did you delete that line?
I’m just curious =P


Pro version ? It looks like the Pro download area is still 6.1.9. Is 6.2x still considered early beta for Pro usage ?

1 Like

server-session.c(271): Unknown database type: pgsql

6.2.2 was ok with PostgreSQL