My Seafile client is stuck synchronizing a certain library at 30%, is there any way to see which file is being attempted to download?
Please check the logs. Have a look what the I/O of your systems does.
Which logs exactly? I already checked a bunch of logs and none seemed to show anything related to single file download.
Could you guide me to the logs I’m supposed to be looking at? I’m a bit lost.
Thank you, I did check those logs already but apparently not thoroughly. An error that appears several times around the time it happened is: libcurl failed to GET ***** Failed writing received data to disk/application
So from what I can tell it can’t GET a certain block
@daniel.pan
Tipps?
Please, help me.
Please post the related logs in seafile.log from the client.
[06/12/17 17:07:40] seaf-daemon.c(555): starting seafile client 6.0.6
[06/12/17 17:07:40] seaf-daemon.c(557): seafile source code version f6b66ebf772e22251eff8b1a5917fabc678f15a2
[06/12/17 17:07:40] …/common/mq-mgr.c(60): [mq client] mq cilent is started
[06/12/17 17:07:44] …/common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[06/12/17 17:09:12] clone-mgr.c(840): Transition clone state for 7654a0e1 from [init] to [check server].
[06/12/17 17:09:14] http-tx-mgr.c(1213): Bad response code for GET http://[REDACTED]:8000/seafhttp/protocol-version: 404.
[06/12/17 17:09:15] [06/12/17 17:09:15] clone-mgr.c(840): Transition clone state for 7654a0e1 from [check server] to [fetch].
http-tx-mgr.c(4262): Download with HTTP sync protocol version 1.
[06/12/17 17:09:15] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[06/12/17 17:09:16] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[06/12/17 17:09:17] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[06/12/17 17:10:16] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘fs’) --> (‘normal’, ‘data’)
[06/12/17 18:21:44] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘data’) --> (‘canceled’, ‘data’)
[06/12/17 18:21:44] clone-mgr.c(840): Transition clone state for 7654a0e1 from [fetch] to [canceling].
[06/12/17 18:21:44] http-tx-mgr.c(748): libcurl failed to GET http://[REDACTED]:8082/repo/7654a0e1-88f6-40bf-849c-233f9a8f3a5f/block/fdc57ad5d6461f29527d86c544e8fd270a27ef87: Failed writing received data to disk/application.
[06/12/17 18:21:44] http-tx-mgr.c(748): libcurl failed to GET http://[REDACTED]:8082/repo/7654a0e1-88f6-40bf-849c-233f9a8f3a5f/block/75e7abe116ea0058deddb331eeb53e76705ad5a5: Failed writing received data to disk/application.
[06/12/17 18:21:44] http-tx-mgr.c(748): libcurl failed to GET http://[REDACTED]:8082/repo/7654a0e1-88f6-40bf-849c-233f9a8f3a5f/block/f350ea495c6b33957b30354537bb128d3f8b4e94: Failed writing received data to disk/application.
[06/12/17 18:21:45] http-tx-mgr.c(748): libcurl failed to GET http://[REDACTED]:8082/repo/7654a0e1-88f6-40bf-849c-233f9a8f3a5f/block/a31aa73a2719a55e40ddbab3790960da2aefd893: Failed writing received data to disk/application.
[06/12/17 18:21:45] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘canceled’, ‘data’) --> (‘canceled’, ‘finished’)
[06/12/17 18:21:45] clone-mgr.c(840): Transition clone state for 7654a0e1 from [canceling] to [canceled].
[06/13/17 11:22:16] seaf-daemon.c(555): starting seafile client 6.0.6
[06/13/17 11:22:16] seaf-daemon.c(557): seafile source code version f6b66ebf772e22251eff8b1a5917fabc678f15a2
[06/13/17 11:22:16] …/common/mq-mgr.c(60): [mq client] mq cilent is started
[06/13/17 11:22:16] …/common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[06/13/17 11:22:16] seafile-session.c(422): Moving commits for deleted repo 7654a0e1-88f6-40bf-849c-233f9a8f3a5f.
[06/13/17 11:22:16] seafile-session.c(422): Moving fs for deleted repo 7654a0e1-88f6-40bf-849c-233f9a8f3a5f.
[06/13/17 11:22:16] seafile-session.c(422): Moving blocks for deleted repo 7654a0e1-88f6-40bf-849c-233f9a8f3a5f.
[06/13/17 11:22:16] repo-mgr.c(6584): Removing store D:/Seafile/seafile-data\deleted_store\commits\7654a0e1-88f6-40bf-849c-233f9a8f3a5f
[06/13/17 11:22:16] repo-mgr.c(6584): Removing store D:/Seafile/seafile-data\deleted_store\fs\7654a0e1-88f6-40bf-849c-233f9a8f3a5f
[06/13/17 11:22:30] repo-mgr.c(6584): Removing store D:/Seafile/seafile-data\deleted_store\blocks\7654a0e1-88f6-40bf-849c-233f9a8f3a5f
[06/14/17 11:40:09] seaf-daemon.c(555): starting seafile client 6.0.6
[06/14/17 11:40:09] seaf-daemon.c(557): seafile source code version f6b66ebf772e22251eff8b1a5917fabc678f15a2
[06/14/17 11:40:09] …/common/mq-mgr.c(60): [mq client] mq cilent is started
[06/14/17 11:40:09] …/common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[06/14/17 11:41:25] clone-mgr.c(840): Transition clone state for 7654a0e1 from [init] to [check server].
[06/14/17 11:41:25] http-tx-mgr.c(1213): Bad response code for GET http://[REDACTED]:8000/seafhttp/protocol-version: 404.
[06/14/17 11:41:25] [06/14/17 11:41:25] http-tx-mgr.c(4262): Download with HTTP sync protocol version 1.
clone-mgr.c(840): Transition clone state for 7654a0e1 from [check server] to [fetch].
[06/14/17 11:41:25] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘init’) --> (‘normal’, ‘check’)
[06/14/17 11:41:25] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘check’) --> (‘normal’, ‘commit’)
[06/14/17 11:41:25] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘commit’) --> (‘normal’, ‘fs’)
[06/14/17 11:41:49] http-tx-mgr.c(1109): Transfer repo ‘7654a0e1’: (‘normal’, ‘fs’) --> (‘normal’, ‘data’)
[06/12/17 17:09:15] is when I first started synchronizing the library, I then cancelled it before creating this thread
The most recent entry from today is when I restarted synchronization of said library on the same folder, it’s stuck at 31% but shows an active download rate of 700 kB/s
How large is your library? Is there a very big file there?
About 60 GBs and possibly. I will check and report back.
Biggest file is just under 2 GBs, it is located in the block that appears in the logs.
Is there some kind of limitation in place?
No. Files can have unlimited size, but requires to have some local space and computation power.
Do you have multiple partitions / disks and is there enough free space on the one the Seafile folder is located on (the one being specified on first run)?
There is plenty of space left (>500 GB) on the disk the Seafile folder is located on. This synchronization issue is present for this library in general, meaning other clients on different computers also get stuck at the same percentage. What throws me off is that the clients still show a download rate as if something was happening but the percentage never changes.
Do you use your own server? If so, could you run seaf-fsck on the library? Instructions can be found at https://manual.seafile.com.
Another thing you could do is checking your proxies access logs (as long as you use one and have logging enabled). Interesting would be requests to /seafhttp/* with a non 200 http code.
I do use my own server. I ran seaf-fsck with default arguments on all libraries, no reports indicating any corruptions.
Sadly I do not have logging enabled.
Could you possibly guide me on how to enable said logging feature? I still haven’t found a solution.
Do you use any proxy in front of Seafile (e.g. nginx or apache)?