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

#1

I’m getting the message “Repo size compute queue size is 0” in seafile.log (every 5 minutes) it’s prevent my HDD to sleep, after update Seafile to 6.2.3 on my Raspberri Pi [https://github.com/haiwen/seafile-rpi/].

How to disable this message?

I’m allready read this post:

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.


#2

I had same issue, every 5mins will got this warning.
Follow Seafile server 6.2.3 is ready! OAuth support and other improvements to modify, nothing work.

need help, thanks


#3

@Feitian It’s not a warning.


#4

Even it is not warning, why it write into log every 5 mins?


#5

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.

@daniel.pan @lian @lins05


Strange behaviour with encrypted libraries
#6

Same behavior on version 6.2.5 :frowning:


#7

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.


#8

Can i disable it or increase the check time (5min)?


#9

Currently no.


Nginx - bad gateway after a while
#10

I also want to vote to have this behavior

  1. being removed again (preferred) or at least

  2. 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


#11

Thank for the suggestion. We will add an option for this.


#12

@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.


#13

I would also appreciate a fix so the logfile isn’t filled with just this message. Running 6.3.1 CE


#14

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

#15

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.


#16

@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.


#17

@porph: I am running seafile 6.3.2 CE on a Raspberry Pi 3 (latest Raspbian Stretch).


#18

@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


#19

@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!


#20

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” …