'Transport Error' in Seafile Client after upgrading openssl

Hi,

I am running Seafile Server on a Raspberry Pi (OS: Arch Linux ARM) and Seafile Client on two Android devices (OS: Android 4.x) and a laptop (OS: Arch Linux x86_64).
The other day openssl got upgraded in the repositories of the aforementioned distributions. The distribution packages for Seafile also got received updates for the same reason.

After rebuilding Seafile and upgrading both systems, the client (on the laptop) throws a ‘Transport Error’ when trying to sync any library, and also shows yellow cloud icons for all the libraries.
The web interface can be accessed without hiccups. Connecting and synchronizing works from both Android devices using the Android version of the Seafile Client.

On the server Seafile Server was built against openssl 1.0.2.k and on the laptop Seafile Client was built against openssl 1.0.2.k also (I think).

What does the ‘Transport Error’ mean? Is it a problem with openssl?

~/ccnet/logs/applet.log excerpt (from the laptop):

[2017-04-27 23:05:50][Sea RPC] Bad response: 102 processor is dead.
[2017-04-27 23:05:51][Sea RPC] Bad response: 102 processor is dead.
[2017-04-27 23:05:51]failed to get repo list: Transport Error

[2017-04-27 23:05:51][Sea RPC] Bad response: 102 processor is dead.
[2017-04-27 23:05:52][Sea RPC] Bad response: 102 processor is dead.
[2017-04-27 23:05:52]failed to get repo list: Transport Error

[2017-04-27 23:05:52][Sea RPC] Bad response: 102 processor is dead.

Am having the same issue on Arch. Exactly the same error messages.

Did you solve it yet?

Can you start the client on your arm devices? I get the following errors:

seaf-cli start
Traceback (most recent call last):
File "/usr/bin/seaf-cli", line 82, in <module>
import urllib2
File "/usr/lib/python2.7/urllib2.py", line 94, in <module>
import httplib
File "/usr/lib/python2.7/httplib.py", line 80, in <module>
import mimetools
File "/usr/lib/python2.7/mimetools.py", line 6, in <module>
import tempfile
File "/usr/lib/python2.7/tempfile.py", line 35, in <module>
from random import Random as _Random
File "/usr/lib/python2.7/random.py", line 885, in <module>
_inst = Random()
File "/usr/lib/python2.7/random.py", line 97, in __init__
self.seed(x)
File "/usr/lib/python2.7/random.py", line 113, in seed
a = long(_hexlify(_urandom(2500)), 16)
OSError: [Errno 38] Function not implemented

I didn’t upgrade the client and server, I just did a system update (pacman -Syu) after which everything couldn’t be synced anymore. Trying to sync again leads to ‘Transport error’ with error messages as above.

The daemon starts without issues:
$ seaf-cli start
Starting ccnet daemon …
Started: ccnet daemon …
Starting seafile daemon …
Started: seafile daemon …

I downgraded openssl but that’s not resolving the issue. It must be something else.

It’s probably related to seaf-daemon not starting. See comments in the AUR: https://aur.archlinux.org/packages/seafile-client/?comments=all They are having the same ‘Transport error’.

This is probably related as well: Seaf-daemon does not start automatically

1 Like

Unfortunately, nope, I haven’t been able to find the cause of the trouble. However, upon further investigation, I suspect the problem might rather be with the server. I noticed yesterday that a client on latop running OSX (which hasn’t been updated for quite a while) was showing the exatcly same behaviour (yellow cloud icons; refuses to sync). This suggests that the problem lies with the server.

To clarify, the server is running Arch Linux ARM and my laptop with the Seafile client is running Arch Linux x86_64. I upgraded both around the same time, so I wasn’t sure exactly when/where the problem appeared. I have never used a client on an ARM machine, though.
It might be the server, client or both (the latter is less likely, since now it is happening on a machine whose client wasn’t updated).