Currently no.
I also want to vote to have this behavior
-
being removed again (preferred) or at least
-
can be silenced by configuration
Why? I run Seafile intentionally as low budget on a RasPi and have all Seafile data on a USB disk. Since the introduction of this feature the disk cannot spin down any more.
I’d appreciate if that could be considered, please. @daniel.pan
1 Like
Thank for the suggestion. We will add an option for this.
4 Likes
@daniel.pan
Any progress on this feature request. Where can I track it?
Version 6.3.0 did not address it.
Maybe it is worth to think about not logging queue sizes of “0”, if this is the happy path. (I am unaware of the meaning of the value, so this might not be viable).
This could solve the issue without introducing another feature/config option.
Otherwise one could introduce a logging interval for the queue size as config property and if it is “0” or some other magic value, then no logging is done.
Right now it is hard coded.
For reference, here is the commit that introduced the logging:
The commit message does not contain a hint for what reasons the logging at 5 min rate was introduced.
I would also appreciate a fix so the logfile isn’t filled with just this message. Running 6.3.1 CE
Until this issue is fixed I am using a workaround by patching the binary file “seaf-server”. I did this successfully for seafile 6.2.5 on raspberry pi. I was able to increase the logging interval from 5 minutes to 24 hours.
Ask me if you need help, in short:
- find position of logging string const with objdump
- attach to running seaf-server with gdb and put a read watch on that address
- at the breakpoint examine the backtrace and find the memory address of the instruction in the outmost stack frame
- use objdump to examine the instructions around that memory address, find the " cmp" assembly instruction that does the interval check and find the position of the logging interval constant
- use readelf to get the position offset in file
- change the bytes with hex editor
Hey,
good to hear you found a way.
I do not know anything about the tools.
I would be very grateful if you can publish a small guide to it. Pecially the tool commands / searching parameters.
Now i am on version 6.3.2 CE and thy “issue” still exists.
@TT-SWP13: Are you running seafile on “Generic Linux” or Raspberry Pi? I can write a tutorial with your specific version as an example.
Maybe I find a way to supply the change as a binary patch with checksums which can be applied in a user-friendly way.
@TT-SWP13 Ok, I will try to patch your version on my Raspberry Pi 2. I have read that Rpi2 is 32bit and Rpi3 is 64bit, but I guess you use the official 32bit binaries. Just in case can you give me the md5 checksum of your “seaf-server” executable, so I don’t work on the wrong version.
I get:
pi@raspberrypi:~ $ md5sum seafile-server-6.3.2/seafile/bin/seaf-server
10d60720e1bd2a9b302865688c735faf seafile-server-6.3.2/seafile/bin/seaf-server
@TT-SWP13 Ok, I patched the official 32bit binary of seafile server 6.3.2 CE for raspberry pi.
You can find the original “seaf-server” and the “seaf-server.patched” here https://github.com/timmi-on-rails/seaf-server-patch
Before you use it, make sure that your md5 is the same as mine or better check that your “seaf-server” and the one in the repo matches.
After that you can be super safe by checking the difference between your “seaf-server” and the patched version with:
cmp -l seaf-server seaf-server.patched | gawk ‘{printf “%08X %02X %02X\n”, $1-1, strtonum(0$2), strtonum(0$3)}’
Should print:
00024368 2B 7F
00024369 01 51
0002436A 00 01
If you don’t have gawk installed, then use “cmp -l seaf-server seaf-server.patched”, should print:
148329 53 177
148330 1 121
148331 0 1
Three lines means 3 different bytes.
Changing “2B 01 00” to “7F 51 01”
To understand the values you have to read the bytes in reverse.
“2B 01 00” -> “00 01 2B” -> to dec -> 299 seconds -> +1 second (assembly reason) -> 300 seconds -> 5 minutes
“7F 51 01” -> “01 51 7F” -> to dec -> 86399 seconds -> +1 second (assembly reason) -> 86400 s -> 24 hours
Hope it works.
Please tell me your result!
1 Like
Hi Seafile Devs, any news about this from your side?
97% of the lines in my log file are “. size-sched.c(96): Repo size compute queue size is 0” …
@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)
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
@TT-SWP13: This wasn’t the tutorial yet 
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.
@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?
@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.
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.
@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.
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.
The message has been removed in 7.0
3 Likes