Libcurl failed to PUT - Error in the HTTP2 framing layer

Seafile Client
#1

Hi guys, thank you for this great software.
I have a problem: new installation with docker of Seafile CE (I’ve tried with Pro version and same error), seaf-cli stop working after some minutes with this error:

http-tx-mgr.c(931): libcurl failed to PUT (link) Error in the HTTP2 framing layer.

I restart the client and after some minutes same error.

What I’ve wrong?

I follow the installation guide present on official website.

I am trying to upload my files (about 30gb of files, nothing big)

Thank you!

#2

Hi !

Same issue, not after a few minutes, but after longer times. The client works and synchronizes well for hours, then sometimes I end up with the same error as the last entry in my log. The log shows that the repo had gone from synchronized to committing, and from committing to uploading.

When I suspect this has happened, I run seaf-cli status , and this fails with a connection refused trace because, as I understand, the socket used for communication between the daemon and seaf-cli is no longer listened to.

If I restart the seafile client daemon, I get more hours of success, until the following time. This is quite annoying, as synchronization silently stops.

I’m using seafile-cli 6.2.11-1 on a Raspberry Pi 4 (Arm7 , 32-bit) with a 8.0.7 server running on the same Pi 4.

Cheers,
Pierric.

#3

To clarify, the issue for me is that the seafile client crashes regularly after an error such as the one mentioned by @Pang1982 . Looking closer at the log, it doesn’t ALWAYS crash when such an error is returned. For some URLs, that error is logged but there are further logs after that, and I don’t notice any break in functionality. But it seems that there is a crash specifically when the error is returned for URLs in this format (edited with random x’s as I’m not sure if this is sensitive or not):

[02/10/22 06:39:06] http-tx-mgr.c(954): libcurl failed to PUT https://mydomain/seafhttp/repo/xxxxxxx-2d89-xxxx-b496-xxxxxxxxx/commit/HEAD/?head=fdeafa1b80xxxxxxxxxxd8c086d0: Error in the HTTP2 framing layer.
[02/10/22 18:07:35] seaf-daemon.c(502): starting seafile client 6.2.11

As you can see, the next line in the log is when I detect the issue and manually restart seaf-cli, many hours later.

Here is an example when the error is returned but the client recovers:

[02/10/22 04:38:13] http-tx-mgr.c(1181): Transfer repo 'xxxxxx': ('normal', 'init') --> ('normal', 'check')
[02/10/22 04:38:13] http-tx-mgr.c(808): libcurl failed to GET https://mydomain/seafhttp/repo/xxxxx-2d89-xxxx-b496-xxxxxxxx/permission-check/?op
=upload&client_id=xxxxxxxxxxxxxxxxxxxx&client_name=unknown: Error in the HTTP2 framing layer.
[02/10/22 04:38:13] http-tx-mgr.c(3708): Upload permission denied for repo xxxxxxx on server https://mydomain.
[02/10/22 04:38:13] http-tx-mgr.c(1181): Transfer repo 'xxxxxxxx': ('normal', 'check') --> ('error', 'finished')
[02/10/22 04:38:13] sync-mgr.c(621): Repo 'pisync' sync state transition from uploading to 'error': 'Error occurred in upload.'.

In that case, after that error, a new attempt is made around 30 seconds later and there is no error, and the repo ends up synchronized again.

#4

Hi,

This hasn’t been getting much attention, but in the interest of potential future people experiencing similar issues, I think I’ve solved it on my side by adding http2 next to ssl in my nginx configuration for the seafile reverse proxy. May seem obvious from the error, but to be fair, the exact same configuration (without http2) was working fine previously for me. The change may be related to my moving from non-Dockerized to Dockerized install (on arm7). I haven’t had a crash of the client in quite a few days now.

To be clear, the beginning of the https section of the config file looks like this now:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

EDIT:

Well, it was working for many days… but finally, the day before yesterday, the client crashed again with the same error, in spite of the http2 change mentioned above still being in place. So this is still an active problem. Can anyone acknowledge this issue?

Cheers,
Pierric.

#5

I have triggered a workaround at this moment: a script scheduled in cron that check every minute if seaf-daemon process is running, and restart it if it’s not running:

#!/bin/sh
SERVICE=‘seaf-daemon’

if ps ax | grep -v grep | grep $SERVICE > /dev/null
then
echo “$SERVICE service running, everything is fine”
else
echo “$SERVICE is not running”
echo “$SERVICE is not running, trying to restart it” | mail -s “$SERVICE down” root
/usr/bin/seaf-cli start
fi

It’s not a fix, but in my case it’s an acceptable workaround