Get message "Repo size compute queue size is 0" in seafile.log after update from 6.2.2 to 6.2.3 (every 5 minutes)

server

#21

@porph First of all: Thank you very much for your help and this great “Tutorial”.

I made all steps and all of my checksums are eqal with yours.
But after i replaced the original “seaf-server” with your patched version, i cannot use seafile/seahub without problems.

After the replace and a reboot: I can login into seahub but not libraries or files are shown.
There is only a Error Message (see picture).

Now i will search for error messages in my logfiles to find the reason.
(After re-replace the patched file with my original file it works again)

:warning:
I found this error message:

  • [ERROR] django.request:135 handle_uncaught_exception Internal Server Error: /api2/repos/
    • SearpcError: Error received: 511 Unknown service (In _start_service)

There is the relevant part of my seahub.log:
seahub.log


#22

@TT-SWP13: This wasn’t the tutorial yet :slight_smile: I was gonna write something in more detail, howto find the right bytes.

About your error, I am going to repeat the procedure and verify the patched version.
If that doesn’t explain the problem, then I can only guess that seafile added some self integrity checks, that protect from corrupted files.
I get back to you.


#23

@TT-SWP13 I just installed the 6.3.2 and tested the patch and cannot confirm the problem.
Here it is working fine with an empty test install (only created one library).
Can you maybe clear /tmp/seahub_cache , before using the patched version?

I don’t want to mess up your system, so create a backup just in case.
Although patching these 3 bytes seems harmless to me…
Did you check with “cmp -l seaf-server seaf-server.patched” that only 3 bytes differ?


#24

@TT-SWP13 The only thing that can go wrong that I can think of, is that the compiler reuses the constant for the logging interval and that my patch changes another constant aswell.


#25

It is still the same behaviour.

My steps:

  • stop server
  • replace seaf-server with patch
  • check with cmp that only these 3 bytes changes
  • delete cache
  • reboot
  • login in seahub

I get this Error-Message in seahub.log:

2018-08-14 10:04:25,997 [ERROR] django.request:135 handle_uncaught_exception Internal Server Error: /api2/repos/
Traceback (most recent call last):
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/core/handlers/exception.py”, line 41, in inner
response = get_response(request)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/core/handlers/base.py”, line 249, in _legacy_get_response
response = self._get_response(request)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/core/handlers/base.py”, line 187, in _get_response
response = self.process_exception_by_middleware(e, request)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/core/handlers/base.py”, line 185, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/views/decorators/csrf.py”, line 58, in wrapped_view
return view_func(*args, **kwargs)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/Django-1.11.13-py2.7.egg/django/views/generic/base.py”, line 68, in view
return self.dispatch(request, *args, **kwargs)
File “/srv/seafile/seafile-server-6.3.2/seahub/seahub/api2/base.py”, line 23, in dispatch
response = super(APIView, self).dispatch(*a, **kw)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/djangorestframework-3.8.2-py2.7.egg/rest_framework/views.py”, line 483, in dispatch
response = self.handle_exception(exc)
File “/srv/seafile/seafile-server-6.3.2/seahub/seahub/api2/base.py”, line 20, in handle_exception
return super(APIView, self).handle_exception(exc)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/djangorestframework-3.8.2-py2.7.egg/rest_framework/views.py”, line 443, in handle_exception
self.raise_uncaught_exception(exc)
File “/srv/seafile/seafile-server-6.3.2/seahub/thirdpart/djangorestframework-3.8.2-py2.7.egg/rest_framework/views.py”, line 480, in dispatch
response = handler(request, *args, **kwargs)
File “/srv/seafile/seafile-server-6.3.2/seahub/seahub/api2/views.py”, line 623, in get
ret_corrupted=True)
File “/srv/seafile/seafile-server-6.3.2/seafile/lib/python2.7/site-packages/seaserv/api.py”, line 119, in get_owned_repo_list
start, limit)
File “/srv/seafile/seafile-server-6.3.2/seafile/lib/python2.7/site-packages/pysearpc/client.py”, line 110, in newfunc
ret_str = self.call_remote_func_sync(fcall_str)
File “/srv/seafile/seafile-server-6.3.2/seafile/lib/python2.7/site-packages/ccnet/rpc.py”, line 75, in call_remote_func_sync
req_id = self._start_service(client)
File “/srv/seafile/seafile-server-6.3.2/seafile/lib/python2.7/site-packages/ccnet/rpc.py”, line 36, in _start_service
raise SearpcError(“Error received: %s %s (In _start_service)” % (rsp.code, rsp.code_msg))
SearpcError: Error received: 511 Unknown service (In _start_service)

On seahub interface i get “Error” and after view seconds “Page unavailable”.

Thank you very much for your help!
I think I have to live with this.


#26

@TT-SWP13 Sorry, I have no other idea.
I also debugged the 6.3.2 version again to see, whether another function is accessing the constant or not and I couldn’t find any accesses.

So I guess nobody should use my patch until the reason is clear.


[docker] How to move storage from SSD /opt/... to /srv/ on a HDD
#27

Hi, is there any news on this? Currently my seafile.log is a multi-megabyte file containing almost only this annoying message:

root@seafile:/home/seafile/haiwen/logs# ls -lh seafile.log
-rw-rw-r-- 1 seafile seafile 3.3M Jun  3 20:28 seafile.log
root@seafile:/home/seafile/haiwen/logs# cat seafile.log | wc -l
43892
root@seafile:/home/seafile/haiwen/logs# grep -v "Repo size" seafile.log | wc -l
87

That’s just crazy (only 87 lines out of 44000 that don’t match “Repo size”). Don’t get me wrong: I’m all for extensive and detailed logging, but not a single message over and over again.


#28

The message has been removed in 7.0