I’m getting in seafile.log every 5 minuts this message. Maybe devs just forget remove some debug dumps cause I think it’s not error but, it filling log file and it harder to find error messages.
[11/16/17 07:37:13] size-sched.c(96): Repo size compute queue size is 0
I didn’t found the source / cause of this message. So i decide to move this file to SD-Card and create a symlink to this (bad for health of card) . Now my HDD will fall to sleep.
I call it a bug, it’s just something that the dev’s did put in the logs after 6.2.3 update.
This is not good for the I/O and I and some others hopes that the dev’s take this away in the next release.
It’s no bug. It’s a log message from a worker or something similar. The size of the libraries is being computed in the background and the job always leaves a log message when it runs.
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
@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.
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
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:
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: